9 Guideline
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
Brief Rationale
For future proofing, you’ll never know when that Choice will become useful for another table or column
10 Guideline
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).
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:
- 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!
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