Category: Power Platform
Operating Power Platform at Enterprise Scale
What´s coming up 👆
Operating Power Platform at enterprise scale
In this article, we will learn how to use the Power Platform to build and manage low-code applications at scale. We will cover four main topics:
- How to establish a security baseline for your low-code estate using tenant isolation and IP firewall.
- How to enable governed innovation for your makers using environment routing and environment groups.
- How to enhance continuous integration for your apps using Power Platform pipelines and ALM tools.
- How to trust and verify your low-code operations using Microsoft Sentinel and Microsoft Purview.
Security baseline
The first topic is how to create a security baseline for your low-code estate. This means ensuring that your apps and data are protected from unauthorised access and malicious attacks. To do this, you can use two features: tenant isolation and IP firewall.
- Tenant isolation allows you to control the business-to-business interaction between your Power Platform tenant and other tenants. You can create policies to allow or block specific tenants from accessing your data sources and connectors. This way, you can prevent data leakage and cross-tenant attacks.
- IP firewall allows you to restrict the IP ranges that can access your Power Platform environments. You can create rules to allow or block specific IP addresses or service tags. This way, you can prevent unauthorised access and denial-of-service attacks.
To enable these features, you need to go to the Power Platform admin center and navigate to the policies and settings pages. You can also learn more about them from the links below:
Governed innovation
The second topic is how to enable governed innovation for your makers. This means empowering your makers to build low-code apps with the Copilot and other tools, while ensuring that they follow the best practices and standards of your organization. To do this, you can use two features: environment routing and environment groups.
- Environment routing allows you to direct your makers to their personal dev environments when they create new apps. This way, you can avoid cluttering the default environment with many apps and data sources. You can also control the connectors, licenses, and expiration policies for the personal dev environments.
- Environment groups allows you to organize your environments into logical sets based on your criteria. You can create groups based on organizational structure, functionality, or lifecycle stage. You can also apply rules to the groups to configure the managed environment settings, such as sharing limits, maker onboarding, solution checker, and pipelines.
To enable these features, you need to go to the Power Platform admin center and navigate to the environment groups and tenant settings pages. You can also sign up for the preview and learn more about them from the links below:
Continuous integration
The third topic is how to enhance continuous integration for your apps. This means ensuring that your apps are tested, validated, and deployed in a consistent and reliable way. To do this, you can use two features: Power Platform pipelines and ALM tools.
- Power Platform pipelines allows you to automate the movement of your apps from personal dev environments to user testing and production environments. You can use predefined templates or customize your own pipelines to suit your needs. You can also integrate IT checks and balances and certify your apps before they are shared broadly.
- ALM tools allows you to manage the life-cycle of your apps using source control, versioning, and collaboration tools. You can use tools such as GitHub, Azure DevOps, or Power Platform CLI to develop, test, and deploy your apps. You can also use tools such as Solution Checker, Power Platform Test Studio, or Power Apps Review Tool to improve the quality and performance of your apps.
- Preferred solution: This feature allows you to automatically add every app that is created in an environment to a solution, which is a container that holds the app and its dependencies. This way, you can ensure that your apps are always ready to be deployed to other environments using ALM tools, and also avoid the hassle of manually adding them to solutions later.
- Deployment notes: This feature allows you to use Copilot, an AI assistant, to generate deployment notes for your apps, which describe the changes and updates that are included in each deployment. This way, you can provide more information and transparency to your downstream stakeholders, such as testers, approvers, and end users, and also avoid the hassle of manually writing deployment notes.
To use these features, you need to go to the Power Platform admin center and navigate to the solutions and pipelines pages. You can also learn more about them from the links below:
Trust and verify
The fourth and final topic is how to trust and verify your low-code operations. This means ensuring that you have visibility and insight into the activities and events that occur in your low-code estate. To do this, you can use two features: Microsoft Sentinel and Microsoft Purview.
- Microsoft Sentinel allows you to monitor and analyze the security incidents and alerts that happen in your Power Platform tenant. You can use built-in or custom connectors to ingest data from various sources, such as audit logs, DLP events, or threat protection alerts. You can also use dashboards, workbooks, or notebooks to visualize and investigate the data.
- Microsoft Purview allows you to discover and catalog the data assets that are used by your Power Platform apps and flows. You can use scanners to scan your data sources, such as Dataverse, SharePoint, or Azure SQL. You can also use the Purview portal or the Power Platform admin center to browse and manage your data assets.
- Auto-claim policy: This feature allows you to integrate Power Platform licenses with the Microsoft 365 admin center, where you can create a pool of licenses that can be automatically assigned to users who launch premium apps. This way, you can reduce the friction and delay of manually assigning licenses, and also monitor and manage the license usage and availability in one place.
- License request: This feature allows you to integrate Power Platform licenses with the Azure portal, where you can create a workflow that enables users to request licenses for premium apps, and administrators to approve or reject them. This way, you can have more control and visibility over the license distribution and consumption, and also customize the workflow according to your needs.
These features are available in the Microsoft 365 admin center and the Azure portal, where you can configure and manage your Power Platform licenses.
Conclusion
In this article, we have learned how to use the Power Platform to build and manage low-code applications at scale. We have covered four main topics: security baseline, governed innovation, continuous integration, and trust and verify. We hope that you have found this article useful and informative. If you have any questions or feedback, please feel free to contact us. Thank you for reading
Best practices when configuring Power Platform and Dynamics CDS Data Origins – Part2
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
Best practices when configuring Power Platform and Dynamics CDS Data Origins – Part1
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