Power Apps Patterns

When we think of Power Apps patterns our go to thought is this Microsoft article learn.microsoft, but that's not the type of pattern I'm talking about. For me they are more classification or type of Power App, as they focus on the end goal.

A pattern for me is more technical and focuses on how the app is made and what connectors its uses.

So what are the point of patterns, well there are a few and it's all about scalability and sustainability.

For an app to scale we will need security approval, to sustain we will need to grow beyond lone developer teams.

Power Apps are designed for citizen developers, meaning anyone can make an app, which is great, but there is a problem. Citizen developers are often not designated roles, so when the developer moves on, often we end up with orphaned apps. Any developer will tell you their worst nightmare is supporting someone else's code, especially without documentation. Add in that aa the developer is not classically trained, the solutions often takes an unusual decision path, making it even harder to read.

And this is where patterns come in, having them you can ensure novice developers create easily readable apps.

Security love patterns, they can be efficient with their testing and they are able to quickly identify or risks if a new threat is identified.

By creating patterns for common data flows, means not only we can understand the logic and structure (easy for new dev), we can layer on coding standards and Non-Functional Requirements (security happy)

The Patterns will cover data connections, input, outputs and any role authentication.

I think the below will cover over 90% of possible Power Apps you could build:

Standard SharePoint Data Gather

The App gathers data and updates a list, no sensitive data

NFRs

• SharePoint list setup for only edit own records

Examples

• Order System

Secure SharePoint Data Gather

The App gathers data and updates a list, sensitive data so leverages flow and non-delegated permissions.

NFRs

• Secure inputs/outputs for flow
• Power App v2 trigger with service account connector for SharePoint list
• Access role from approved list using triggerOutputs()?['headers']?['x-ms-user-email'] as user id
• Flow runs logged in approved list
• Access to the list by Security group and reviewed every 6 months

Example

• Absence Request

Secure Dataverse Data Maintainer

The App allows users to add and maintain data, sensitive data and row level security so requires Dataverse.

NFRs

• Use approved security roles
• Custom table and included in solution
• Table only used in this app
• Access to the table by Security role and reviewed every 6 months

Example

• Personal Development Plan

Display / Data Transformer

The App ingests no data, simply displaying information or carrying out live calculations.

NFRs

• SharePoint list shared with everyone read only
• No other connectors excluding SharePoint
• No Flows

Example

• Holiday Calculator

Notification/Comms

App gathers information and sends out notification or comms

NFRs

• Communication sent from Service Account not logged in user

Example

• Community Comms

AI Builder

User inputs data and leverages AI builder to transform/classify data. Depending on connector and processing time request can be passed to flow to run in background

NFRs

• If flow then run on Service Accounts connections
• If flow user timer for periodic progress updates

Example

• Receipt Scanner

PaaS / SaaS Integration

App sends and receives data from external system with premium or custom connector

NFRs

• Legal sign off with provider
• Authentication level O Auth only
• Logging with application insights

Example

• Jira ticket creator

Azure Data

App sends and receives data from tenant database system with SQL connector or custom connector.

NFRs

• Access through gateway
• Logging with application insights

Example

• Customer Service sales transaction search

---

These patterns can also be branched into sub versions. Example the AI Builder might want to store data in Dataverse (version -dv) or email for approval (version -ot), etc.

There are definitely still use case missed and the NFR's are specific to each organisation, but by having these patterns we can ensure that:

• Anyone can understand the logic and pick up development
• We meet security requirements
• Code Review feedback is minimum
• Documentation can follow templates for ease of creation

And if you are clever, you can scale out these patterns for other purposes, like layering on security information: