Working with Migration Output in Power Automate Desktop (PAD)

after blueprint exports your rpa processes, the resulting power automate desktop (pad) flows are functional — but they may look structurally different from what you'd write by hand this is expected pad and legacy rpa platforms differ in how they handle variables, program flow, data types, and action availability, and blueprint's output reflects those differences this article explains the most common reasons migrated code looks different in pad and describes the constructs blueprint generates to bridge the gap why migrated code looks different variable scope legacy rpa platforms typically support global variables shared across an entire automation pad scopes variables to the subflow in which they're declared blueprint resolves this by declaring all variables in an init variables subflow that runs at the start of every flow, making them accessible across the full execution context see variable prefixing docid\ lvidy2 rg7bpa9sjxzn4u for details on how variables are named and structured in output program flow pad does not natively support constructs like goto, nested loops with complex exit conditions, or some exception handling patterns common in legacy platforms where direct equivalents aren't available, blueprint uses pad labels and go to actions to replicate the original logic as faithfully as possible native vs custom actions not every legacy rpa action has a direct pad equivalent blueprint maps actions to pad's native library where possible when no native equivalent exists, it uses custom actions — or, for platform specific functionality, generates net scripts to replicate the behavior see setting up defaultrundotnetscriptreferences docid 821wzumakctteumhg9aat for details on net script configuration data types pad's type system differs from most legacy platforms blueprint applies conversion logic to map source data types to pad compatible equivalents some conversions are straightforward; others require intermediate handling that adds steps to the output flow selectors ui automation selectors are platform specific and cannot be automatically translated selectors from uipath, blue prism, and a360 will require manual review and updating in pad after migration what blueprint generates generated subflows blueprint structures output into multiple subflows rather than a single flat flow this mirrors the call tree of the original automation — each subprocess or reusable component becomes a discrete subflow in pad see why blueprint creates multiple similar subflows docid\ jc8qf1mdzkqowh97uqukq for details on the subflow structure blueprint produces wrapper subflows for processes that call reusable components shared across multiple automations, blueprint generates wrapper subflows that act as adapters between the calling flow and the exported reusable component see wrapper subflows docid\ owgtiscydgxdqtk wpfcd for how these are structured and when they appear one to many conversions some single legacy actions expand into multiple pad actions in output this occurs when the source action has no direct pad equivalent and the logic must be decomposed into sequential steps platform specific differences certain behaviors in migrated output are specific to the source rpa tool see the platform specific articles for details relevant to your migration uipath to pad migration output docid\ a1sajvhomibeebis4ukja blue prism to pad migration output docid\ polzb8a7gnktos vfwdtw a360 to pad migration output docid\ rtsn23d7rq8li ravdplj setting up sap for rpa docid\ xhckz1 xijzprt2e viy ⓘ for a full list of what to review and complete after export, see completing pad code post migration docid\ h9qdcjgx34vunwjkdorns