When child workflows stay partial
A child workflow step is easy to understand conceptually and much harder to finalize generically. The converter can identify the pattern, but the destination implementation still depends on whether you want a child cloud flow, a placeholder scope, or a manually wired service boundary.
Why child workflows are different
A child workflow is not just another action. It points to another process boundary, another deployment unit, and sometimes another ownership boundary. The source export usually does not contain everything needed to decide how that boundary should look in the target tenant.
Because of that, leaving child workflow calls as partial is often the honest choice.
What a future fully supported path would require
A full end-to-end child workflow export would need a target child flow to exist, a stable interface contract for its inputs and outputs, and a packaging strategy that can wire the parent and child together safely.
Until that exists, a placeholder or partial strategy is often better than emitting a misleading fake call.
How to treat these workflows today
Use Analyze to confirm whether the child workflow call is the main blocker or just one part of the workflow. Many workflows are still worth converting even if one child call remains manual.
Plan the child flow boundary intentionally instead of expecting the product to invent it on your behalf.