Top 15 best practices when configuring Power Platform and Dataverse

[EricRegnier]

Microsoft Docs is often the first go to place if we want to get How Tos and more information on best practices. For instance, if you haven’t seen the following pages on Power Platform Guidance, ALM and Administration, they’re great and suggest going through them:

• https://docs.microsoft.com/power-platform/guidance
• https://docs.microsoft.com/power-platform/alm
• https://docs.microsoft.com/power-platform/admin/admin-documentation

For new, junior and even seasoned developers, there are some concepts that can be hard to grasp and determine the best practices to quickly get started on the Power Platform journey. Here are my top 15 best practices every developer must know when configuring the Power Platform with a focus on Dataverse. I gathered these from common questions/errors seen in the community and from past experiences. These are based on Configuration — configuring the platform with out-of-the-box capabilities (i.e. no code), and next article will be on Extending — for pro developers and extending the platform using code.

#	Guideline	Brief Rationale
1	Always provision Dataverse in a new instance and never install Dataverse in the Default environment even for non-production environments. Licenses are not per environment but storage, so extra storage the environment(s) take are negligible. More info: https://docs.microsoft.com/power-platform/guidance/adoption/environment-strategy	This is mainly because all licensed users will automatically be added to Default environment with customizing privileges (i.e Maker role) which can be dangerous.
2	Change the default publisher prefix on both “CDS Default Publisher” and “Default Publisher”.	There’s always someone (including yourself!) that by mistake configured a component outside of a solution. If prefix isn’t changed then it will be named the default prefix (e.g. new_ or cr43e_).
3	Perform your changes in a solution. Solutions are great to track your changes (including Power Automate, Agents, Dataflows, etc) and are used to promote your completed changes to another environment such as production. Only add sub-component level for existing components. More info: https://docs.microsoft.com/power-platform/alm/segmented-solutions-alm There’s a lot more that can be said about managed/unmanaged solutions, deployments and ALM but it’s for another topic!	Risk of unexpected behavior after a releasing. Risk of releasing components that are not ready and overwriting changes made from others.
4	Create small apps (model-driven or canvas apps) instead of large apps. For model-driven apps, only associated the required components (e.g. forms, views, tables, etc) to the app. For example, instead of having one large “CRM” app, split into smaller ones such as “Customer Service” and “Sales” and assign / share the “Customer Service” app to Customer Service users and salespeople the “Sales” app.	Future proofing. Will allow for better flexibility/maintainability and less risk of regression as changes are made. Better UX with leaner and cleaner focused apps.
5	Do not re-create custom Account, Contact or User tables. Reuse the ones out-of-the-box and create new forms, views, etc for them. Update the names if need be. For instance, it’s quite common to rename Account to “Organization” or “Company” and Contact to “Person” or “Individual”.	As the system evolves, will allow you to adopt new features and eventually leverage existing features that weren’t necessary before.
6	Create new tables with ownership as “User or Team”. Only exception cases where tables are Organization owned.	Future proofing since this option cannot be done change after the table is created. Will give you more flexibility around security and privacy as your system evolves. For instance, there’s a Timesheet table as Org owned which users have access to manage their timesheets. Later, you want to enhance security so that users only have access to their own timesheets and not the others. It would have been possible if the table was configured as “User or Team”, but not as Org.
7	Business units (BU) are used to segregate data for security/privacy purposes, so organize your BU structure based on your security groups, not on your organisation structure. If you don’t have these security requirements, don’t configure BUs, but at a minimum create a child BU for your users.	BUs are complex to amend, over configuring BU imposes restrictions. For future proofing, leaving the root BU free with one direct child BU enables easier introduction of BUs later.
8	When creating  Lookup columns, set the Display Option to “None”. Add it manually if required in the Related tab of model-driven forms. If you don’t need the Related tab, hide it.	Better UX and avoid of having lots of junk in the Related tab. Example:
9	When creating Choice option set columns, create them at Global Choices for reusability. Would a Lookup column be better? Main Pros/Cons: Choices For elements that are usually static (e.g. Gender) Adding new items will require a release. Easily deploy to target environments with solutions since items are considered as metadata whereas tables are data (but can easily import as well with Configuration Migration Tool) Simpler UX in model-driven apps (irrelevant in canvas apps) as Choices are rendered as simple drop downs Out-of-the-box multi-language support  Lookups My preference. Future thinking, tables give more flexibility, especially if eventually need more metadata (e.g. Display Order). So many times, I had to convert and deprecate Choices to Lookups instead. Supports out-of-the-box cascading drop down behaviors	For future proofing, you’ll never know when that Choice will become useful for another table or column
10	When requiring many-to-many (N-N) relationships between data/tables, know your options as there are 3 methods: Multi Choices multi-select option sets - simplest but most limited Out-of-the-box N-N relationship - simpler UX but limited Custom N-N relationship - a junction/intermediate table with Lookups on the two tables. More complex to set up but more flexible to change. My preference because can capture additional info about the relationship such as "Relationship Type" whereas is not supported with out-of-the-box N-N relationship. Gain more control with extensions (e.g. plugins).	Future proofing. Will give you more flexibility as your system evolves. Changing a column afterwards is difficult.
12	Consistency (applies for Extensions as well)! This is something I’m very strict on. Discuss with your team and ensure consistency with naming conventions, form design, etc. Some of common easy standards are: Prefix Power Automate flows and classic workflows (e.g. “Notifications – Follow-up on case with customer”) Lower case on physical names of tables and columns. The developers will thank you! This will simplify their life especially when using the Web API. Suffix date time columns with “On” to follow Microsoft naming conventions (e.g. Created On). You don’t want a mix of styles like Created Date, Date Created, Created On!	Because you’ve done such a good job delivery awesome apps, as your system evolves having consistency will pay off and make it easier to maintain, understand, etc. Better UX
13	Hide model-driven command bar buttons if not used. Example: If possible, hide buttons with privileges (e.g. hide New button with create privilege) otherwise can easily hide with the Ribbon Editor	Better UX with less clutter, confusion and potential issues.
14	Automate any background (async) processes with Power Automate instead of classic workflows. More info: https://docs.microsoft.com/power-automate/replace-workflows-with-flows Following the same principle as #4, prevent all-purpose Power Automate flows. Scope flows to perform a single task based on a clear concise set of inputs and outputs. Register the flow on the exact step, fields/columns and rows/records filters:	Classic workflows are getting phased out. A cloud flow will also give you much more capabilities to automate. Better scalability, performance and maintainability.
15	Create custom roles based on the out-of-the-box “Basic User” security role. There are different ways to model security; business/title-based roles and/or Add-on or feature type roles. For example: "Export to Excel" role with just export to excel privileges versus "Customer Service Manager" with all the privilege the manager required to perform its tasks. A topic for the future, but analyze which is best for your needs!	Ensures custom roles have the minimum set of privileges for users to use the system.