Power Automate - How to Fix Missing Dependencies

Its one of those dreaded moments, you click import solution and you get 'Missing Dependencies' so you can't import it, but fortunately there is a way (most of the time).

For starters what are missing dependencies, well they are components that are used in the solution but not in the solution or the environment. So missing dependencies from the solution is not an issue, as long as you have the dependency already in the environment. In fact its some times good practice to split out components like custom connectors and Dataverse tables, as these are often used by multiple different solutions.

1. How to Avoid Missing Dependencies
2. Find Missing Dependencies
3. Fix Missing Dependencies
4. Unmanage a Managed Solution

1. How to Avoid Missing Dependencies

Obviously the best time to fix missing dependencies is before you export the solution. To see missing dependencies you need to run the 'Solution Checker':

It can take a minute or two to complete, but it will show you all missing dependencies (along with any Canvas App checker errors).

It will explain the missing component type and name:

The solution.xml for the solution Missing Dependencies contains an unmanaged dependency on the Active solution with type EnvironmentVariableDefinition, schemaName , displayName wd_pollingsite. A solution will fail to import in a target environment when missing dependencies on unmanaged components are present.

This can also be set to run on export, where it will email you the report.

You can either then add them to your solution or ensure they are in the target environment. There is also the quick way 😎, and that's to use the 'Add required objects' option on each flow. This will automatically add all missing dependencies. Call out here if you have accidentally used wrong component (e.g. wrong connection reference), this will add it, when really you want to use the correct one in the flow, so always check what is added and not blindly add all.

That is all good if you own the unmanaged solution in an environment, but what happens if you don't, that's when the below tricks will help.

2. Find Missing Dependencies

You will see the list of missing dependencies when trying to import the solution, but there is another quicker easier way, and that's to look inside the solution file. Its just a zip file so you can look inside it, inside you will see the solution.xml file. Open it either in your web browser or text editor (like notepad or vs code), you will see xml tags, at the bottom will be your missing dependencies:

<Required type> = what is missing, you will see the display name to identify it and the unique id (schemaName,id,id.connectionreferencelogicalname,etc) and type (this is from the table entity id, more information can be found here)

<Dependent> = the component missing it, it will have all the same properties as the Required type.

3. Fix Missing Dependencies

Now we know the missing dependencies we can try and fix them, some are easier then others.

Missing Connection References

Connection references are probably the easiest, the way we fix it is by creating the connection reference in the environment (or in another environment and importing it first).

<MissingDependency>
<Required type="connectionreference" displayName="wd_SharePointPolling" solution="Active" id.connectionreferencelogicalname="wd_SharePointPolling"/>
<Dependent type="29" displayName="Missing D Flow" id="{5289985e-ab96-ef11-8a6a-6045bd09cc55}"/>
</MissingDependency>

So in the example above we need to create a connection reference with display name: wd_SharePointPolling and logicalname:wd_SharePointPolling, but first we need to find out what connection it is. For that we need to go into the flow and check. In the solution zip file we need to go to the 'workflows' folder and find the json file with the displayName (no spaces) and id. Once opened we look for the connection reference and see the type:

Above we can see its a SharePoint connection. The last thing we need is to make sure we have the same publisher in the environment (as this is the prefix to the id.connectionreferencelogicalname). The publisher name doesnt matter, just as long as it has the same prefix (wd in the example). We then create a new solution with that publish and create a new connection reference:

Missing Environment Variables

Environment variable definitions are very similar, we are again going to create our environment variable.

<MissingDependency>
<Required type="EnvironmentVariableDefinition" displayName="wd_pollinglist" solution="Active" id.schemaname="wd_pollinglist"/>
<Dependent type="29" displayName="Missing D Flow" id="{5289985e-ab96-ef11-8a6a-6045bd09cc55}"/>
</MissingDependency>

This time to key question is what type of variable, and that can be found, you guessed it, in the solution zip file. Again we look in the flow file, but this time it takes a little detective and guess work. The variables are at the top and even say which type, but the small challenge is data sources, as these show as strings.

If its not a guid then its a string, but if it is then we need to find where it is used and then guess. Below it is shown as table in a Get Items, so that will be a data source:

Then we follow same process and create the environment variable in the solution with the same publisher (it does not need to be right value/list, that will just stop it running not importing).

Missing Tables

Rinse and repeat again, this time to make the missing table. Simply create the table in the new environment. You can identify tables as the Required type="1".

<MissingDependency>
<Required type="1" schemaName="crb89_test" displayName="Test" solution="Active"/>
<Dependent type="29" displayName="Missing D Flow" id="{5289985e-ab96-ef11-8a6a-6045bd09cc55}"/>
</MissingDependency>

In our above example our table is called Test, so we need to create it with that name (Test and schemaName: crb89_test). You will also see the usual publisher prefix, so we need to make sure we create the table within a solution with a publisher with same prefix. Good news is even default environment ones, like crb89 can be created, just set a publisher to use it.

Quick tip, you can edit publishers, so you can temp switch and then switch back.

Missing Flows

This is where it gets a little difficult, because not only do we need to create a replacement flow, we have to set the id (process/workflowid).

<MissingDependency>
<Required type="29" displayName="childflow test" solution="Active" id="{8d8b1e3e-ab96-ef11-8a6a-6045bd09cc55}"/>
<Dependent type="29" displayName="Missing D Flow" id="{5289985e-ab96-ef11-8a6a-6045bd09cc55}"/>
</MissingDependency>

First create a template flow, this just needs to be a 'Manually trigger a flow' trigger and end with a 'Respond to a Power App or flow'.

Next you need to create a flow the will use the Dataverse actions to create a new flow based on the template flow. The reason we create a new flow is we need to set the process/workflowid to match the one in our solution. So in our example we need to create a flow with the workflowid/process value of 8d8b1e3e-ab96-ef11-8a6a-6045bd09cc55.

That's right, when you create a row you are not forced to let the guid be auto generated, you can set your own, and even have a little fun with it 😎

And that's it, we are now able to import the solution even though there were missing dependencies:

4. Unmanage a Managed Solution

Now because of the edits to the solution the flows will most likely not run, so you need to edit them. This is where a cool trick to convert a managed solution to unmanaged solution may be needed.

We are back in the solution zip file, but this time we need to edit it. First you copy the solution.xml from inside the zip file and paste it outside (you don't need to unzip the solution). Open the file in a text editor (like vs code) and then all you need to do is update the managed tag:

Then save the file, and copy and paste it back into the solution zip file (or drag it onto the zip) and then confirm copy and replace. The solution is now unmanaged and fully editable when you import it.

Dealing with managed dependencies is never fun, and it really should be delt with before it becomes an issue, good policies, training, alm process and code reviews should catch them before importing. But its also good to know that if your backs against the wall there are workarounds to at least get the solution imported and editable.

The example solution can be found here if you want to test/practice on it.