SSW Foursquare

Rules to Better Power Apps - 13 Rules

  1. Do you bundle all your customizations in a Solution (Model Driven)?

    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

    solutions custom
    Figure: Solution show all customizations, make it very easy to move changes between environments

  2. Do you know the difference between Canvas Apps and Model-Driven Apps?

    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

    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

    canvas apps example
    Figure: Canvas App Example

    Model-Driven Apps

    Model-Driven Apps are data (or schema) first approach, you model your data, that data is stored in the Dataverse, formerly known as CDS (Common Data Service). The Dataverse 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).

    The entry-level for a Model-Driven App maker is also higher with Data Modelling, JavaScript, C# knowledge being desirable if not a minimum. Would someone who didn't have these skills be able to develop a Model-Driven App? Yes, absolutely, but they wouldn't have an as productive experience as they would with making a Canvas App.

    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.

    model driven apps example
    Figure: Model-Driven App Example

    OK, I get it, now which do I use?

    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.

  3. Do you know the connectors for Power Apps?

    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.

    connector gallery
    Figure: Microsoft connectors gallery is growing every day

  4. Do you know there are Training Templates to help you learn Power Apps (Canvas)?

    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.

    power apps training
    Figure: Power Apps Training and Power Apps Training for Office

  5. Do you know to claim your Power Apps Community Plan?

    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:

    Full documentation here:

  6. Do you use source control for your Power Apps?

    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.

    How to Implement Source Control

    Exporting Power Apps Solution

    1. Open Power Platform CLI: Open a terminal and navigate to your project directory.
    2. Export Solution: Use the Power Platform CLI to export your Power Apps solution. This will create a .zip file or a directory structure that represents your solution.

      pac solution export --path ./YourSolutionName --name YourSolutionName

    Using GitHub

    1. Initialize a Git Repository: Navigate to your project directory and run git init.

      git init
    2. Add Remote Repository: Add GitHub as the remote repository.

      git remote add origin <Your-GitHub-Repository-URL>
    3. Commit and Push: Add your Power Apps exported solution files to the Git repository, commit them, and push to GitHub.

      git add .
      git commit -m "Initial commit"
      git push -u origin master

    Using Azure DevOps

    1. Create a New Repository: In Azure DevOps, create a new Git repository under your project.
    2. Clone the Repository: Clone the repository to your local machine.

      git clone <Your-Azure-DevOps-Repository-URL>
    3. Commit and Push: Add your Power Apps exported solution files to the Git repository, commit them, and push to Azure DevOps.

      git add .
      git commit -m "Initial commit"
      git push -u origin master

    Importing Power Apps Solution

    1. Open Power Platform CLI: Open a terminal and navigate to the directory where your exported solution is stored.
    2. Import Solution: Use the Power Platform CLI to import the solution into another environment.

      pac solution import --path ./YourSolutionName --name YourSolutionName

    By following these steps, you can implement source control for your Power Apps solutions using either GitHub or Azure DevOps. This will help you manage your project more effectively, collaborate with others, and maintain a history of your changes.

  7. Do you know when to use Power Automate vs internal workflow engine (Model Driven Apps)?

    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.

    power automate
    Figure: Using Power Automate is the preferred workflow engine

    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.

    builtin workflow
    Figure: Built-in workflow engine

  8. Do you place you Components in a Component Library (Canvas Apps)?

    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

    create component library
    Figure: Create a new component library

    For more information on Component libraries see documentation here:

  9. Do you use Components to create custom controls (Canvas App)?

    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:

    Full documentation here:

    newcomponent powerapps
    Figure: Create a new Component

  10. Do you use Environment variables for environment-specific configurations?

    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.

    new environment variable
    Figure: Environment variable make configuration information easy

    More information here:

  11. Do you use Power Platform Build Tools to automate your Power Apps deployments?

    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:

    Figure: ALM for your Power Platform projects

    What do I get with the Microsoft 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:

    • Helper
    • Quality check
    • Solution
    • 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:

  12. Do you know when to choose Microsoft Dataverse over traditional databases (SQL)?

    In the realm of digital solutions, data storage and management remain critical. Microsoft Dataverse, part of the Power Platform suite, offers an integrated data service with enhanced features compared to traditional relational databases like SQL. Making an informed decision between the two can significantly impact your business operations and digital strategy. Here's a guide to help you navigate this choice.


    • Integrated App Development
    • Security & Compliance Requirements
    • Development Speed and Ease
    • Custom Data Modeling Needs
    • Integration with Other Tools and Systems
    • Scalability & Performance

    Consider Using Microsoft Dataverse When

    • Integrated App Development: If you aim to develop applications with tight integration to your data using Power Apps or other Power Platform components.
    • Robust Security & Compliance: If you're looking for built-in security measures and tools that align with compliance standards and guidelines set by Microsoft.
    • Rapid Application Deployment: When the need for quick application deployment and prototyping is high, leveraging Dataverse's built-in capabilities can be beneficial.
    • Out-of-the-Box Data Modeling: If you want to avoid the intricacies of custom data model design and prefer using pre-defined templates and structures.
    • Seamless Integration with Microsoft Tools: If your operations heavily depend on Microsoft solutions like Dynamics 365, Office 365, or other Power Platform services.
    • Automatic Scalability: If you want a solution that auto-scales based on demand without manual interventions.

    Opt for Traditional Databases (e.g., SQL) When

    • Custom Data Architecture: If you require deep customization in your data architecture beyond what Dataverse templates offer.
    • Direct SQL Access & Complex Queries: When you need to perform complex SQL queries, optimizations, and have direct database access for intricate operations.
    • Interoperability with Diverse Systems: If your ecosystem consists of diverse non-Microsoft tools, and integration between them and the database is crucial.
    • High Transaction Rates: If your operations involve a very high number of transactions per second and demand impeccable performance at scale.
    • Very Large Datasets: When dealing with extensive datasets that require intricate management, optimizations, and storage solutions.

    Conclusion: Both Microsoft Dataverse and traditional databases like SQL have their unique advantages. By assessing your business needs against the criteria listed above, you can ascertain the best fit for your organization's data management requirements.

  13. Do you know when to choose Low-Code over Full-Stack Development

    As businesses undergo digital transformation, selecting the right tools and platforms becomes paramount. Microsoft's Power Platform offers a plethora of benefits tailored for businesses, ranging from data architecture to seamless integration with Microsoft's ecosystem. However, every organization has unique needs. Here's a guide to help you decide if the Power Platform is the right choice for you.


    • Data Architecture Requirements
    • Security Concerns
    • Development Timeline and Method
    • Budgetary Constraints
    • Integration with Existing Workflows
    • Ecosystem Compatibility

    Consider Using Microsoft Power Platform When

    • Data Architecture Simplification is Needed: If your business doesn't want to spend significant resources on creating a data model from scratch and prefers a robust, continuously updated model.
    • Security is a Priority: If you're looking for a solution with built-in security measures, including role-based access, auditing, and data policies.
    • Rapid Development is Essential: If you need to design, prototype, or deploy applications swiftly, especially when compared to traditional custom software timelines.
    • Budget Constraints Exist: If you're trying to avoid the high costs associated with custom software development and are looking for a cost-effective alternative.
    • Adapting to Current Business Processes: If you don't want to significantly modify existing workflows or undergo extensive retraining, and you're looking for a solution that molds around your current operations.
    • Integration with Microsoft Tools: If your business heavily relies on Microsoft products like Office 365, Dynamics 365, or Azure and seeks a seamless integration experience.

    You Might Want to Explore Alternatives When

    • Highly Specialized Customization is Needed: If your business requirements are very specific and might not be fully met by the out-of-the-box capabilities of Power Platform.
    • Outside the Microsoft Ecosystem: If your business largely relies on non-Microsoft tools and integration with these tools is crucial.

    Conclusion: The Microsoft Power Platform is a robust solution for many businesses. By assessing your needs against these criteria, you can make an informed decision about whether it's the right fit for your organization's digital transformation journey.

We open source. Powered by GitHub