Photo by Clint Patterson on Unsplash

Upgrading Power Automate Desktop to v2 schema

The announced with the February 2023 release, new Microsoft Dataverse schema for storing Power Automate Desktop data, so called “v2”, requires all desktop flows to be upgraded by Q1 2024. I did this already and faced several challenges, that I would like to share with you.

The new v2 schema “makes working with Dataverse APIs easier and enables future product enhancements with desktop flows. The new storage schema is publicly available along with Power Automate for desktop (v2.29)” and newer. Read more about it here:

Steps to upgrade to v2 schema

  1. Install the latest Power Automate Desktop client (must be v2.29 or newer).
  2. Upgrade Power Automate browser extension so that it uses Manifest V3 before July 2022 (
Manifest V3 extension

  1. In the Power Platform Admin Center go to Environments > Settings > Product > Features > Enable storage of desktop flow files into v2 schema and turn to “On”:
Enable desktop flow schema
  1. Open and save every desktop flow that you want to upgrade to v2 schema.
  2. If you plan to move desktop flows to another environment, go to solutions where they are stored and click to add required objects.
Add required objects for a desktop flow
  1. This will add “Desktop Flow Binaries” to your solution which if missing will cause the flow to fail once executed. The number of binaries may vary. For large desktop flows it may even be close to 100.
Desktop Flow Binary

And this is that simple!

Issues after the upgrade

The issues I faced in the whole upgrade process were related to situations after the upgrade was completed. Basically – around running upgraded processes. And mostly because the list of Desktop Flow Binaries was incomplete in a deployed solution or they were re-added after another deployment.

Newly upgraded desktop flows were failing due to the errors mentioned below (just examples, may be incomplete):

  "error": {
    "code": "MalformedFlowError",
    "message": "Malformed flow detected: ControlRepository"

There were as well other errors related to XrmApiRequestFailed, eg.:

Encountered an unexpected error during Desktop flow initialization: 'Microsoft.Flow.RPA.Desktop.Robin.Core.Packager.Exceptions.PackagerValidationException: A validation error occurred during project unbundling.
at Microsoft.Flow.RPA.Desktop.Robin.Core.Packager.ProjectValidator.CreateAndReturnFinalValidationResult()
at Microsoft.Flow.RPA.Desktop.Robin.Core.Packager.ProjectValidator.ValidateProject()
at Microsoft.Flow.RPA.Desktop.Robin.Engine.Packager.PackageProvider.<>c__DisplayClass12_0.b__0()
at Microsoft.Flow.RPA.Desktop.Robin.Engine.Packager.PackageProvider.ExecuteAndLogOperation(String methodName, Action action, Func1 func) at Microsoft.Flow.RPA.Desktop.Robin.Engine.Packager.PackageHelper.PackProjectToDirectory(Project project, String directory, Guid flowId) at Microsoft.Flow.RPA.Agent.Server.Components.ScriptEngines.RobinEngine.DataResolvers.DataResolverV2.GetFlowDataAndSetState(Guid scriptId, Guid runId, Dictionary2 flowInfoCache, String directory)
at Microsoft.Flow.RPA.Agent.Server.Components.ScriptEngines.RobinEngine.RobinScriptProvider.ResolvePackagePath(Guid flowId)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Flow.RPA.Agent.Server.Components.ScriptEngines.RobinEngine.RobinEngine.d__21.MoveNext()'.

However they were really confusing and thus I thought they are all related to the upgrade process.

Resolving the issues

First thing is to check if you have completed steps 5 and 6 above, so that your solution contains Desktop Flow Binaries. If it does, but is still failing, possibly the number of binaries between your dev and prod environments varies. If this is the case then you can try to import the solution manually, by using classic interface:

Swotch to classic interface

And then choose Upgrade (as this action should delete components not present in your new deploy, so in this case the additional Desktop Flow Binaries) and Overwrite customizations (just to be sure no unmanaged layers are interfering with new version):

Classic solution import

However, if this approach doesn’t work either, then the only solution I found is to delete existing solution and to deploy it again.

Pattern to re-run desktop flow if response code is 400

It often happens, that a desktop flow instance fails and the action in a cloud flow which triggered RPA shows “bad request” (400) status code in a response. Some of the possible reasons and possible solutions you can find here. But the number of possible reasons is much bigger. You can find all possible errors under Desktop flow activity report:

Desktop flow activity report errors

But often you would like that the RPA is re-submitted, not ended with failure. You can follow my approach to create a cloud flow, that triggers desktop flow if it ends up with 400:

Pattern to run desktop flow as long as it ends up with bad requests

  1. Variable var_BotStatus is used to control the loop. It is initiated with value “Error”.
  2. Loop runs as long as the var_BotStatus is equal “Error”, but…
  3. No longer than 1 hour or 4 times – that is to prevent the whole process to run endlessly.
  4. If action that triggers RPA ends up with an error, left branch is triggered that checks if outputs('Run_PAD_RPA')?['statusCode'] is equal 400.
  5. If yes the var_BotStatus keeps value “Error”,
  6. Otherwise it is set to “OK”, which ends the loop.
  7. If the RPA action ends up successfully, then…
  8. var_BotStatus is set to “OK” which ends up the loop.

And that’s it. I hope this will help you to create more reliable processes.

Tomasz Poszytek

Hi, I am Tomasz. I am expert in the field of process automation and business solutions' building using Power Platform. I am Microsoft MVP and Nintex vTE.

No Comments

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.