Power Apps Patterns
Tags: powerapps, powerplatform, lowcode, development
Published: 2023-08-14 07:26:53

When we think of Power Apps patterns our go to thought is this Microsoft article [learn.microsoft](https://learn.microsoft.com/en-us/power-apps/guidance/patterns/overview), 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

![power app to sharepoint](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vzf2fy1104a0iizdha96.png)

**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.

![power app flow to sharepoint](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fs9t3ohs4z9jg8sp1pad.png)

**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.

![power app to dataverse](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zlk4xkrd0920e9m58to0.png)

**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.

![power app read sharepoint](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xf7vttnp89im7t0z6czx.png)

**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

![app communicator](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xnscegak5j84bnhek3he.png)

**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

![ai builder](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7a98ahloopmkz4togspk.png)

**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

![power app to PaaS or SaaS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/otovkk7qchup8wsrizek.png)

**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.

![power app to azure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8vzlh9vusqsrnegws7rk.png)

**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:
 
![security pattern](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z8euluelw6cudo9hjw2p.png)