Power Apps Deployment Checklist for Connections and Permissions

Power Apps projects rarely stay as one simple canvas app. As the solution grows, it usually starts collecting other moving parts: cloud flows, connection references, SharePoint sites, Microsoft 365 groups, environment variables, service accounts, and security roles.

That is where deployment can become fragile.

A flow action may use a different connection than expected. A connection reference may point to the wrong account. A SharePoint permission may allow edit but not create. An email action may fail because the sender is not the same account configured in the Outlook connection.

This is the checklist I want to confirm before moving a Power Apps solution into production.

Start With ALM

The first rule is to avoid building important apps as isolated personal assets.

• Build the app inside a solution from the beginning.
• Use connection references instead of direct, unmanaged connections.
• Keep environment variables, flows, apps, and related components in the same solution where possible.
• Use separate development, test, and production environments when the app is business critical.
• Confirm that every flow used by the app is included in the solution before export.

Starting with a solution makes the deployment path clearer. It also reduces the chance of discovering late that a flow or connection cannot be moved cleanly.

Use Service Accounts for Shared Connections

For shared business apps, connections should not depend on one maker's personal account.

Use a service account for shared connectors such as:

• SharePoint
• OneDrive for Business
• Office 365 Outlook
• Office 365 Users
• Dataverse
• connectors used by background or admin flows

This matters because personal accounts change. People move teams, licenses change, accounts get disabled, and passwords or authentication policies can break flows unexpectedly.

The service account should be named clearly, licensed correctly, and documented as part of the application ownership model.

Name Connections and Connection References Clearly

Connection references are easier to support when the names explain their purpose.

Good names should make these details obvious:

• the app or solution they belong to
• the connector being used
• the environment
• whether the connection is a service account connection

For example:

cr_eGatePass_SharePoint_PRD_Service
cr_eGatePass_Outlook_PRD_Service
cr_eGatePass_Approvals_PRD_Service

The exact naming convention matters less than consistency. The goal is that another maker can open the solution and understand which connection reference should be used without guessing.

Confirm Every Flow Action Uses the Right Connection

Each Power Automate flow can contain many actions, and each action can use its own connection or connection reference. Before deployment, open the flow and confirm the connection used by each important action.

Pay extra attention to:

• SharePoint actions that create, update, or read list items
• Outlook actions that send email
• OneDrive actions used for file generation
• Word or PDF generation actions
• Dataverse actions that run as a specific user
• any action that performs an admin or notification task

For admin-style flows, such as sending notifications, creating PDFs, or writing system updates, use the service account connection as the run-as identity.

Rebind Flows After Connection Changes

When a flow connection is modified, replaced, or moved to a new connection reference, the Power Apps app can keep a stale reference.

After changing a flow connection:

1. Remove the flow from the Power Apps app.
2. Add the flow back to the app.
3. Save and publish the app.
4. Turn the flow off.
5. Turn the flow on again.
6. Test the app-to-flow call with the expected user account.

This refreshes the app and flow relationship and helps avoid confusing errors where the flow works in Power Automate but fails when triggered from Power Apps.

Check Outlook Send As Scenarios

Email actions need careful checking when the flow sends mail from a shared mailbox or service account.

Before deployment, confirm:

• the Office 365 Outlook connection is using the correct account
• the account has permission to send as or send on behalf of the mailbox
• the flow action uses the correct Outlook connection reference
• the sender configured in the action matches the account or mailbox permissions

If the action uses Send as, the account configured in the Outlook connection must be allowed to send as that mailbox. Otherwise the flow may pass design-time checks but fail at runtime.

Use Azure AD Groups for Access

Avoid assigning permissions user by user whenever possible.

Create Azure AD groups for the app, then assign those groups across the platform:

• Power Apps app sharing
• Power Automate access where required
• Power Platform security roles
• SharePoint site permissions
• SharePoint list or library permissions
• Microsoft Teams team or channel membership

This makes onboarding and offboarding much easier. A user should normally be added to a group, not manually added in five different places.

Separate Unrelated Apps

Do not put unrelated apps in the same SharePoint site, Teams channel, or permission model just because it is convenient at the start.

Use a separate Team site or channel when:

• the audience is different
• the data ownership is different
• the permission model is different
• the app lifecycle is different
• the app should be retired or changed independently

This keeps permissions clean and reduces the risk of exposing one app's data to another app's users.

Create the Right Power Platform Security Role

For production users, create a dedicated security role when the default roles are too broad or too unclear.

In Power Platform Admin Center, create a custom security role for the app users or app operators. Then assign that role to the Azure AD group created for the application.

At minimum, confirm the role has the privileges needed for:

• running flows
• executing workflow jobs
• reading required connection references
• reading required environment variable definitions
• reading app and process metadata

Useful privileges to check include:

• prvFlow for running flows
• prvWorkflowExecution for executing workflow jobs
• Process
• Process Session
• System Job
• Connection Reference
• Environment Variable Definition
• User Application Metadata

Also confirm read access across the required areas:

• Business Management
• Business Process Flows
• Core Records
• Custom Tables
• Customization

Depending on the app, assigning the Environment Maker role to the Azure AD group may be enough. For stricter production environments, a custom role is usually cleaner because it gives only what the app needs.

Confirm SharePoint Permissions

If SharePoint is the data source, the SharePoint permission model needs the same attention as the Power Platform solution.

Before deployment:

• Add the Azure AD groups to the correct SharePoint groups.
• Confirm Owners, Members, and Visitors contain the right users or groups.
• Use Advanced permissions from Site permissions when you need more control.
• Create a custom permission level if the default levels do not match the app.
• Test with a normal user account, not only an owner account.

For example, some apps need users to create, update, and read items, but not delete them. In that case, create a custom permission level such as Contribute items with create, update, and read permissions, but without delete permissions.

Then assign the group to the custom permission level instead of giving full edit or contribute rights.

Pre-Deployment Checklist

Before deployment, I want to be able to answer yes to each of these:

• Is the app inside a solution?
• Are all flows included in the solution?
• Are connection references used for all supported connectors?
• Are the production connection references mapped to service account connections?
• Are connection and connection reference names meaningful?
• Has every flow action been checked for the correct connection?
• Are admin, notification, file generation, and email actions using the service account where required?
• If Outlook uses Send As, does the connected account have the required mailbox permission?
• Were flows removed and added back in Power Apps after connection changes?
• Were the flows turned off and on again after connection changes?
• Are Azure AD groups used for app access instead of individual users?
• Are those groups assigned in Power Apps, SharePoint, and security roles?
• Does the Power Platform security role include the required flow and workflow privileges?
• Does the role have read access to required connection reference, environment variable, process, and metadata tables?
• Are unrelated apps separated by site, channel, solution, or permission model?
• Are SharePoint groups and custom permission levels configured correctly?
• Has the app been tested with a standard user account?

Result

Most deployment problems in Power Apps projects are not caused by the formulas. They come from ownership, permissions, and connections.

The safest pattern is to make those dependencies explicit:

• build in solutions
• use connection references
• use service accounts for shared connections
• manage access with Azure AD groups
• create security roles deliberately
• verify SharePoint permissions before go-live

The checklist takes time, but it is much faster than debugging a production app where the flow runs for the maker but fails for everyone else.