Child Workflows
A Child Workflow is a Workflow Execution started by another Workflow. The child gets its own Event History, can run on a separate set of Workers, and has its own lifecycle. That lets a Parent Workflow hand off part of a business process instead of running every step itself.
When to use a Child Workflow
- Create a separate service: because a child can be processed by a completely separate set of Workers than its parent, it can act as its own service. Parent and child share no local state and communicate only through asynchronous Signals. To compose across Namespace boundaries, or between teams that own separate Temporal Applications, use Temporal Nexus instead.
- Partition a large workload: each child has its own Event History, so splitting work across children raises the ceiling on how many steps one business process can take.
- Represent a single resource: map one child to one resource and use its Workflow Id to guarantee uniqueness, which serializes every operation on that resource.
- Run periodic logic: a child can call Continue-As-New as many times as it needs and then complete. From the parent's point of view it was a single invocation, so the periodic work never fills the parent's Event History.
When not to use a Child Workflow
- For code organization alone. Use the object-oriented structure and other organizing techniques your language already offers.
- When the workload has a bounded size. Start from a single Workflow Definition when you can put a ceiling on the number of Activity Executions and Signals. One Workflow is simpler to reason about than several communicating asynchronously.
- When Activities would do. Child Workflow Executions record more Events overall than Activities do, and each Event in an Event History costs compute. Start with a single Workflow that calls Activities, and add Child Workflows once you have a clear reason.
Child Workflow or Activity?
Both are started from a Workflow, which makes the choice easy to get wrong. A Child Workflow has access to all Workflow APIs but is subject to the same deterministic constraints as any other Workflow. An Activity has the inverse trade-off: no access to Workflow APIs, but no determinism constraints either. See Child Workflow versus an Activity for the full comparison.
Limits to plan for
These numbers shape how you partition a business process:
- A Workflow Execution's Event History is capped at 51,200 Events or 50 MB, with a warning at 10,240 Events or 10 MB.
- A Workflow Execution can have at most 2,000 incomplete Child Workflows at a time, by default.
- A Parent Workflow's Event History records Events for each child's status, so a single parent should not spawn more than about 1,000 Child Workflow Executions.
- Those figures compound: one parent running 1,000 children that each run 1,000 Activity Executions reaches 1,000,000 Activity Executions, far past what one Workflow Execution can hold.
See Workflow Execution limits for the full set.
Parent Close Policy
Every Child Workflow Execution carries a Parent Close Policy that decides what happens to the child when its parent reaches a Closed status:
- Terminate (the default): the child is forcefully Terminated.
- Request Cancel: a Cancellation request is sent to the child.
- Abandon: the child keeps running.
Each child can set its own policy, so a parent can terminate some children and leave others running.
Resources
Read the Temporal Encyclopedia for conceptual depth:
Or jump straight to the SDK feature guide for implementation details:
.NET SDK
Start and manage Child Workflows in C# and .NET.
Go SDK
Start and manage Child Workflows in Go.
Java SDK
Start and manage Child Workflows in Java and other JVM languages.
PHP SDK
Start and manage Child Workflows in PHP.
Python SDK
Start and manage Child Workflows in Python.
Ruby SDK
Start and manage Child Workflows in Ruby.
Rust SDK
Start and manage Child Workflows in Rust.
TypeScript SDK
Start and manage Child Workflows in TypeScript and JavaScript.