Guide · Intermediate
How to line up DEV, TEST, and PROD with Power Platform Pipelines
A short path so a solution leaves development, gets tested, and reaches production without being edited there.
A solution that only exists in the environment where it was built gets fragile the day someone patches it in production. Power Platform Pipelines move that solution across three environments and leave a record of what was released.
Three environments, three jobs
- DEV. You build. The solution can stay unmanaged so components can still change.
- TEST. The person who runs the process validates it. The managed solution lands here.
- PROD. People use it. It is not the place to redesign the screen.
Before the first release
- Your own publisher and prefix, so components are recognizable.
- Environment variables for what changes between DEV and PROD: URLs, lists, notification mailboxes.
- Connection references, so the flow is not tied to the maker's personal account.
- One solution that holds the app, the flow, and the tables that travel together. Leave out anything that should not be promoted.
When you promote
Install the managed solution in TEST. Walk the whole path: create, approve, fail, and the permission of someone who is not the maker. If TEST holds, the same package continues to PROD.
If something fails in PROD, the fix goes back to DEV and through the pipeline again. Editing the component in PROD breaks the next promotion.
What to write down
Environment, solution version, date, and what was tested. Then someone else can tell what is in production without opening the designer.