The flow works perfectly in development. Testing passes. Stakeholders sign off. You deploy to production and it fails on the first run. The error message is unhelpful. The developer who built it has moved on to the next thing.
This is one of the most common support requests I see on Power Platform engagements, and it is almost always preventable. Here is every cause I have encountered — and how to address each one.
Connection references not configured
Connection references are the solution-aware way to store connector connections. When you move a solution between environments, connection references need to be configured in the new environment with appropriate credentials.
If you hardcoded connections instead of using connection references, your flow will carry the developer's personal connection into production. It will work until that person leaves or their password changes.
Fix: Use connection references for every connector in every flow. When importing to a new environment, configure each connection reference with a service account, not a personal account.
Environment variables not set
Environment variables let you store configuration values (SharePoint site URLs, list names, thresholds, email addresses) separately from your flow logic. When you move between environments, you update the variable, not the flow.
Teams that hardcode these values discover the problem when production points to the development SharePoint site and starts writing records to the wrong place.
Fix: Before deploying any solution, audit every hardcoded value in your flows. SharePoint site URLs, list names, email addresses, Teams channel IDs — all of these should be environment variables.
Service account permissions
A flow runs as the user whose connection is attached. In development, that is often the developer with full access. In production, it is a service account with carefully scoped permissions.
The flow that could read any SharePoint list in development cannot read the restricted HR list in production because the service account was not granted access.
Fix: Define service account permissions as part of your deployment checklist. Every environment variable that stores a connection should be documented with the permissions that connection requires.
Trigger misconfiguration
List-based triggers (SharePoint item created, Dataverse row added) are environment-specific. The trigger in your dev flow points to your dev SharePoint list. If you export and import without reconfiguring environment variables, the flow in production still triggers from the dev list.
Fix: Environment variables for every trigger source. No exceptions.
Throttling and concurrency
Development environments often have low data volumes. Production environments hit API limits. A flow that processes ten records in dev might be expected to process ten thousand in production — and will start getting throttled immediately.
Load testing flows before production deployment is not optional for business-critical automation. A flow that cannot handle production volumes is not ready for production.
Fix: Test with production-scale data before go-live. Enable concurrency control. Implement retry logic. Know your connector's API limits before you hit them.
The deployment checklist
Every flow deployment should run through this before going to production:
- All connection references configured with service accounts
- All environment variables set with production values
- Service account permissions verified on all data sources
- Flow tested with production credentials in test environment
- Throttling and volume behaviour understood
- Error handling and alerting configured
- Owner and support contact documented
The checklist sounds tedious until the first time it stops a production incident from happening. After that it becomes non-negotiable.
