Tag: Dataverse

---

9 Guideline

When creating Choice option set columns, create them at Global Choices for reusability.

Would a Lookup column be better? Main Pros/Cons:

Brief Rationale

For future proofing, you’ll never know when that Choice will become useful for another table or column

---

10 Guideline

Brief Rationale

Future proofing. Will give you more flexibility as your system evolves. Changing a column afterwards is difficult.

---

12 Guideline

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:

Brief Rationale

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 Guideline

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

Brief Rationale

Better UX with less clutter, confusion and potential issues.

---

14 Guideline

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:

Brief Rationale

Classic workflows are getting phased out. A cloud flow will also give you much more capabilities to automate.

Better scalability, performance and maintainability.

---

15 Guideline

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!

Brief Rationale

Ensures custom roles have the minimum set of privileges for users to use the system.

---

Labels (5):
#canvasapps #Dataverse #DataverseforTeams #PowerApps #PowerAutomate

---

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