Rules to Better Power Apps - 10 Rules
When customizing a Model-Driven App all changes should be in a solution. A solution holds all customization being carried out by the maker, whether it be any custom entities, processes, business rules, or modifications to existing OOTB entities.
Solutions can be used to move these customizations between environments, eg. from development à testing à production.
Solutions can also be used to deploy changes in a managed (testing, production) and unmanaged (development) environment. Managed solutions can be thought of in simple terms and an installer can be installed and uninstalled.
Differences between Managed and Unmanaged solutions:
- When a Managed solution is uninstalled, all artifacts including data are removed
- Unmanaged solutions will install the changes but deleting the solution will leave the changes intact, so think of it as an additive change
- To completely remove all customizations in an Unmanaged solution every customized item needs to be manually deleted
Power Apps provide makers a highly productive low code environment, but before you jump into building your first Power App it's important to know the difference between Canvas and Model-Driven Apps and to make the right choice upfront.
Canvas Apps are just that, a blank canvas (or a template) that controls can be placed on in any order, style, and format that is required. Over 300 data sources are supported, and there is a very low cost of entry in terms of programming knowledge required. An Office “power user" or as they are now called “citizen developer" makers will have no problem developing a Canvas App that is very powerful. Here are some examples:
- Need an App to search your corporate directory for staff located within a particular radius of head office, not a problem a Canvas App can do that
- Need an App to create a checklist of work performed, take a photo of a finished product, then upload to cloud storage, not a problem a Canvas App can do that
Model-Driven Apps are data (or schema) first approach, you model your data that data is stored in the CDS (Common Data Service). CDS has the concept of an entity, entities contain fields, views, forms, relationships, processes etc. Model-Driven Apps are much more rigid in their design approach than Canvas Apps. The UI elements slot into Tabs, Sections, and the form controls are limited when compared to a Canvas App (but can be expanded on if required).
Model-Driven Apps can also host Canvas Apps, where the majority of the application logic, forms, workflows can be in the main Model Driven App, and where a specific piece of functionality is required, a Canvas App can be embedded into a Model-Driven App form. An example of this could be taking photos of a finished job and uploading it to OneDrive.
Canvas Apps are ideal for task-based apps, an example might be logging support tickets, a task checklist, submitting an expense claim, etc.
Model-Driven Apps are more suited to larger solutions, an example of this could be where a customer submits a support request, and based on the ticket type, the request is assigned to the correct team, once the team actions this request the customer receives a survey email to rate the service given.
With a Model-Driven App, a complete end to end solution can be developed.
One huge advantage of a Canvas App has over a Model-Driven App is the number of connectors supported. As of October 2020, there are 300+ supported connectors. That means the hard work and the integration between your Canvas App and 300 plus external data sources is taken care of for you. On top of this, you can create custom connectors too. Want to see all the connectors currently available, go here: https://flow.microsoft.com/en-us/connectors/.
If you're new to Power Apps and would like to get up and running quickly there two training templates that will help you along the way. The first one is Power Apps Training ; it contains exercises to get you quickly up and running with Canvas Apps.
For Office specific integration there is also the Power Apps Training for Office . Both these templates are an excellent starting point for anyone wanting to get into Canvas apps; strongly recommended for citizen and pro makers alike.
The Power App Community Plan gives developers a dedicated environment with access to:
- Power Apps (Canvas and Model-Driven)
- Premium Connectors
- Power Automate
- Common Data Service and more…
Best of all it’s completely free, yes there are some restrictions but they’re quite reasonable. The main ones being the environment is restricted to a single user and no ability to share apps. Sign up for a Community Plan here: https://powerapps.microsoft.com/en-us/communityplan
Full documentation here: https://docs.microsoft.com/en-us/powerapps/maker/dev-community-plan
When creating workflows for Model-Driven Apps using Power Automate is now the suggested and for most scenarios the preferred workflow engine. Using Power Automate is simply a nicer experience compared to using the legacy workflow editor, with the ability to connect to over 300 connectors, visual editor, excellent expression editor that the built-in workflow editor simply can’t touch.
There is one scenario where the built-in workflow engine is preferred and that is when a synchronous workflow is needed. A synchronous workflow means that all operations will wait until the workflow is completed. An example of this could be synchronous workflow being trigger on save of a record. You can be certain that when the user gets control back after saving the record that the workflow would have finished running. This is important in some instances, as with an asynchronous workflow (like Power Automate) the workflow will be triggered on save and the App will continue running as normal.
If you are creating and using Components, you’re already doing a great job. The next step is to move those commonly used components into a Component Library. The advantage of moving to a Component Library is the Components will be accessible by all your apps. Another advantage is Components can be shared with other makers to use in their apps. To create a Component library, go to:
Apps | Component libraries | Create Component library
For more information on Component libraries see documentation here: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/component-library
Canvas Apps have many controls out of the box that will work for most scenarios, for example, you would like to create a custom control that combines a text box and two buttons (+ and -) to create a spinner control. You could do this by placing two buttons next to a text box on the form. Problem solved, but what about next time that same control is needed?
That's where Components come in. Components allow you to create a custom control once then re-use the control repeatedly in your App. It's great for consistency, and any time you edit the component definition those changes will be applied to every instance of the control.
For more information on Components look at the following blog post: https://powerapps.microsoft.com/en-us/blog/components-available-in-preview/
Full documentation here: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/create-component
If your Power Apps solution has any environment-specific configuration items, then an Environment Variable in the Solution gives you a configurable input parameter. Environment variables avoid hardcoding configuration information and having to keep track of and change configuration data when importing a solution.
Some of the benefits of using environment variables are:
- No need to manually edit configurable values in a production environment.
- Configure one or more variables in one place and reference like a parameter across multiple solution components.
- Enter different values while importing solutions to other environments.
- Update values without a code change.
- Granular level security managed by Common Data Service.
- Unlimited number of variables (max solution size is 29 MB).
- Service the definitions and the values independently or together.
- Supported by Solution Packager and DevOps tools enable continuous integration and continuous delivery (CI/CD).
- Support for localization.
- Can be used to control feature flags and other application settings.
More information here: https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/environmentvariables
You’ve built your Power App using all the best practices, have multiple solutions that are split into a logical component, you’re using environment variables to handle your configuration data everything is going great! Now it comes time to deploy these changes to the Test environment. Do not deploy these manually. It is a repetitive step and if you have multiple solutions, there will be installation order dependencies that need to be handled, etc. Then the whole process will need to be repeated when you promote the changes to production, rinse, and repeat for the next round of changes for test and production. Highly repetitive, error-prone, and a prime example of automation.
The solution, Power Platform Build Tools:
The Power Platform Build Tools are a collection of Power Platform-specific Azure DevOps build tasks. They automate the manual steps and scripts needed to manage the application lifecycle. There four types of tasks:
- Quality check
- Environment management
What Power Platform Projects are supported?
- Canvas and Model-Driven Apps
- Power Virtual Agents
- UI Flows and Traditional Flows
- AI Builder
- Custom Connectors and Dataflows
If it can be included in a solution, then it's supported.
More Information here: https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools