Invoice Intelligence Pipeline: ALM

Deploy a managed invoice solution across Dev, Test, and Production via Power Platform Pipelines.

Introduction

30 Second Summary

Building an app is only half the battle. Getting it safely from your development workspace to production, without breaking things or exposing sensitive data, is what separates a prototype from a real enterprise solution.

In this project, you will package your invoice intelligence solution into a portable deployment unit and push it through a multi-stage pipeline from Development to Test to Production. You will also set up connector governance policies to protect each environment.

What You'll Build

A complete ALM pipeline that deploys your Invoice Intelligence solution across three environments using Power Platform Pipelines and Data Loss Prevention policies.

By the end of this project, you'll have:

A packaged unmanaged solution with environment variables and connection references for portability across environments.
A multi-stage deployment pipeline (Dev > Test > Production) with successful deployment history and a managed solution upgrade demonstrating solution layering.
A DLP policy enforcing connector governance across your invoice pipeline environments with Business, Non-Business, and Blocked classifications.
Secret Mission: Wire a pre-deployment approval gate on the Production stage using pipeline gated extensions and a cloud flow.

Are there any prerequisites?

Yes. This project is Part 4 of the Invoice Intelligence Pipeline series. You need to have completed Projects 1-3 with all components built in a development environment.

You also need a Power Platform Premium license and a Power Platform admin role on your tenant.

Create Target Environments

Your invoice pipeline works well in the development environment. But deploying it to real users requires separate environments where you can test changes safely before they reach production.

Power Platform ALM uses a multi-environment strategy. You'll create two sandbox target environments (Test and Production) and enable them as Managed Environments so they can receive deployments through a pipeline later.

In this step, get ready to:

Create a Test sandbox environment with a Dataverse database.
Create a Production sandbox environment with a Dataverse database.
Enable both environments as Managed Environments.

Note the region of your development environment

Both target environments must be in the same region as your development environment. Before creating them, confirm which region your dev environment uses.

In the Power Platform admin center, select Manage in the navigation pane.
In the Manage pane, select Environments.
Find your development environment in the list and note the Region column value (e.g., United States, Europe).

Why the same region?

Deployment pipelines move solutions between environments. Keeping all environments in the same region minimizes latency during deployments and avoids cross-region data residency concerns.

Create the Test environment

Sandbox environments are non-production environments designed for testing and ALM. You'll create the first one for your testing stage.

On the Environments page, select New in the command bar.
In the Name field, enter Invoice Pipeline - Test.
Set Region to the same region as your development environment.
Set Type to Sandbox.
Set Add a Dataverse data store to Yes.
Leave Pay-as-you-go with Azure set to No (your Premium license covers this).
Select Next.

On the second page of settings:

Leave Language and Currency at their defaults.
For URL, enter a unique name such as invoicepipeline-test.
Set Enable Dynamics 365 apps to No.
For Security group, select None for open access.
Select Save.

What is a Dataverse data store?

Dataverse is the underlying database platform for Power Platform. Your invoice pipeline's tables, flows, and apps all rely on Dataverse. Each target environment needs its own Dataverse instance to receive the managed solution later.

The environment takes a few minutes to provision. Wait for the status to change from Preparing to Ready in the Environments list.

Not seeing the New button?

You need the Power Platform Administrator role to create environments. Confirm your role is assigned in the Microsoft Entra admin center under role assignments.

Also ensure your tenant has at least 1 GB of database storage capacity available. You can check this under Resources > Capacity in the admin center.

help me troubleshoot why I cannot create a new environment in Power Platform admin center

Create the Production environment

Repeat the same process to create a second sandbox environment for your Production stage.

On the Environments page, select New in the command bar again.
In the Name field, enter Invoice Pipeline - Production.
Set Region to the same region as your development environment.
Set Type to Sandbox.
Set Add a Dataverse data store to Yes.
Select Next.

On the second page:

For URL, enter a unique name such as invoicepipeline-prod.
Set Enable Dynamics 365 apps to No.
For Security group, select None.
Select Save.

Wait for this environment to reach Ready status before continuing.

Why sandbox type for Production?

In a learning scenario, sandbox environments are free on your Premium license and offer the same deployment pipeline capabilities as production-type environments. You can always convert a sandbox to production type later when the solution is ready for real users.

Enable Managed Environments on both targets

Pipeline target environments must be enabled as Managed Environments before they can receive deployments. This unlocks premium governance features like solution checker enforcement and sharing limits.

On the Environments page, select the ellipsis (...) next to Invoice Pipeline - Test.
In the menu, select Enable Managed Environments.
Review the default settings on the configuration pane.
Select Enable.

Repeat for the Production environment:

Select the ellipsis (...) next to Invoice Pipeline - Production.
Select Enable Managed Environments.
Select Enable.

What if it says already managed?

Starting February 2026, Microsoft began auto-enabling Managed Environments for pipeline targets. If you see Edit Managed Environments instead of Enable Managed Environments, the environment is already managed. No further action is needed for that environment.

After enabling, both environments display a Managed badge in the Environments list. You should now see three environments: your original development environment plus the two new managed sandbox environments.

Don't see the Enable Managed Environments option?

This option requires the Power Platform Administrator or Dynamics 365 Administrator role in Microsoft Entra ID. Users with only the Delegated Admin or Environment Admin role cannot change this property.

Also confirm that the environment has finished provisioning and shows Ready status. Environments still in Preparing state cannot be modified.

help me enable Managed Environments in Power Platform admin center

Your three-environment landscape is ready. Next up, you'll package all your invoice pipeline components into a portable solution with environment variables and connection references.

Package the Solution

Your Test and Production environments are ready. Now it's time to bundle everything you built in Projects 1-3 into a single, portable unit that can travel between environments.

In Power Platform, that unit is called a solution. A solution groups your tables, apps, flows, and other components together under a custom publisher so they can be exported, versioned, and deployed as one package.

In this step, get ready to:

Create a custom publisher with a unique prefix for your invoice components.
Package all Projects 1-3 components into an unmanaged solution.
Add environment variables and connection references for portability across environments.

Create a custom publisher

A publisher identifies who created the solution and applies a consistent prefix to all components. This prefix prevents naming collisions when multiple solutions from different teams are installed in the same environment.

In make.powerapps.com, confirm you are in your development environment using the environment selector in the header.
Select Solutions in the left navigation pane.
Select New solution to open the new solution panel.
In the Publisher dropdown, select New publisher.
Enter Contoso Invoice Team in the Display name field.
Enter cinv in the Prefix field.
Select Save to create the publisher.

What is a publisher prefix?

The prefix (cinv in this case) is prepended to the internal name of every component you create inside the solution. For example, a new column called "Deployment Version" becomes cinv_deploymentversion in Dataverse.

This helps you distinguish your components from those created by other publishers or the system default.

Don't see New publisher?

Make sure you clicked New solution first. The New publisher option only appears inside the new solution panel, not from the main Solutions list.

help me find where to create a new publisher in Power Apps

Create the unmanaged solution and add components

With your publisher ready, you can now create the solution container and fill it with all the invoice pipeline components from Projects 1-3.

Back in the New solution panel, enter Invoice Intelligence Pipeline as the Display name.
Select Contoso Invoice Team from the Publisher dropdown.
Leave the version as 1.0.0.0.
Select Create.

Your empty solution opens. Now add your existing components to it.

Select Add existing in the command bar, then select Table.
Search for and select your Invoice table and all related tables from Projects 1-3.
Select Next, then choose Include all objects and metadata for each table.
Select Add.
Select Add existing again, then App, then Model-driven app. Select your model-driven app and click Add.
Select Add existing, then App, then Canvas app. Select your canvas app and click Add.
Select Add existing, then Automation, then Cloud flow. Select all your cloud flows (including the approval flow and any processing flows) and click Add.
Select Add existing, then Automation, then Process. Select your business process flow and click Add.
Select Add existing, then Other, then Security role. Select your custom security roles and click Add.
Select Add existing, then Chatbot. Select your Copilot Studio agent and click Add.

Why include all objects and metadata?

Selecting "Include all objects and metadata" ensures views, forms, charts, and business rules attached to your tables are included. Without this, you might deploy a table without its custom views, causing errors in your apps.

If a Missing Required Components prompt appears

Select Yes, include required components. This automatically pulls in any dependencies (like referenced tables or choices) that your components need to function correctly in the target environment.

Add environment variables and connection references

Your flows from Projects 1-3 likely have hardcoded connection IDs and environment-specific values like a SharePoint site URL. These need to be replaced with portable placeholders so the solution works in any environment.

Environment variables store values that change per environment. Connection references decouple your flows from specific user connections.

Inside your solution, select New in the command bar, then More, then Environment variable.
Enter SharePoint Site URL as the Display name.
Set the Data type to Text.
Enter your development SharePoint site URL as the Current value.
Select Save.
Repeat the process to create a second environment variable named Approval Manager Email with Data type set to Text and your admin email as the current value.

What are environment variables?

Environment variables store values like email addresses, URLs, or connection strings that differ between environments. When you deploy the solution to Test or Production, you provide new values for each variable without modifying the flow logic itself.

Now create connection references for each connector your flows use.

Inside your solution, select New, then More, then Connection Reference.
Enter a display name (e.g., Dataverse - Invoice Pipeline), select the Microsoft Dataverse connector, and choose your existing Dataverse connection.
Select Save.
Repeat this process to create connection references for SharePoint, Approvals, and AI Builder connectors.

Finally, update your flows to use these connection references instead of hardcoded connections.

Open each cloud flow inside your solution by selecting it.
For each action in the flow, check the connection. If it shows a specific user connection rather than a connection reference, select the action, expand the connection settings, and switch it to the matching connection reference you just created.
Replace any hardcoded SharePoint site URLs or email addresses in your flow actions with the environment variables you created. Use the dynamic content picker (lightning bolt icon) to insert the environment variable.
Save each flow after updating it.

Why replace hardcoded connections?

Flows with embedded connection IDs break when deployed to another environment because those connection IDs don't exist there. Connection references act as a bridge. During import, Power Platform prompts you to map each reference to a valid connection in the target environment.

Can't find the connection reference option in a flow action?

Flows that were originally created outside of a solution may not show connection reference options. If this happens, remove the action and re-add it while working inside the solution context. Power Automate will automatically offer connection references that exist in the solution.

help me update my flow to use connection references instead of hardcoded connections

Now verify your solution is complete and free of dependency issues.

Return to the Solutions list in the left navigation.
Next to your Invoice Intelligence Pipeline solution, select the vertical ellipsis (⋮), then Solution checker, then Run.
Wait for the analysis to complete. This may take a few minutes. You will receive a notification when it finishes.
Verify the results show no critical issues or missing dependencies.

What does Solution Checker do?

Solution Checker scans your unmanaged solution for common issues like missing dependencies, performance problems, and configuration errors. Running it before deployment catches problems early rather than discovering them during import into Test or Production.

Open your solution and confirm that environment variables and connection references both appear in the components list alongside your tables, apps, and flows.

Your invoice pipeline is now packaged as a portable solution. Next up, you will configure a deployment pipeline to move this solution through your Test and Production environments automatically.

Configure the Deployment Pipeline

In the previous step, you packaged all your invoice pipeline components into a single portable solution. Now it is time to build the highway that moves that solution from development through test to production.

Power Platform Pipelines automate the export, transfer, and import of solutions between environments. Instead of manually downloading and re-uploading solution files, you configure a pipeline once and deploy with a few clicks.

In this step, get ready to:

Create a deployment pipeline targeting your Test environment.
Add a Production stage to the pipeline.
Deploy the invoice solution to Test and verify a successful deployment.

Create the deployment pipeline

A deployment pipeline defines the path a solution travels from your development environment to one or more target environments. You will create a personal pipeline using the platform host, which supports up to three environments (one development source and two targets).

In make.powerapps.com, confirm you are in your development environment.
Select Solutions in the left navigation pane.
Open your Invoice Intelligence unmanaged solution.
Select Pipelines from the left navigation pane inside the solution.
Select Create pipeline on the command bar (or from the Pipeline dropdown).
In the Pipeline name field, enter Invoice Pipeline.
For Target environment, select your Test environment from the dropdown.
Select Save.

What just happened?

Saving the pipeline linked your development environment and the Test environment to the platform host. It also created environment records for both environments automatically. The pipeline now has a single stage targeting Test.

Why use the platform host?

The platform host is the default tenant-wide host that any maker can configure. For a personal pipeline with up to two target environments, it is the simplest option. A custom host adds centralized governance but requires extra setup that is not needed for this project.

Add the Production stage

Your pipeline currently has one stage (Test). You need a second stage so the solution can continue its journey to Production after passing validation in Test.

With the pipeline still open, select Add stage on the command bar.
In the Name field, enter Production.
For the target environment, select your Production environment.
Select Save and Close.

What does Add stage do?

The Add stage button appends a second deployment stage to your single-stage pipeline. This button is only available on pipelines that currently have one stage. Stages must be completed in order, so the solution deploys to Test first, then Production.

Your pipeline now shows two stages: Test and Production.

Don't see the Add stage button?

The Add stage capability is only available on single-stage pipelines that you own. If you do not see the button, confirm you are the owner of the pipeline and that it currently has only one stage.

help me troubleshoot why the Add stage button is not appearing on my pipeline

Deploy the invoice solution to Test

With both stages configured, you can now run your first deployment. The pipeline will export your solution from development and import it as a managed solution into the Test environment.

Return to the Pipelines page inside your Invoice Intelligence solution.
Select your invoice solution from the list.
Choose Invoice Pipeline from the pipeline dropdown.
Select Next to begin the deployment configuration.

What happens at this step?

The pipeline validates your connection references and environment variables before the deployment begins. You will be prompted to provide connection values and environment variable values specific to the Test environment (for example, the Test SharePoint site URL and a valid connection for each connector).

For each connection reference (Dataverse, SharePoint, Approvals, AI Builder), select or create a valid connection for the Test environment.
For each environment variable (SharePoint site URL, approval manager email), enter the values appropriate for Test.
Select Deploy.

The deployment process begins. This may take a few minutes depending on the size of your solution.

Wait for the deployment to complete. Select Run history to monitor progress and confirm the deployment succeeded.

What does Run history show?

The Run history tab displays all deployment activity for the current pipeline and solution. Each run shows the status, start time, end time, and any error details if a failure occurred.

To verify the managed solution arrived in Test, switch to your Test environment in make.powerapps.com.
Select Solutions in the left navigation pane.
Confirm the Invoice Intelligence solution appears in the list with a Managed badge.

Why is the solution managed in Test?

Pipelines always deploy solutions as managed artifacts to target environments. A managed solution prevents direct edits in Test or Production, ensuring all changes flow through the development environment and the pipeline. This is a core ALM best practice.

Deployment failed or stuck?

Check that both your Test and Production environments are enabled as Managed Environments. Pipeline targets must be managed environments.

Verify that the connections you provided are valid and that you have import privileges in the Test environment. Open Run history for detailed error messages.

help me debug why my Power Platform pipeline deployment to the Test environment failed

Your deployment pipeline is live and your first managed deployment is in Test. Next up, you will make a change to the solution and deploy an upgrade to see how solution layering works in a managed environment.

Perform a Managed Solution Upgrade

Your invoice solution is deployed as a managed solution in the Test environment. In real-world ALM, solutions evolve constantly as teams add new features and fix issues.

To understand how Power Platform handles these changes, you will now modify the solution in development, increment its version, and deploy the update through the pipeline. This demonstrates solution layering and the "top wins" behavior that determines which layer controls a component at runtime.

In this step, get ready to:

Add a new column to the Invoice table and increment the solution version.
Deploy the updated solution through the pipeline as a managed upgrade.
Inspect solution layers in the Test environment to confirm managed layer behavior.

Make a visible change and increment the solution version

Before you can deploy an upgrade, you need something different between the development version and what is already in Test. Adding a new column is a quick, visible change that is easy to verify after deployment.

In make.powerapps.com, make sure you are in your development environment.
Select Solutions in the left navigation.
Open your Invoice Intelligence unmanaged solution.
In the Objects pane, expand Tables and select your Invoice table.
Select Columns in the sub-navigation, then select + New column on the command bar.
Enter Deployment Version as the display name.
Set the data type to Single line of text.
Select Save to create the column.

Why add a column instead of changing an existing one?

Adding a new column is a non-destructive change. It does not break existing flows or apps that reference the Invoice table. This makes it safe to deploy through a pipeline without needing to update downstream components first.

Now increment the solution version number so the pipeline recognizes this as a newer release.

Navigate back to the solution's Overview pane (select Overview in the left navigation of the solution).
Locate the Version field. It currently shows 1.0.0.0.
Change the version to 1.1.0.0.
Select Save to confirm the version change.

What is the version format?

Power Platform solutions use the format major.minor.build.revision. An update must have a higher value in at least one position than the parent solution. Bumping from 1.0.0.0 to 1.1.0.0 signals a minor feature addition.

Can't edit the version field?

Make sure you are editing the unmanaged solution in your development environment. Managed solutions in target environments cannot have their version changed directly.

If the solution is locked due to patches, you may need to clone it first. For this project you should not have patches, so the version field should be editable.

Help me update my solution version in Power Platform.

Deploy the updated solution through the pipeline

Power Platform Pipelines use Stage and Upgrade as the default import behavior. This means the new version replaces the previous managed solution in the target environment and rolls up any patches into a single base layer.

In your Invoice Intelligence solution, select Pipelines in the left navigation pane.
Select Invoice Pipeline from the list.
The pipeline shows your solution ready for deployment. Select Deploy for the Test stage.
Provide any required connection values and environment variable values for the Test environment (these should match what you configured in the previous step).
Confirm and start the deployment.

What happens during an Upgrade deployment?

The pipeline exports your unmanaged solution as a managed package and imports it into Test using the Upgrade behavior. This replaces the previous 1.0.0.0 managed solution with the new 1.1.0.0 version. Any components deleted from the source solution are also removed from the target.

Wait for the deployment to complete. You can monitor progress in the pipeline run history.

Once the run status shows Success, switch your environment selector to the Test environment.
Select Solutions in the left navigation.
Confirm the Invoice Intelligence solution appears with version 1.1.0.0 and is marked as Managed.
Open the managed solution, expand Tables, select the Invoice table, then Columns.
Verify the Deployment Version column is present.

Deployment failed or column not showing?

If the deployment failed, check the run history error details. A common cause is a missing connection reference or environment variable value that was not provided during deployment.

If the column does not appear in Test, confirm you saved the column in development before running the pipeline. Also confirm the solution version in Test updated to 1.1.0.0.

Help me troubleshoot my pipeline upgrade deployment.

Inspect solution layers in the Test environment

Solution layering is how Dataverse tracks which solution introduced each change to a component. In the Test environment, your Invoice table now has a managed layer from your publisher. Understanding this layering is critical for troubleshooting and for the AB-410 exam.

In the Test environment, select Solutions in the left navigation.
Open the managed Invoice Intelligence solution.
Select the Invoice table component.
On the command bar, select Advanced > See solution layers.

The solution layers page displays each layer for the Invoice table, with the most recent layer at the top.

Confirm you see a managed layer with your publisher name (Contoso Invoice Team) in the Solution column.
Verify there are no rows where the Solution column shows Unmanaged layer. A clean target environment should have only managed layers for your components.
Select the managed layer row to open the Properties pane. Review the Updated tab to see which properties were modified by your solution.

What is "top wins" behavior?

Except for model-driven app, form, and site map components, all other solution components use a "top level wins" behavior. The layer that resides at the top determines how the component works at app runtime.

Because you deployed a managed upgrade (not an unmanaged customization), your publisher's managed layer sits at the top. There is no unmanaged layer competing with it, so the managed solution controls the component entirely.

Seeing an unmanaged layer?

If you see an unmanaged layer on the Invoice table in Test, someone (or a previous import) made a direct customization in that environment. In a healthy ALM setup, target environments should never have unmanaged customizations.

You can remove it by selecting the unmanaged layer and choosing Remove active customizations on the command bar.

Help me understand solution layers in my Test environment.

You have successfully deployed a managed upgrade and verified solution layering. Next up, you will set up DLP policies to enforce connector governance across all three environments.

Set Up DLP Policies

Your managed solution is deployed and verified across environments. The pipeline handles packaging and deployment, but what about governing which connectors your flows and apps can use?

Without connector governance, a maker could accidentally wire a flow that sends invoice data to a social media connector. Data Loss Prevention (DLP) policies prevent this by classifying connectors into groups and enforcing boundaries between them.

In this step, get ready to:

Create a DLP policy scoped to your invoice pipeline environments.
Classify connectors into Business, Non-Business, and Blocked groups.
Verify DLP enforcement by triggering a violation warning.

Create a new DLP policy

DLP policies act as guardrails that control which connectors can share data with each other. You will create a policy specifically for your three invoice pipeline environments.

Switch back to the Power Platform admin center.
Select Security in the navigation pane.
In the Security pane, select Data and privacy.
On the Data protection and privacy page, select the Data policy section.
Select + New Policy.
Enter Invoice Pipeline Governance as the policy name.

What is a DLP policy?

A DLP policy classifies connectors into three groups: Business, Non-Business, and Blocked. Connectors in the Business group can only share data with other Business connectors within the same app or flow.

If a maker tries to combine a Business connector with a Non-Business or Blocked connector in the same flow, Power Platform flags or suspends the resource. This prevents accidental data leakage to unauthorized services.

Classify connectors into groups

When you create a new policy, all connectors start in the Non-Business group by default. You need to move the connectors your invoice solution uses into the Business group, and move risky connectors into Blocked.

On the Prebuilt connectors step of the policy wizard, use the search box to find and select the following connectors, then move them to the Business group:

Microsoft Dataverse.
SharePoint.
Office 365 Users.
Approvals.
AI Builder.

Leave the Microsoft 365 connectors (such as Office 365 Outlook and OneDrive) in the Non-Business group.
Search for social or non-business connectors (such as Twitter and Facebook) and move them to the Blocked group.

Why can't I block certain connectors?

Microsoft 365 Enterprise license connectors and a few core Power Platform connectors are exempt from being marked as Blocked. They can only be classified as Business or Non-Business. If you do not see the option to block a connector like Dataverse or Office 365 Users, this is expected behavior.

Select Next to proceed to the scope configuration.

Scope the policy and verify enforcement

Rather than applying this policy tenant-wide, you will scope it to only the three environments involved in your invoice pipeline.

On the Define scope page, select Add multiple environments.
From the Available tab, select your Development, Test, and Production environments, then select Add to policy.
Select Next to review your configuration.
Confirm the policy name, connector classifications, and environment scope are correct.
Select Create policy.

Your policy now appears in the Data policy list, scoped to your three invoice pipeline environments.

Why scope to specific environments?

Scoping limits the policy's impact to only the environments that need it. A tenant-wide policy could inadvertently block connectors used by other teams or projects. Environment-scoped policies give you precise governance without side effects.

To verify enforcement, navigate to your Test environment in make.powerapps.com.
Select Flows in the left navigation, then select + New flow to create a new instant cloud flow.
Add a step using the Microsoft Dataverse connector (a Business connector).
Attempt to add a second step using a Blocked connector (such as Twitter).

You should see a DLP violation warning indicating that the connectors cannot be used together. This confirms your policy is active and enforcing connector boundaries.

Enforcement may take a few minutes

DLP policy enforcement can take a short time to propagate across environments. If you do not see the violation warning immediately, wait a few minutes and try again. In rare cases, enforcement latency can extend up to 24 hours.

Once you have confirmed the violation warning, discard the test flow (do not save it).

Not seeing a DLP violation warning?

Make sure you are building the test flow in the Test environment, not a different environment outside the policy scope.

Check that the connector you added is actually in the Blocked group by returning to the admin center and editing the policy. If the connector is in Non-Business instead of Blocked, the violation will not trigger against a Business connector.

Help me troubleshoot why my DLP policy is not showing a violation warning in my Test environment.

Secret mission

Pre-Deployment Approval Gate

Your pipeline deploys to Production with zero human checkpoints. In a real enterprise, a final approval before production is non-negotiable. Wire a cloud flow that intercepts production deployments, sends an Approve/Reject request, and signals the pipeline to proceed or halt.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses sandbox environments and pipeline configurations covered by your existing Power Platform Premium license, so there are no ongoing costs.

Resources you used:

Test environment (sandbox) in the Power Platform admin center.
Production environment (sandbox) in the Power Platform admin center.
DLP policy "Invoice Pipeline Governance" in the admin center.
Deployment pipeline "Invoice Pipeline" in Power Apps.
Pre-deployment approval cloud flow in the pipelines host environment.

Keep everything running

No action needed. Choose this if you are still actively iterating on the invoice solution or plan to deploy further updates through the pipeline.

The Test and Production sandbox environments remain active for future deployments.
The DLP policy continues governing connector usage across your three environments.
The pre-deployment approval flow stays active and triggers on any new Production deployments.
No recurring charges apply beyond your existing Power Platform Premium license.

Pause - I'll come back to this later

Shut down active processes while keeping your environments and configuration intact. This stops approval requests from firing unexpectedly while you are away.

In Power Automate, navigate to the pipelines host environment and open the pre-deployment approval flow.
Select Turn off on the command bar to disable the flow.
The sandbox environments and pipeline remain in place but idle. You can re-enable the flow at any time by selecting Turn on.

Delete - I don't want to use this again

Remove all project resources created during this project. Your development environment and unmanaged solution remain intact.

Delete the deployment pipeline:
In Power Apps (make.powerapps.com), open your unmanaged solution in the development environment.
Select Pipelines from the left navigation pane.
Select the Invoice Pipeline from the pipeline dropdown.
Select Delete on the command bar and confirm the deletion.

Delete the pre-deployment approval cloud flow:
In Power Automate, navigate to the pipelines host environment.
Open the pre-deployment approval flow.
Select Delete on the command bar and confirm.

Delete the DLP policy:
In the Power Platform admin center, select Security in the left navigation.
Select Data and privacy, then Data policies.
Select the Invoice Pipeline Governance policy.
Select Delete Policy and confirm.

Delete the Test environment:
In the Power Platform admin center, select Manage then Environments.
Select the ellipsis (...) next to your Test environment.
Select Delete, provide the confirmation data, and select Confirm.

Delete the Production environment:
Repeat the same steps for the Production environment.
Select the ellipsis (...) next to the Production environment.
Select Delete, provide the confirmation data, and select Confirm.

What stays after cleanup?

Your development environment, unmanaged solution, and custom publisher all remain intact. Only the target environments, pipeline configuration, DLP policy, and approval flow are removed.

Nice Work!

You have just built a complete Application Lifecycle Management pipeline for your Invoice Intelligence solution using Power Platform's native deployment tools. Your invoice processing components now move through governed stages from development to production.

You've learned how to:

Package a multi-component Power Platform solution with environment variables and connection references for portability across environments.
Deploy a managed solution through a multi-stage Power Platform Pipeline (Dev > Test > Production) and perform a managed solution upgrade with verified solution layers.
Create a DLP policy with connector classification (Business/Non-Business/Blocked) scoped to specific environments for connector governance.
Secret Mission: Wired a pre-deployment approval gate using pipeline gated extensions and a cloud flow triggered by Dataverse real-time events.

Ready to quiz yourself?