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:
Top comments (0)