Rules to Better Power Apps

​​

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
  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.png
    Figure: Solution show all customizations, make it very easy to move changes between environments

    Related Rule

  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. 

    ​C​anvas 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.png
    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 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).  

    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.png
    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 there are *hundreds* of connectors for Power Apps (Canvas)?

    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/.​

    connector-gallery.png
    Figure: Microsoft connector 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.png
    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: https://powerapps.microsoft.com/en-us/communityplan

    Full documentation here: https://docs.microsoft.com/en-us/powerapps/maker/dev-community-plan

  6. 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.png
    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.png
    Figure: Built-in workflow engine

  7. 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.png
    Figure: Create a new component library​

    For more information on Component libraries see documentation here: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/component-library

  8. 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: 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

    newcomponent-powerapps.png
    Figure: Create a new Component​
  9. 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.png
    Figure: Environment variable make configuration information easy

    More information here: https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/environmentvariables

  10. 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: 

    almpowered.png
    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: https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools