Calling Cloud flows from Power Automate Desktop

At this point, we are well versed in calling a Power Automate Desktop flow from a cloud flow. As part of this call, we can pass in inputs and receive outputs from the desktop flow. This works well when the cloud flow is orchestrating the desktop flow process, but what if the desktop flow needs to reach out to a different cloud flow? For example, what if we are in the middle of our desktop flow and we want to call an AI Builder model? We don’t want to fully return context back to the calling cloud flow as that will log us out of our existing desktop session and we won’t have a way to resume the desktop session. Instead, we can use the Invoke web service action found in Power Automate Desktop to call the HTTP Request trigger found in a cloud flow. However, as we will experience, there are a few nuances that we need to be aware of.

Cloud flow

Let’s first setup a simple cloud flow that exposes an HTTP Request trigger and provides an HTTP Response. We will Use sample payload to generate schema. In this case we will pas a simple file name that represents a file name that we want to pick up from a local folder so we can send it to AI Builder.

Note: For the purposes of this post, we won’t include the AI Builder functionality.

Desktop flow

Inside our Desktop flow we will add the Invoke web service action to our canvas. The first thing we need to do is to retrieve our HTTP POST URL from our Cloud flow. We will insert this value into URL textbox. However, when we paste this value, we will quickly discover that we have a syntax error. The result of this is due to the % being part of our URL. As you may know, % is a reserved character within Power Automate Desktop as it is used with variables.

The reason why these characters exist is that the URLs have been encoded. %2F represents ‘/’ character. To avoid this error, what we can do is replace %2F with / as part of our updated URL.

By default, a cloud flow will expose an HTTP Trigger to use a Post method, so we will set that method in our desktop flow. In addition, we can set our Accept and Content-type to application/json. We will set our Request body to something that matches the sample body that we specified in our cloud flow.

However, when we go to run this desktop flow, we run into an error:

{"error":{"code":"InvalidRequestContent","message":"The request content is not valid and could not be deserialized: 'Unexpected character encountered while parsing value: %. Path '', line 0, position 0.'."}}

The good news is that there is an easy fix. If we expand the Advanced tab, we can turn off the Encode request body.

When we do turn the Encode request body setting off, we can successfully send our message body to our cloud flow. We will subsequently get our result back from our cloud flow.

Conclusion

Generally, we see cloud flows calling desktop flows more than the other way around. However, there are some good reasons to have a desktop flow call a cloud flow. One of these reasons is so we can take advantage of all the connectors that are found in cloud flow, such as AI Builder. We can try to call the AI Builder APIs in desktop flows but would have to subsequently figure out all the authentication required to call that service.