Govern the App with Error Handling and Pipelines

Add try/catch error handling and deploy your app as a managed solution via pipelines.

Introduction

30 Second Summary

When a critical government system fails at 2 AM, nobody wants to find out about it the next morning. Real-world operations demand instant failure alerts and controlled, repeatable deployments that prevent unauthorized changes.

In this project, you will refactor your weather API Cloud Flow with structured try/catch error handling, route failures to a dedicated Microsoft Teams notification channel, and deploy your complete solution as a managed package through a Power Platform Pipeline.

What You'll Build

A fully governed emergency deployment system with enterprise error handling and automated application lifecycle management.

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

Scope-based try/catch error handling in your weather API Cloud Flow that detects and routes failures automatically.
A Microsoft Teams breach notification channel receiving structured error alerts from your Cloud Flow.
A Power Platform Pipeline that deploys your entire solution as a managed package from development to a target environment.
Secret Mission: Add a Finally scope that posts a structured run summary to Teams on every flow execution.

Are there any prerequisites?

This project builds on Projects 1 and 2 in the series. You need a working Canvas App with a weather API Cloud Flow, a Dataverse deployment table with column-level security and auditing, a premium Power Platform license, and two Power Platform environments with Dataverse (one development, one target).

Before We Start

Before We Start...

Set Up the Breach Notification Channel and Managed Environment

When a Cloud Flow fails in production, operations teams need immediate visibility into what went wrong. Without structured alerting, failures go unnoticed until users report problems.

In this step, you'll prepare the infrastructure for structured error handling and automated deployment. You'll create a dedicated Microsoft Teams notification channel, enable your target environment as a Managed Environment, and verify your existing solution is ready for the governance work ahead.

In this step, get ready to:

Create a Microsoft Teams breach notification channel.
Enable the target environment as a Managed Environment.
Verify the existing solution components in the development environment.

Create a Teams channel for breach notifications

Your error handling flow will post failure alerts to a dedicated Teams channel. This keeps breach notifications separate from day-to-day team conversations and gives operations staff a single place to monitor.

Open Microsoft Teams. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar, then type Teams and press Enter.
In the left sidebar, select Teams to see your list of teams.
Locate the team you want to use for operations notifications.
To the right of the team name, select More options (...), then select Add channel.
In the Channel name field, type Breach Notifications.
For the channel type, select Standard.
Select Create.
Note the team name and channel name. You will need both when configuring the Cloud Flow notification action later.

Why a standard channel?

The Power Automate Teams connector does not support posting messages to private channels. Your breach notification channel must be a standard (public) channel within the team for the Flow bot to deliver alerts successfully.

Don't see the Add channel option?

Your organization's admin may have restricted channel creation to team owners only. Check with your IT admin to get the right permissions, or ask a team owner to create the channel on your behalf.

Help me get permissions to create a Teams channel

Enable the target environment as a Managed Environment

Power Platform Pipelines require target environments to be enabled as Managed Environments. This unlocks deployment, governance, and compliance capabilities needed for automated solution delivery.

Open your browser and go to admin.powerplatform.microsoft.com.
Sign in with your Power Platform administrator credentials.
In the left navigation, select Environments.
Select your target (second) environment from the list.
Select Enable Managed Environments (if not already enabled).
Review the settings on the configuration panel, then select Enable to confirm.

What is a Managed Environment?

A Managed Environment is a suite of premium Power Platform capabilities that provide greater visibility, control, and governance over an environment. Enabling it is a prerequisite for using Power Platform Pipelines to deploy solutions to that environment.

Starting February 2026, Microsoft began auto-enabling Managed Environments for pipeline targets. Your environment may already show as managed. If it does, you will see Edit Managed Environments instead of an enable option. In that case, no action is needed.

Confirm the environment now shows Managed in its status on the Environments list.

Don't see the Enable Managed Environments option?

You need the Power Platform Administrator or Dynamics 365 Administrator role in Microsoft Entra ID to enable Managed Environments. Users with the Delegated Admin or Environment Admin role cannot change this property. Contact your tenant admin if needed.

Also verify that Dataverse is provisioned in the target environment. Dataverse is required for Managed Environments.

Help me enable Managed Environments in the admin center

Verify the existing solution in the development environment

Before adding error handling and deploying through a pipeline, you need to confirm all components from your previous projects are present in the solution. Missing components would cause deployment failures later.

Open your browser and go to make.powerapps.com.
In the top-right environment selector, confirm you are in your development environment.
In the left navigation, select Solutions.
Open your emergency deployment solution by selecting its name.
Verify the solution contains the following components: the Canvas App, the weather API Cloud Flow, the Dataverse deployment table (with security profiles), and environment variables.

Why verify before building?

Power Platform Pipelines deploy the entire solution as a single managed package. If a component is missing from your solution, it will not be included in the deployment artifact.

Catching gaps now prevents confusing deployment errors later. Only published components are exported during pipeline deployment, so ensuring everything is present and accounted for is essential.

Missing a component from your solution?

If any of the expected components are not listed, you can add them. Select Add existing from the solution command bar, choose the component type (App, Cloud Flow, Table, etc.), and add it to the solution.

Help me add missing components to my solution

Your notification channel is ready, your target environment is managed, and your solution is verified. Next up, you'll refactor the weather API Cloud Flow with structured try/catch error handling using Scope blocks.

Refactor the Weather API Flow with Try/Catch Scopes

Your environments are configured and the breach notification channel is ready. Now it's time to make your weather API Cloud Flow resilient to failures.

By default, a Cloud Flow that hits an error simply fails and stops. In a government-grade system, silent failures are unacceptable. You need the flow to detect problems, contain them, and report them. The Scope action in Power Automate lets you group actions together and define exactly what happens when that group succeeds or fails.

In this step, get ready to:

Open the weather API Cloud Flow for editing.
Wrap your existing weather API actions inside a Try scope.
Add a Catch scope configured to run only when the Try scope fails.

Open the weather API Cloud Flow in the development environment

Return to make.powerapps.com and confirm your development environment is selected in the environment picker at the top right.
Select Solutions from the left navigation pane.
Open your emergency deployment solution.
Find your weather API Cloud Flow in the solution components list and select it.
Select Edit to open the flow in the designer.

You should see the flow designer with your existing trigger and the HTTP action that calls the weather API.

What does the flow currently look like?

Your flow has a trigger at the top followed by the HTTP action (and any response-processing actions) that call the weather API. Right now, if the HTTP action fails, the entire flow just stops with an error. No notification, no recovery path.

Create a Try scope and move existing actions into it

A Scope groups multiple actions into a single logical unit. You will create a "Try" scope to hold your weather API actions, so the flow can detect if anything inside that group fails.

Below the trigger, click the plus sign (+) and select Add an action.
Search for Scope in the search bar.
Under the Control category, select Scope.
Rename this scope to Try - Weather API Call by selecting the scope title and typing the new name.
Move (cut and paste) your existing weather API HTTP action and any response-processing actions into this Try scope.

Moving actions into a scope

In the new designer, you can drag actions directly into the scope. Alternatively, select an action, use the three-dot menu (...) to cut it, then click the plus sign inside the scope and paste it there.

Why wrap actions in a scope?

When a scope fails, it reports a single Failed status for the entire group. This lets you handle the failure as one event rather than checking each individual action.

Think of it like a try block in traditional programming. Everything inside the scope either completes successfully or triggers a known failure path.

Your designer should now show: Trigger at the top, then the Try - Weather API Call scope containing all your weather API actions.

Actions disappeared after moving?

If your actions appear to be missing, click the scope header to expand it. Scopes collapse by default. If an action ended up outside the scope, drag it back inside or use cut and paste again.

Help me troubleshoot moving actions into a scope in Power Automate.

Create a Catch scope configured to run on failure

The Catch scope is where your error-handling logic will live. The key configuration is its Run After settings, which tell it to execute only when the Try scope fails or times out.

Below the Try scope, click the plus sign (+) and select Add an action.
Search for Scope and under Control, select Scope.
Rename this scope to Catch - Error Handling.

Now configure the Run After settings so this scope only fires when the Try scope fails.

Select the Catch - Error Handling scope to open its configuration pane on the left.
Navigate to the Settings tab in the configuration pane.
Find the Run After section.
Select the Try scope (Try - Weather API Call) as the preceding action.
Check only has failed and has timed out.
Uncheck is successful if it is selected.

What is Run After?

Run After defines the conditions under which an action executes relative to the preceding action. The four options are: is successful, has failed, is skipped, and has timed out.

By checking only "has failed" and "has timed out", you ensure the Catch scope runs exclusively when something goes wrong. If the Try scope succeeds, the Catch scope is skipped entirely.

After saving these settings, you should see a red dotted connector line between the Try scope and the Catch scope. This visual indicator confirms the Catch scope only runs on failure.

Save the flow by selecting Save in the top right of the designer.

Don't see the red dotted connector?

If the connector line between scopes is solid (not dotted and red), the Run After settings are still set to "is successful". Go back to the Catch scope's Settings tab and confirm that only "has failed" and "has timed out" are checked.

Help me configure Run After settings on my Catch scope in Power Automate.

What about the maximum nesting depth?

Power Automate supports a maximum of 8 nested levels of actions (including scopes, conditions, switch cases, and apply-to-each loops). Your try/catch pattern uses two top-level scopes side by side, not nested inside each other. This is well within limits.

Your flow now has structured error containment. The Catch scope is empty for now. In the next step, you will wire up a Teams notification inside it so failures are automatically reported to your breach notification channel.

Wire Up the Teams Breach Notification

Your Try/Catch structure is in place, but right now the Catch scope is empty. A failed flow that silently swallows errors is worse than no error handling at all.

In this step, you will add a Microsoft Teams notification inside the Catch scope so that every weather API failure posts a structured breach alert to your team's channel. Then you will deliberately break the flow to prove the pattern works.

In this step, get ready to:

Add the Teams notification action inside the Catch scope.
Compose a structured breach notification message with dynamic expressions.
Test the error handling by simulating a failure and verifying the Teams alert.

Add the Teams notification action inside the Catch scope

The Catch scope currently has no actions inside it. You need to give it something useful to do when a failure arrives from the Try scope.

Inside the Catch - Error Handling scope, click the plus sign (+) and select Add an action.
In the search bar, type Post a message in a chat or channel.
Select Post a message in a chat or channel under the Microsoft Teams connector.
In the Post as dropdown, select Flow bot.
In the Post in dropdown, select Channel.
In the Team dropdown, select the team containing your Breach Notifications channel.
In the Channel dropdown, select Breach Notifications.

What does this configuration do?

The Flow bot posts messages on behalf of the flow itself, not your personal account. This means the notification arrives even if you are offline.

Posting to Channel ensures the entire operations team sees the alert, not just one person in a private chat.

Use a standard channel

The Teams connector does not support posting to private channels. Make sure your Breach Notifications channel is a standard (public) channel within the team.

Compose the error notification message

A useful breach notification needs more than just the word "error." You will compose a structured message that tells the operations team exactly what went wrong, when, and in which flow.

Click into the Message field of the Teams action you just added.
Type the following header line:

BREACH NOTIFICATION: Weather API Flow Failure

Press Enter to start a new line, then type Timestamp: followed by inserting the expression below.
To insert an expression, click the fx (expression) button in the dynamic content panel, paste the expression, and select OK.

utcNow()

Press Enter again, type Flow name: and insert this expression:

workflow()['name']

Press Enter again, type Error details: and insert this expression:

result('Try_-_Weather_API_Call')

What do these expressions do?

`utcNow()` returns the current UTC timestamp so you know exactly when the failure occurred.
`workflow()['name']` returns the name of the current flow. This helps identify which flow failed when you have many flows running in your environment.
`result('Try_-_Weather_API_Call')` returns an array of action results from inside the Try scope. It includes the status, inputs, outputs, and error codes for every action in that scope.

Why use result() instead of outputs()?

The result() function is designed for scoped actions. It returns all inputs and outputs from the top-level actions inside a specified scope.

This gives you full visibility into which action failed and why, without needing to reference each action individually.

Save the flow by clicking Save in the command bar.

Seeing a validation error on save?

Make sure each expression was entered through the fx expression editor, not typed as plain text. Plain text is not evaluated at runtime.
Check that the scope name inside result() exactly matches Try_-_Weather_API_Call with spaces replaced by underscores and hyphens kept.
Confirm the Teams action has a team and channel selected. An empty dropdown causes a save error.

Still stuck? Help me fix a save error on my Teams notification action.

Test the error handling by simulating a failure

The best way to prove error handling works is to intentionally break something. You will temporarily corrupt the weather API URL, trigger the flow, and confirm the breach notification arrives in Teams.

Inside the Try - Weather API Call scope, select the HTTP action that calls the weather API.
In the URI field, append /invalid to the end of the existing URL. This forces a 404 error on the next run.
Click Save to save the modified flow.
Click Test in the top-right corner of the flow editor.
Select Manually and click Test to trigger a test run.
Wait for the run to complete.

The flow run view should show the Try - Weather API Call scope as Failed (red) and the Catch - Error Handling scope as Succeeded (green).

Switch to Microsoft Teams and open the Breach Notifications channel.
Verify that a message from the Flow bot appears containing your header, timestamp, flow name, and error details.

What should I see in Teams?

The message starts with BREACH NOTIFICATION: Weather API Flow Failure followed by a UTC timestamp, the flow name, and a JSON array showing the failed action status along with its inputs and outputs.

The JSON output from result() may be verbose. That is expected and gives operations staff the detail they need to diagnose the failure.

Return to the flow editor and remove /invalid from the HTTP action URI to restore the correct weather API URL.
Click Save to save the restored flow.

No message in the Teams channel?

Open the flow run details and expand the Catch scope. If the Teams action shows Failed, check that the team and channel are correct and that the channel is a standard (not private) channel.
Make sure the Catch scope's Run After is set to the Try scope with only has failed and has timed out checked. If is successful is also checked, the scope may have run prematurely on a previous successful test.
Verify you have permission to post in the channel. Ask your Teams admin if the Flow bot is blocked in your tenant.

Still not seeing the notification? Help me debug why my Catch scope is not posting to Teams.

Your weather API flow now has a fully working safety net. Every failure automatically alerts the team with structured details. Next up, you will configure a Power Platform Pipeline to deploy this solution to a target environment.

Configure a Power Platform Pipeline

Your weather API Cloud Flow now catches failures and sends breach notifications to your Teams channel automatically. The next goal is getting your entire solution out of development and into your target environment safely.

Manually exporting and importing solutions is error-prone. Power Platform Pipelines automate the deployment process, ensuring the same solution artifact reaches your target without tampering or modification.

In this step, get ready to:

Navigate to the Pipelines page within your solution.
Create a personal pipeline linking development to a target environment.
Verify the pipeline configuration shows the correct source and target.

Navigate to the Pipelines page

Pipelines live inside unmanaged solutions in your development environment. You cannot access them from managed solutions or target environments.

In make.powerapps.com, confirm you are in your development environment using the environment switcher in the top-right corner.
Select Solutions from the left navigation pane.
Open your emergency deployment solution.
Select Pipelines from the left navigation pane.

What is the Pipelines page?

The Pipelines page is where you create, manage, and run deployment pipelines for your solution. You can also reach it by selecting Overview from the left navigation pane and then selecting Deploy on the command bar.

Create a personal pipeline to the target environment

A personal pipeline uses the platform host to connect your development environment to up to two target environments. No file downloads or uploads are involved.

Select Create pipeline on the command bar (or from the Pipeline dropdown list).
A panel opens with fields for the pipeline configuration.
In the Pipeline name field, enter Emergency Deployment - Dev to Production.
In the Target environment dropdown, select your second environment (the one you enabled as a Managed Environment in Step 1).
Select Save to create the pipeline.

Why does only my Managed Environment appear?

The target environments list is filtered to show only environments where you have import access and that are enabled as Managed Environments. If your target environment does not appear, verify that it is enabled as a Managed Environment in the Power Platform admin center.

Why a personal pipeline instead of a custom host?

Personal pipelines use the platform host, which is simpler to set up and does not count toward Dataverse capacity. The tradeoff is they cannot be extended with gated approvals or shared with other users.

For an individual maker learning ALM concepts, the platform host is the right fit. Enterprise teams with multiple developers would use a custom host instead.

Verify pipeline association

After saving, the pipeline is created and your environments are associated with the platform host automatically.

Confirm the newly created pipeline appears on the Pipelines page within your solution.
Verify the source environment (your development environment) and target environment are correctly listed.
The pipeline is now ready to deploy your solution as a managed package to the target environment.

Don't see the pipeline on the page?

Make sure you are viewing the Pipelines page from within your unmanaged solution in the development environment. Pipelines cannot be viewed from the default solution, managed solutions, or target environments.

If the Create pipeline option was not available, your environment may already be associated with a custom host configured by your admin. Contact your Power Platform administrator to verify.

help me troubleshoot why my pipeline is not showing up

Your pipeline is configured and ready to go. Next up, you'll use this pipeline to deploy your entire emergency deployment solution as a managed package to the target environment.

Deploy the Managed Solution via the Pipeline

Your pipeline is configured and ready to go. Now it is time to use it for what it was built for: deploying your entire emergency deployment solution to the target environment as a managed solution.

Before deploying, you need to publish all your customizations. Power Platform Pipelines do not automatically publish unpublished changes, so anything left unpublished will be excluded from the deployment.

In this step, get ready to:

Publish all customizations and increment the solution version.
Deploy the solution through the pipeline to the target environment.
Verify the managed solution arrived intact in the target environment.

Prepare the solution for deployment

Only published components are included when a solution is exported. If you made any changes during the error handling steps that you haven't published yet, those changes will be missing from the deployed solution.

In make.powerapps.com, return to your emergency deployment solution in the Solutions area.
Select Publish all customizations from the solution command bar.

Why publish before deploying?

When you export an unmanaged solution, only published components are exported. Pipelines do not publish unmanaged customizations before exporting.

This means if you skip publishing, your Try/Catch error handling changes or any other recent edits could be silently excluded from the deployment.

Next, you need to increment the solution version number so the target environment recognizes this as an update.

Select the solution settings (gear icon) to open the solution properties.
Find the Version field. It uses the format major.minor.build.revision.
Update the version number to a higher value (for example, from 1.0.0.0 to 1.1.0.0).
Select Save to confirm the version change.

What is solution versioning?

Solution versions follow the major.minor.build.revision format. Updates must have a higher value in at least one of these fields than the parent solution already deployed in the target.

Deploy through the pipeline

With everything published and versioned, you can now trigger the pipeline to export and deploy the solution as managed to your target environment.

From the solution's Pipelines page in the left navigation pane, or select Overview from the left navigation pane and then select Deploy on the command bar.
Select Deploy to begin the deployment process.
Review the deployment summary showing the solution components that will be deployed.
The pipeline validates connections, environment variables, and target environment readiness.
Confirm and initiate the deployment.

What happens during pipeline deployment?

Solutions are exported as soon as a deployment request is submitted and the same solution artifact will be deployed. The system prevents any tampering or modification to the exported solution artifact.

The solution is automatically exported as managed and deployed to the target environment. You do not need to manually export it yourself.

Wait for the deployment to complete. You should see a success status once the pipeline finishes deploying your solution to the target environment.

Deployment failed?

Make sure your target environment is still enabled as a Managed Environment. Pipeline targets must be Managed Environments.

Confirm that you published all customizations before deploying. Unpublished changes can cause validation failures.

Check that you have import access to the target environment.

Help me troubleshoot my pipeline deployment failure

Verify the managed solution in the target environment

The deployment is done, but you need to confirm everything arrived correctly. A managed solution locks components from editing, which is the expected behavior for production environments.

Switch to your target environment using the environment selector in the top-right corner of make.powerapps.com.
Open Solutions from the left navigation.
Confirm your emergency deployment solution appears in the list with the Managed label.
Open the managed solution and verify it contains: the Canvas App, the weather API Cloud Flow (with Scope-based error handling), Dataverse tables, and security profiles.

Why can't I edit anything in this solution?

You cannot directly edit the components within a managed solution. This is intentional. Managed solutions protect production environments from ad-hoc changes.

All changes must flow through the pipeline from your development environment. This ensures every modification is tracked, versioned, and deployed consistently.

You should now see your complete emergency deployment solution deployed as a managed solution in the target environment, with all components intact and read-only.

Secret mission

Add a Finally Scope with Structured Run Summary

Your Try/Catch pattern handles failures, but operations teams need visibility into every run. Add a Finally scope that posts a structured run summary to your Teams channel on every flow execution, regardless of outcome. This gives complete operational visibility without requiring manual log checks.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses resources included with your existing Power Platform premium license, so there are no ongoing costs beyond what you already pay.

Resources you used:

Microsoft Teams "Breach Notifications" channel (no cost, persists in your Teams workspace).
Power Platform Pipeline configuration (no additional cost, stored in platform host).
Managed solution in target environment (uses Dataverse capacity included with your premium license).

Keep everything running

No action needed. Choose this if you are still actively building or want to continue iterating on the solution.

The pipeline and managed solution remain available in their respective environments.
No ongoing charges beyond your existing premium license.
The Cloud Flow in the target environment will be active and trigger as configured.
The Breach Notifications channel continues receiving messages from flow executions.

Pause - I'll come back to this later

Shut down running processes to avoid unnecessary flow executions while keeping your configurations intact.

Switch to the target environment in make.powerapps.com.
Open the managed solution and select the weather API Cloud Flow.
Turn off the Cloud Flow so it does not actively trigger.
The pipeline and managed solution remain configured but dormant until you are ready to return.

Delete - I don't want to use this again

Remove all project resources completely. This cannot be undone for the managed solution.

Delete the managed solution from the target environment: switch to the target environment in make.powerapps.com, open Solutions, select the emergency deployment managed solution, then select Delete. This removes all deployed components (Canvas App, Cloud Flows, Dataverse tables, security profiles) from the target environment.
Delete the pipeline: in the development environment, open your solution, select Pipelines from the left navigation pane, select your pipeline, then select Delete.
Delete or archive the Teams channel: in Microsoft Teams, right-click the Breach Notifications channel and select Delete this channel (or Archive if you want to preserve the message history).

Nice Work!

Nice work! You've just built a fully governed emergency deployment system with enterprise error handling and automated ALM using Power Platform.

You've learned how to:

Refactored a Cloud Flow with structured Scope-based try/catch error handling and wired failures to a dedicated Microsoft Teams breach notification channel.
Created a personal Power Platform Pipeline linking a development environment to a Managed Environment target.
Deployed the complete emergency deployment solution as a managed solution containing the Canvas App, Dataverse tables, security profiles, and Cloud Flows.
Secret Mission: Added a Finally scope that posts a structured run summary on every flow execution, providing complete operational visibility.

Ready to quiz yourself?