Best practices when customizing Power Platform and Dataverse
In my last article about Power Platform best practices, the tips covered the configuration aspect using out-of-the-box capabilities (i.e. low/no code). In this one, I touch on the best practices extending Power Platform and Dataverse with customizations. This is aimed more for pro-developers or anyone using code (e.g. C#, JavaScript). Like in the previous article, these guidelines are based on past experiences and projects, and also from common questions/mistakes seen in the community.
# |
Guideline |
Brief Rationale |
||||
1 |
Choose low code/no code approach over customizations (code). This may sound obvious but it’s easy to fall back on old ways and methods that we’re conformable with. Examples:
|
Adds value quicker to the business
Less maintenance effort
Easily adopt new features
More likely to have upgrade path and less likely to break with upgrades and API changes |
||||
2 |
Should server-side logic be required, leverage Azure Functions with Azure aware plugins instead of traditional plugins when (but not limited to):
Note: Sync operations with Azure Functions is possible with webhooks 😊
More info: https://docs.microsoft.com/powerapps/developer/data-platform/azure-integration |
Better scalability
Can handle long running processes
Azure stack becomes available
Better monitoring |
||||
3 |
Prevent all-purpose plugins (traditional and Azure aware). Scope plugins to perform a single task based on a clear set of inputs and outputs. Select only the required columns for the step/trigger and for pre/post images. Example:
With the 2nd approach, we have a clear idea what the plugins are doing, and we have the flexible to have different plugin step configuration for each. |
Better scalability and flexibility
Better performance as async plugins can run in parallel
Better maintainability |
||||
4 |
Use Custom API instead of custom workflow activities or custom actions which also provides more flexibility. |
Workflows are getting phased out
Better flexibility |
||||
5 |
Limit the data retrieved from the APIs or SDK calls by:
More info: https://docs.microsoft.com/powerapps/developer/data-platform/best-practices |
Better scalability and performance
Less code smells |
||||
6 |
Reference dependent web resources with the dependency feature instead of adding them to model-driven forms or ribbon.
|
Dependencies traceability
The system does not guarantee the load order
Better performance
|
||||
7 |
Be aware of the deprecated client scripts (e.g. Xrm.Page) or messages. Recommend reviewing these under a regular frequency. Deprecated list: https://docs.microsoft.com/power-platform/important-changes-coming#some-client-apis-are-deprecated
Tip: Using Solution Checker with help to detect those 😊 |
Better performance
More likely to have upgrade path and less likely to break with upgrades and API changes |
||||
8 |
Use the async pattern when writing JavaScript/TypeScript to reduce chaining and complexity. For example (taken from MS docs)
Can be rewritten like this:
Which one is more readable?
Note: Model-driven apps now support awaiting for async OnLoad and OnSave events. |
Better maintainability, cleaner code that’s easier to read |
||||
9 |
Might seem strange but do not use ExecuteMultipleRequest or ExecuteTransactionRequest in traditional plugins due to their overheard and plugin execution limit. Performance of these messages are gain more in external processes. |
Better Performance |
Supporting documentation and additional readings:
https://docs.microsoft.com/powerapps/developer/data-platform/best-practices
Comments
-
-
Best practices when customizing Power Platform and Dataverse
Hi @_neronotte,
Agree that sometimes it becomes more complex and hard to scale with Business Rules than JavaScript for example, but these are just general guidelines. If the complexity is known upfront and the out-of-the-box tools aren't fit for purpose for this scenario, then looking at other custom alternatives is totally fine 🙂 Having a more senior resource would help to identify these scenarios.
-
Best practices when customizing Power Platform and Dataverse
Hi Eric,
I don't completely agree with guideline #1.
Usage of Business Rules opposed to JS can lead to several issues:
- when the complexity increases, the readability and the maintenability of the business rules decrease a lot faster than the corrisponding JS logic.
- if you start writing logic as a BR, you can reach an asymptote where you need to throw it all away and move to JS, because of a single requirement that cannot be addressed by BR
Same goes for powerautomate. It can be written faster for easy-to-go scenarios, but in the long run they are harder to mantain.I think that, as for every tool PowerPlatform provides us, there is a "complexity ceiling" under which is preferrable to go via codeless solutions, and above of you should directly go via full-code-based-solutions.
The hard part is to identify that ceiling...
*This post is locked for comments