Export & import

Validate a refactor solution package before production

A refactor package should import as a Power Platform solution, but production readiness still depends on tenant-specific validation. Use this checklist before promoting a generated parent/child package from pilot to production.

6 min readUpdated Jul 3, 2026UATPower Platform Solutionsrefactor package
Quick answer
In shortA concise UAT checklist for parent/child refactor packages generated for oversized Nintex workflows.
Most likely causeRefactor packages should be imported through Power Platform Solutions. After import, map connection references, open the generated flows, and activate child flows before the parent flow. That order makes child-flow call validation easier and avoids parent activation failures caused by inactive callees.
What to do nextMake the fix, generate a new package, and import the new ZIP instead of retrying the old one.

Start with import and activation order

Refactor packages should be imported through Power Platform Solutions. After import, map connection references, open the generated flows, and activate child flows before the parent flow. That order makes child-flow call validation easier and avoids parent activation failures caused by inactive callees.

  1. Import the solution ZIP into the target environment.
  2. Map every connection reference to an approved customer connection.
  3. Open child flows and resolve connector warnings first.
  4. Activate child flows.
  5. Open and test the parent flow after child flows are available.

Validate business branches, not just import success

An import success message only proves the solution can be saved. It does not prove that every original Nintex branch, email recipient, lookup, group membership action, HTTP call, or SharePoint update behaves correctly in the customer tenant.

For large workflows, choose a small set of representative test cases that cover each major status, category, or decision branch. Keep run-history screenshots or exported run logs with the customer UAT evidence.

  • At least one happy-path run through the main branch.
  • At least one exception or hold/rework branch if present.
  • One branch that sends email with attachments if the source workflow did so.
  • One branch that reads SharePoint group members if present.
  • One branch that writes back to SharePoint list or library fields.

Use generated notes as validation cues

TODO and review notes should point to real validation work. They are especially important around partial actions, unsupported actions that were excluded, custom HTTP calls, document-generation patterns, and connector-specific permissions.

Do not remove notes just to make the flow look cleaner. Remove or resolve them only after the customer has confirmed the behavior.

Related articles

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