How to Fix Policy Errors in auxiliary Flows?

In this article, we’ll explore what causes policy exception errors when turning on or saving Power Automate Flows that use DocJuris’ auxiliary Flows or any “Run a Child Flow” action.

 

DocJuris’ auxiliary Flows are pre-defined templates of complex actions that you can import to your environment and use as a “black box,” meaning that the complex actions are hidden and centralized. This allows you to:

  1. Perform complex actions without being concerned about how they work.
  2. Centralise standard practices so you can re-use them in all your Flows.
  3. Use them and take advantage of DocJuris’ expertise and speed up your Flow development

If you’re starting with Power Automate, you’ll want to check out our Overview of Power Automate guide.

 

Please note that this article is for Power Platform Administrators that manage the DLP (data loss prevention) policies for the organization, and therefore requires additional permissions to execute the changes. The solution requires you to have permission to access the administration panel; if you don’t, please forward this article to your administrator so that they can implement the changes proposed.

The Error

DocJuris’ auxiliary Flows require the use of an action called “Run a Child Flow”. This action will call another Flow with all the logic that can be conveniently called using only one action.

 

Unfortunately, some companies have a policy that blocks the usage of “Run a Child Flow”, albeit unintentionally, so if you try to use a “Run a Child Flow” action, even for the Flows built by you, you will get the following error:

 

proxyerror_SAM65_How_to_fix_policy_errors_in_auxiliary_Flows_copy_2.png

 

The exception looks complex, so let’s break it down into pieces. The first part tells us we don’t have permission to do something due to a “Policy Violation.” It tells us that there’s a policy in place (in the case of the example above called “AMERICAS”) that restricts the usage of the HTTP API (we’ll see what that means a bit later), and it’s a blocked connector.

 

This means that we’re trying to use an action that is blocked by our company. These policies are meant to prevent data loss and security reasons, so let’s look at how we can configure the policies to enable functionality without compromising security.

 

The Policy

Companies have policies in place that protect them from data loss. For example, some companies block the “Twitter” connector so that people cannot, accidentally or not, leak confidential information using Power Automate. These policies are managed centrally in the Power Platform Admin Center, so you need to be an administrator to see them.

 

One common policy is to block the “HTTP” connector. This connector allows for custom HTTP requests to be done using Power Automate. Companies don’t want just any person doing them, so it’s a useful policy to have in place to avoid unintentional damages to the company’s data.

 

But one unintentional side-effect of this policy is that it also blocks the “Run a Child Flow” action. Microsoft shares in the documentation that the “Run a Child Flow” shares some internal dependencies with the HTTP connector so the policy impacts both actions. It’s important to note that although they share internal dependencies, they operate in completely different ways. It’s only possible to run Flows using the “Run a Child Flow” shared or built by authenticated and authorized users in your organization. Also, since the child Flows need to follow the same rules as any other Flow, they are bound to the policies in place, ensuring the security of the data.

 

Calling the “Run a Child Flow” is like calling a Flow manually by a user, making them completely safe compared to the “HTTP” action.

 

To validate if the policy is in place:

  1. Navigate to https://admin.powerplatform.microsoft.com/
  2. Policies
  3. Data Policies

Open each of the existing policies and check if any of them have in the blocked group the “HTTP” connector.

 

Screenshot_2022-10-05_at_16_25_56.png

 

Note that this section could contain any number of connectors, depending on your company’s policies.

 

If this is the case for any policy, you found the cause for the exception above, so let’s look at how to fix it while keeping security in place.

How to Fix the Error

Since companies still want to keep the “HTTP” connection blocked and continue to prevent users from making calls using the “HTTP” action, we’ll need to use additional features of the policy to release the usage of the “Run a Child Flow” without having to compromise security. We will always need to enable the “HTTP” connector, but we can block all endpoints that the connector has access to, rendering it unusable while enabling the “Run a Child Flow” functionality.

 

To do this, we must first move the connector to a group that enables it, like the “Business” or “Non-business” group. The choice of what group to move it depends largely on the company’s strategy since the users can only create Flows with connectors from each group. This means that if you have DocJuris’ connector in the “Business” group as well as “Sharepoint,” you can create Flows with both; but if OneDrive for Business is in the “Non-business” group, it won’t be possible to use it in the same Flow.

 

To enable the “HTTP” connector, please do the following:

 

Select the three dots in the connector and select “Move to Business” or “Move to Non-business”.

 

Screenshot_2022-10-05_at_16_37_37.png

In our case, we’ll select “Non-business,” and since it’s the only one in the group, we’ll see an empty list.

Screenshot_2022-10-05_at_16_38_53.png

If you go to the “Non-business” group, you’ll see it there. You can search for it to find it faster.

 

Screenshot_2022-10-05_at_16_40_13.png

 

Now that it’s enabled, let’s block all endpoints to render it unavailable. To do this, first press the three dots in front of the connector. Then select “Configure Connector” and finally “Connector Endpoints.”

 

Screenshot_2022-10-05_at_16_40_51.png

 

You’ll see the following screen:

 

Screenshot_2022-10-05_at_16_42_24.png

 

As you can see in the above screenshots, it’s allowing all endpoints, and we want precisely the opposite, so let’s select “Deny” from the dropdown and press “Save”.

 

Screenshot_2022-10-05_at_16_43_42.png

 

Now that all configurations are done, we need to press “Next” until we reach “Update Policy”.

 

To validate if the policy is working, let’s look at the following demo Flow.

 

Screenshot_2022-10-05_at_16_53_11.png

 

In it, we’re using a “Run Child Flow” and an “HTTP” action, but since the policy is enabled, we’ll see the following exception:

 

Screenshot_2022-10-05_at_16_50_13.png

 

This means the HTTP action is blocked and cannot be run with the endpoint provided.

 

Screenshot_2022-10-05_at_16_50_04.png

 

Once we remove it and run the Flow, we’ll see that the “Run a Child Flow” will be run without any issues.