Skip to main content
Table of Contents

Working with Migration Output in Power Automate Desktop (PAD)

This article describes some of the more commonly asked aspects of the Power Automated Desktop flows generated by Blueprint migrated from other RPA tools. Why does my code in PAD look different? The t…

Tony Higgins
Updated by Tony Higgins

This article describes some of the more commonly asked aspects of the Power Automated Desktop flows generated by Blueprint migrated from other RPA tools.

Why does my code in PAD look different?

The top priority when migrating to PAD is making each action behave exactly the same way it did in the previous platform. Moreover, Power Automate has a number of key differences from other platforms that require workarounds in order to maintain logic consistency when migrating. Below is a list of those key differences and how Blueprint deals with them.

Variable Scope

Program Flow
  • Power Automate: Program flow is linear, one command is executed after another line by line
  • Other Platforms: Use process diagrams that can have loops, state machines, and jump or return to any part of the process
  • Migration Result:

Native and Custom Actions

Data Types
  • Power Automate: New to the RPA space, not that many available data types.
  • Other Platforms: Have access to almost all .NET data types
  • Migration Result:

Selectors
  • Power Automate: Support Java, SAP, Browser, and UIA selectors
  • Other Platforms: Support Java, SAP, Browser, UIA, and AA selectors
  • Migration Result:

Blueprint Generated Code

Variable Prefixes

Because variables cannot be scoped to sub-flows in PAD, Blueprint adds a prefix to variables being passed to a sub-flow. This prefix is unique to each sub-flow. The sub-flow acts upon these prefixed variables and then where applicable the output is assigned again the main flow.

This approach has the unfortunate side-effect of adding many variables to the global scope. These prefixes and assignments can be removed during export by toggling "Variable prefix" to off as seen below

Wrapper Sub-flows

If a sub-flow has many inputs or outputs, occasionally calls to this sub-flow will be wrapped by another sub-flow. The reason for this is because there is a lot of boilerplate code required to setup and teardown a call to the underlining sub-flow.

Environment Variable Rules

PAD has a concept of environment variables however, the permissions and scope are vastly different than what's typical and expected from other platforms therefore, Blueprint mimics the behaviour of environment variables using Rules. Where possible, environment variable rules will be automatically enabled, in other cases, follow the instructions outlined here.

Logic Flattening Using Go To

PAD flows are intended to execute in a linear fashion however, other platforms allow for triggers and more complex program flow. For example, state machines, and returning to previous statements. In order to maintain cyclical logic in a linear framework, Blueprint takes advantage of Labels and Go To's. A user will see labels typically starting with L_, such as:

Rules for Custom Actions

For 3rd party or custom actions, Blueprint's Rules engine provides a mechanism to map these actions. See our in-depth article: Custom Action Mapping

Rules for Unsupported/Unmapped Actions

There are certain situations where either Blueprint does not support the migration of a given activity, or there's no generic solution. For these cases our Rules engine enables users to migrate these actions. For more detail read: Unmapped Actions

One to Many Conversions

PAD is still growing in its capabilities and has its own set of design principles. As a result, not all functionality in other platforms have a direct conversion. In these situations Blueprint will try its best to use only native PAD actions to replicate the original action. This may require many native actions. In some cases these actions will be put in a Region or in their own subflow entirely.

.NET Scripts

Certain functions cannot be converted natively and the only option is a .NET Script. Blueprint goes to great lengths to avoid using .NET Scripts however, in order to maintain logical consistency it is required.

Variable Type Conversions

PAD has a small set of native data types: Number, Text, List, DataTable, Boolean, Custom Object, and DateTime. In most cases other data types will be converted to a Custom Object. For example, a Dictionary<T,U> will be converted to a Custom Object. For platform specific data type conversions check our platform specific pages.

Blueprint also allows for explicit variable type conversions and initializations. Read: Variable Renaming and Initialization

Generated Subflows

When migrating from another RPA platform to Power Automate Desktop, Blueprint will create various subflows if needed based on the contents of the migrated bot

These Subflows will be generated for every Migrated Flow :
  • Init_Variables - All variables declared in your source RPA file will be declared within this subflow:

One or more of these Subflows will be generated depending on content of the Migrated Flow:

These subflows will be created if the corresponding flag within the error handling of the source RPA tool was enabled:

  • Err_TakeScreenshot - Captures and saves a screenshot at time of error
  • Err_LogToFile - Logs capture error and current date time to provided file path
  • Err_SendEmail - Sends an email to provided users
  • Err_DumpVariables - Dumps values of all variables into a dictionary variable

Platform Specific Differences

Blueprism

AA

UiPath

How did we do?

Blueprism to PAD Migration Output Details

Contact