As playbooks grow in complexity, packing every action into a single playbook makes them harder to maintain and reuse. The TriggerPlaybook component lets you split large playbooks into modular sub-playbooks: a main playbook calls a sub-playbook, passes input data to it, and reads back its output — keeping each playbook focused and reusable across workflows.
The component provides two actions that work together:
| Action | Where to use it | What it does |
|---|---|---|
callSubTaskWithQps | Main playbook | Calls a sub-playbook with concurrency limiting; waits synchronously for all executions to complete or time out |
setOutput | Sub-playbook | Defines the output data that the main playbook reads back after execution |
How they work together: callSubTaskWithQps runs in the main playbook — it triggers the sub-playbook and blocks until all sub-playbook instances finish (or the timeout is reached). setOutput runs in the sub-playbook — it defines what data gets returned to the main playbook. Configure setOutput in the sub-playbook first, then reference its output in the main playbook via callSubTaskWithQps.
Configuration examples
Each example below is a complete JSON file that you can import as a test playbook. After importing, open the playbook in the visualization flow editor to inspect and test the parameter configuration for each action. For import instructions, see Playbook import.
Save the example data as a JSON file before importing.
callSubTaskWithQps
Use callSubTaskWithQps in the main playbook to call a sub-playbook. The main playbook waits synchronously until all sub-playbook executions complete or the timeout is reached before continuing. Each sub-playbook execution generates an execution record. To view records, see View playbook execution records.
Parameters
| Parameter | Description |
|---|---|
| Select playbook | The sub-playbook to call. Lists all playbooks under the current account. |
| Input | Input parameters configured for the start node of the sub-playbook. |
| Output | Output parameters configured for the start node of the sub-playbook. |
Advanced configuration
| Parameter | Description | Default | Maximum |
|---|---|---|---|
maxTasks | Maximum number of concurrent sub-playbook executions. Default: 20. If set to 0 or below, the default of 20 applies. | 20 | 50 |
waitMaxTimeOneTask | Maximum wait time for a single sub-playbook execution, in seconds. | 43200 (12 hours) | 86400 (1 day) |
waitMaxTime | Maximum wait time for all sub-playbook executions combined, in seconds. | 43200 (12 hours) | 86400 (1 day) |
How concurrency limiting works
maxTasks controls how many sub-playbook instances run simultaneously. When the number of calls exceeds maxTasks, excess calls queue and start as running instances complete.
For example, with maxTasks set to 20 (the default) and 100 calls to make: the first 20 start immediately, and the remaining 80 are queued. As each of the first 20 finishes, a queued call starts — continuing until all 100 have run.
setOutput action
Use setOutput in the sub-playbook to define what data the main playbook reads back after execution completes.
Parameters
The output parameters available here are those configured in the input and output parameters section of the sub-playbook's start node. For start node configuration, see Start/End.
Parameter values support constants, expressions, output values from preceding nodes, and more. For details, see Component parameters and node execution flow.