Workflow pointer (concept)
Call another workflow and continue with shared context.
The Workflow Pointer pattern splits automation across two workflows:
- Workflow Pointer (operation) — in the current workflow, selects a target workflow and transfers execution there.
- Workflow Trigger (trigger) — in the target workflow, is the entry point that runs when the pointer hands off.
When to use
- Reuse onboarding, escalation, or support playbooks without copying nodes.
- Keep a main flow short while delegating a complex sub-routine to another published workflow.
- Separate teams or folders (each workflow can live in its own folder in the picker).
Configuration (conceptual)
| Piece | Role |
|---|---|
| Pointer → Select workflow | Chooses workflowId, workflowName, and workflowFolderId on the pointer node |
| Trigger in target | Must exist as the start of the target workflow; no extra trigger fields in the form |
| Description (both nodes) | Optional note on the canvas; does not affect routing |
Flow behavior
- The pointer node has a normal out connection in the source workflow (execution leaves after the handoff is scheduled).
- The target workflow starts at Workflow Trigger with one outgoing edge to the rest of that graph.
- Variable/context carryover is handled at runtime by the platform; in the editor, configure the target workflow’s trigger and first actions as you would for any new run.
Examples
Shared “create ticket” subflow
- Build workflow B with Workflow Trigger → Task (or CRM action).
- In workflow A, add Workflow Pointer and select workflow B after you collect issue details.
- Return paths in B end that run; workflow A continues from whatever you connect after the pointer.
Related
- Workflow Pointer — operation node reference
- Workflow Trigger — matching trigger node
- Documentation home