Run-after: catching failures gracefully

1. Run-after: catching failures gracefully

Every action has a hidden setting called run-after — by default it says "run if the previous step succeeded." That's why one connector hiccup kills the entire run. This video is about flipping that default.

2. There is no try-catch in Power Automate

There's no try-catch keyword in Power Automate. The mechanism for handling failure is per-action and it's called run-after. Every action carries a setting that says which statuses of the previous action should let this one run. The default is is successful, so if anything earlier fails, downstream actions never fire. Change that setting and you can build a branch that fires specifically because something failed. Run-after isn't a separate construct; it's a property you flip on actions you already have.

3. The four run-after states

There are four run-after states and a single branch can be configured to fire on any combination of them. Is successful is the default, which fires when the previous step finished green. Has failed fires on an action error, the workhorse for catching trouble. Is skipped fires when the previous step was skipped, which usually happens when a Condition didn't take that branch. Has timed out fires on long-running actions that exceeded their limit, which is distinct from failure because the error pattern is different. You'll mostly enable has failed and has timed out together for failure handlers.

4. Parallel branches as the failure-handler pattern

The standard pattern is a parallel branch. Right-click the action that might fail, usually a connector call like Send an email or Create item, and add a parallel branch alongside the existing downstream actions. On the parallel branch, open the run-after dialog and tick has failed and has timed out, untick is successful. The original downstream path keeps its default. Now, on a failure, the success path is skipped and the failure handler fires. Inside the handler, log the failure somewhere durable, like a SharePoint list, a Teams message, or an email to support, anywhere you'll actually see it.

5. The most common run-after bug

Here's where most run-after debugging starts. You build a parallel branch, point it at a SharePoint log, run a test, and the failure handler doesn't fire. The reason is almost always the same. Every new branch inherits the is successful default. When the previous step fails, the flow stops. The fix is to open the run-after dialog and explicitly tick the failure states.

6. Retries: parallel branches give you redundancy

Run-after isn't just for logging. It's also the mechanism for retries. Add a parallel branch with run-after set to has failed and put a second send-email action on it pointed at a different connector or a different mailbox. If the primary fails, the backup fires automatically. You can chain these to fall back twice, then log if both fail. Power Automate also has built-in retry policies on most connector actions in the Settings panel, separate from run-after, which handle transient errors.

7. Let's practice!

Time to add a failure-handler branch to the renewal flow.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.