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 Extensions — for pro developers and extending the platform using code.
1 Guideline
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
Brief Rationale
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 Guideline
Change the default publisher prefix on both “CDS Default Publisher” and “Default Publisher”.
Brief Rationale
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 Guideline
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!
Brief Rationale
Risk of unexpected behavior after a releasing. Risk of releasing components that are not ready and overwriting changes made from others.
4 Guideline
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.
Brief Rationale
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 Guideline
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”.
Brief Rationale
As the system evolves, will allow you to adopt new features and eventually leverage existing features that weren’t necessary before.
6 Guideline
Create new tables with ownership as “User or Team”. Only exception cases where tables are Organization owned.
Brief Rationale
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 Guideline
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.
Brief Rationale
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 Guideline
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.
Brief Rationale
Better UX and avoid of having lots of junk in the Related tab. Example:
Labels (5):
#canvasapps #Dataverse #DataverseforTeams #PowerApps #PowerAutomate