Power Automate limits

How SourceItem and MigrationContext work in refactor packages

Parent/child refactors only work when the generated flows share data predictably. Flow Migrator uses two concepts for that handoff: SourceItem for the original trigger record and MigrationContext for migrated variables, lookup outputs, and state that later child flows may need.

7 min readUpdated Jul 3, 2026MigrationContextSourceItemchild flows
Quick answer
In shortUnderstand how Flow Migrator passes source-item data and shared workflow state between parent and child flows in a refactor solution package.
Most likely causeA child flow does not automatically receive the original SharePoint trigger body. Its trigger body is the payload sent by the parent flow. That means source fields such as Category, Status, ID, Created By, or Author Email must be passed explicitly when the parent calls the child.
What to do nextReview the Power Automate limit-risk panel in Analyze, then decide whether to split, refactor, or pilot-test the workflow.

Why child flows need an explicit source item

A child flow does not automatically receive the original SharePoint trigger body. Its trigger body is the payload sent by the parent flow. That means source fields such as Category, Status, ID, Created By, or Author Email must be passed explicitly when the parent calls the child.

SourceItem is Flow Migrator's name for that original source payload. Child flows read source fields from SourceItem so branch logic still evaluates against the same item that triggered the parent flow.

Instead of reading triggerBody()?['Status'] in a child flow, generated refactor logic should read variables('SourceItem')?['Status'] or the equivalent SourceItem path.

What MigrationContext contains

MigrationContext is a JSON object used to carry values that need to survive across child-flow boundaries. It can contain migrated variable values, lookup results, group membership outputs, attachment arrays, action outputs, and other state needed by later sections.

The goal is not to hide all variables. Some Power Automate actions still need local typed variables. The cross-flow contract, however, should be object-based so the caller can merge updated state after every child flow returns.

  • sourceItem for the original trigger record.
  • vars for migrated scalar values.
  • groups for SharePoint group membership outputs.
  • attachments for file arrays used by email actions.
  • actionOutputs for data produced by connector calls that later child flows may need.

What to check during UAT

  1. Open the parent flow and confirm the child-flow call includes SourceItem and MigrationContext.
  2. Open each child flow and confirm branch conditions read from SourceItem, not from a bare child trigger body.
  3. After a child-flow call, confirm the caller merges the returned MigrationContext before later actions run.
  4. Run a test item through a branch that performs a lookup, then verify the returned values are used downstream.
  5. Pay special attention to group member lookups, HTTP body parsing, attachments, and Created By or Author fields.
If a child flow runs but downstream actions see blank values, the first place to inspect is the SourceItem and MigrationContext handoff.

Related articles

Keep reading the next most relevant guides for this workflow pattern.