Why Blueprint Creates Multiple Similar Subflows

6 min

During migration you may notice what appear to be duplicate subflows in your PAD output. This is intentional — each instance exists for a specific technical reason.

Three Reasons Blueprint Creates Subflows

Direct Process Translation

Sub-processes from the source automation (such as UiPath workflows) are recreated as discrete subflows in PAD to preserve the original logical structure.

Variable Management

PAD handles variables differently than legacy RPA platforms. Blueprint creates wrapper subflows to manage how data passes between parts of the automation. See Wrapper Subflows for a full explanation.

One-to-Many Action Translation

Some source actions have no direct PAD equivalent. Blueprint combines multiple PAD actions — loops, conditions, data operations — to replicate the same behavior. This is the most common reason you'll see subflows that look nearly identical.

Why Similar Subflows Aren't Identical

When an action appears multiple times in the original automation, each instance has different specifics — different data sources, variable names, hardcoded values, or parameters. Because PAD lacks variable scoping, each instance requires its own subflow.

Example: A UiPath process uses a GetNextItem action three times — once for a HighPriority queue, once for Standard, and once for LowPriority. The core logic is the same, but each call works with a different queue name, so Blueprint generates three separate subflows.

Why This Approach Works

Accuracy — Each subflow is precisely tailored to its context, ensuring the automation behaves as intended

Maintainability — Changes to one instance don't affect the others

Clarity — Each subflow reflects exactly what it does in that specific context