Rules to Better Power Apps

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.

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.

One huge advantage that Canvas Power Apps 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 Power Apps and 300 plus external data sources is taken care of for you. On top of this, you can create custom connectors too. See all the Power Automate connectors currently available.

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.

Source control is essential for any software development project, and Microsoft Power Apps solutions are no exception. Here are some reasons why you would want to use source control like GitHub or Azure DevOps for your Power Apps projects:

• Versioning - Keep track of changes made to your Power Apps solutions over time.
• Collaboration - Enable multiple developers to work on the same Power Apps project simultaneously.
• Audit Trail - Maintain a history of who made what changes and when.
• Rollback - Easily revert to a previous version if something goes wrong.
• Branching and Merging - Work on new features or bug fixes in isolation before integrating them into the main project.
• Automated Deployment - Integrate with CI/CD pipelines for automated testing and deployment.

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.

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

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?

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.

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.