Export & import

How to import and validate the experimental solution package

Experimental parent/child packages must be imported through Power Platform Solutions and validated like an engineering artifact. This guide explains the import path, connection-reference steps, activation order, and validation checks after import.

7 min readUpdated Jun 3, 2026exportsolutionsexperimental
Quick answer
In shortUse this checklist after downloading the experimental parent/child solution package from Flow Migrator.
Most likely causeDo not import the experimental package from the legacy My flows import screen. The package is generated as a Power Platform solution because it contains solution-aware parent and child flows.
What to do nextMake the fix, generate a new package, and import the new ZIP instead of retrying the old one.

Import through Solutions

Do not import the experimental package from the legacy My flows import screen. The package is generated as a Power Platform solution because it contains solution-aware parent and child flows.

Use Power Apps or Power Automate Solutions, choose Import solution, select the ZIP, and follow the connection-reference prompts for the target environment.

  1. Open the target Power Platform environment.
  2. Go to Solutions and choose Import solution.
  3. Upload the experimental ZIP downloaded from Flow Migrator.
  4. Map or create the required connection references.
  5. Complete the import and review any warnings before activating flows.

Activate child flows before the parent

The parent flow calls generated child flows. If a child flow is inactive, missing a connection reference, or invalid, the parent can fail validation or runtime testing.

After import, open the solution, confirm the connection references, then activate the generated child flows first. Activate or test the parent flow only after the child flows are ready.

Validate context JSON handoff

The experimental package uses a MigrationContext object to pass data between the parent and child flows. This is what lets extracted child flows share state without relying on source actions that no longer live in the same flow.

During UAT, validate that variables used by later child flows are populated by earlier child flows and that default values were not used where real business data is required.

  • Check trigger inputs on each child flow.
  • Review response outputs from each child flow.
  • Confirm important variables are written back to MigrationContext.
  • Pay attention to approvals, HTTP responses, SharePoint item IDs, and file metadata.

Review TODO and partial actions

TODO actions in the experimental solution should represent real review work, not generic boundary labels. They usually appear where the source action requires a business decision, custom connector mapping, external system validation, or document-generation strategy.

If a supported action appears as a placeholder, re-run the workflow through Analyze and confirm the action family is recognized correctly.

Common warnings and what they mean

  • Connection authorization warnings usually mean the selected connection reference cannot activate the generated flow in that environment.
  • Deactivated child-flow warnings mean the parent flow is trying to call a child flow that is not turned on yet.
  • SharePoint GetTable errors usually mean a site or list mapping is missing, points to a tenant the connection cannot access, or references a list/library that has not been created.
  • Action-count or nesting errors mean the experimental splitter still needs to create additional child-flow boundaries before the package should be used.

Related articles

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