Power Automate: Respond to a PowerApp or flow Action

The “Respond to a PowerApp or flow” action is not very useful for single running Flows, but when you create “Helper Flows,” you need this action.

Let’s think of an example to understand the concept better. You have a Flow that triggers when a new item is created in a SharePoint list; you collect the information and then save it to a file—nothing fancy here. But let’s say that you have a flow specializing in keeping the information in files in a certain way. You want to develop once and use it in multiple places. You can use a “Run child Flow” action to call this Flow in various actions. So far, so good.

But how will the “parent” Flow know that the “child” Flow finished? First, you need an action that indicates that it ended processing.

What about if we need to provide information back to the parent or a Power App invoking this Flow?

For all these cases, we’ll use the “Respond to a PowerApp or flow” action. It will always be used at the end of your Flows, and it will help you provide information back to the parent Flow or Power App about the status of the Flow.

Where to find it?

To find it, you can search for the “Respond to a PowerApp or flow” action or going to the “Built-in” section.

Select the “Respond to a PowerApp or flow” action.

This is what is looks like:

Although it’s under the Power App tab, it’s not only used for Power Apps. So, for example, if you have “Helper Flows” that are called by other Flows, then you’ll need this action, even if you’re not interacting with any Power App.

Usage

The output selection looks a lot like the “Manually Trigger a Flow” trigger, where you can pick the type of data that you’re returning.

You can call this action without any parameters, but it’s always to have at least one with a return code. It’s a good practice to use HTTP status codes since they are standards. You know some like 404 (not found), but others are pretty useful:

1. 200 (OK) – If everything goes well in your Flow.
2. 404 (Not found) – If your Flow is trying to find something, like information based on an ID, for example, return this.
3. 400 (Bad Request) – When your Flow is doing something to the data, for example, converting something into something else, but there’s an error in the process.

Limitations

You should understand that the “Respond to a PowerApp or flow” action will provide information back to the Flow called it, but this doesn’t mean that the Flow will end there. Although, if you’re a developer, you understand the concept of a “return” where anything after that won’t be executed, this is not the case.

There is also a limitation with the action regarding datatypes. Regardless of the type, you choose you’ll always get a string returned.

Recommendations

Here are some things to keep in mind.

Call the action as soon as you can

Since Power Automate will return to its parent Power App of Flow when the action is processed, you should call it as soon as possible. It’s counter-intuitive, but this action will say to the “parents,” “go ahead, here’s the data that you need,” so it doesn’t make sense for the “parents” to wait for the Flow to finish running other actions when it already has the information that it needs. If the “child” Flow has more actions and they take a long time but don’t impact or are not related to the parents, you gain a lot of performance by running the action early.

Call the action when it’s “OK to proceed.”

As a counterbalance to the previous recommendation, be aware that if you run the action and the following fails, the parent won’t know about it since you provided the information back. If you want the parent Flow to run only after the child Flow is finished completely and successfully, then you need to have the “Respond to a PowerApp or flow” action to be the last one to execute.

It’s a balance between performance and having the information consistent so keep this in mind.

Ensure that you have on action for all paths

If you have multiple paths for your Flow, for example, if all runs correctly and another if there’s an error, be sure to have one “Respond to a PowerApp or flow” action for each of them.

If you call this using a “Run Child Flow” action and have a path that doesn’t have a “Respond to a PowerApp or flow” action, then your parent Flow will wait for the child Flow to finish but, since it doesn’t get any response, it will end up timing out.

Don’t always return OK.

Use the parameters and return error messages if something goes wrong. It doesn’t make sense to have a failing child Flow return that all is OK to the parent Flow. The parent should know when there’s an error so that it can react to it. Also, if you have a Power App, you would want to show the user that something went wrong, so don’t be optimistic here. Always be realistic, deal with errors and inform people that something went wrong.

Don’t always return strings.

If you have a number, return a number and not a string—the same for dates or other data types. Defining the data type will help other Flows or Power Apps know the type and react to it without having to do conversions of data.

Always return at least the status code.

Although you can return an empty “Respond to a PowerApp or flow,” I would advise you to have always a code that tells the parent not only that the child Flow finished, but how it finished.

Like I mentioned above, use HTTP status codes to keep things standard. Other people that use your Flow will understand what 200 means, but they won’t understand what “255-44” means without looking at a reference.

If you can return a message as well as a code

Suppose you can return a message with the error code. The message should be short but descriptive of what happened so that the people using your Flow will understand how they need to react to errors, for example.

It’s a lot nicer to have a message like this one, even if you don’t show the message to anyone. Then, if someone else is using your “child” Flow, they will understand by the messages what’s happening without needing to check a reference or open the “child” Flow to know why a file was not created.

You can hard-code the messages and errors.

It’s perfectly OK that you put the messages in the “Respond to a PowerApp or flow” action, like this:

But I would recommend having variables if you have a complex Flow that uses many of the “OK” returns. If you have to change it, it will be painful to change all “Respond to a PowerApp or flow” actions, not to mention that you may forget to change one and generate issues.

Keep things generic and always return something.

Reading the suggestions above, you’re tempted to have something like this:

But how about if nothing goes wrong? You can have both the “Error Code” and “Error Message” empty but let’s look at the parent Flow and how it would parse the return:

Since it’s empty, we need to have the “Default” condition to catch the “empty” return. But now, let’s think of adding another error code—”404,” for example. If you forget to add a “case” condition, then you’ll have the “404” going to the “Default” case as well, and this is a problem since you’re considering an error as an OK message. Now let’s think if you “always” define an error message. Then, you can have something like this:

You’re constantly parsing the “OK” and the “Error” messages, and if something goes to the default, then you can alert someone that something’s wrong. So, even if someone adds a new error message, the issue won’t go unnoticed.

Name it correctly

The name is super important in this case since we’re returning information to the parent, but what information? Are we returning an error or a success message? Always build the name so that other people can understand what you are using without opening the action and checking the details.

Always add a comment.

Adding a comment will also help to avoid mistakes. We’re returning information outside this Flow, but what information? Is this an error or a success message? What’s the point?. It’s important to enable faster debugging when something goes wrong.

Always deal with errors.

Have your Flow fail graciously and notify someone that something failed. It’s horrible to have failing Flows in Power Automate since they may go unlooked for a while or generate even worse errors. I have a template, and a template that you can use that will help you make your Flow resistant to issues. You can check all details here.

Thanks!

2022-02-16: I want to thank navarrorc in the comments and @PA4Beginners on Twitter for submitting the limitation on the data types.

Back to the Power Automate Action Reference.

Photo by Hadija Saidi on Unsplash