Call Activity
An activity that runs a whole other process that lives outside this diagram and is reused across many diagrams.
What a call activity does
A call activity looks like a regular activity with a bold rounded-rectangle border, and it behaves like a function call: when the token arrives, the current diagram hands control to a separate, reusable process definition. When that process finishes, the token returns to the calling diagram and continues along the outgoing flow.
The difference between a call activity and a sub-process is scope. A sub-process lives *inside* the parent diagram — expanding it reveals an embedded flow that only this process uses. A call activity points to a global process, authored once and invoked from many places — "Run the credit check", "Send the compliance notification", "Do the identity verification". Editing the global process updates every caller automatically.
When to use a call activity instead of a sub-process
- The same sub-flow appears in two or more processes. Anything that repeats is a candidate for a call activity.
- The sub-flow has its own owner — e.g. the compliance team owns "Run KYC", and any process that needs it should call their canonical version.
- The sub-flow has its own lifecycle — compliance rules change, the global process is updated once, callers inherit it.
Call activities in LucidFlow
LucidFlow detects call-activity candidates during generation: when the document references a process by name ("run our standard onboarding flow", "trigger the compliance review"), the generator emits a call activity rather than expanding the sub-flow inline. You can then either author the called process separately in the same workspace, or leave it as a black-box step for later refinement.
Frequently asked questions
How is a call activity different from a sub-process?
A sub-process is embedded: it lives inside the parent diagram and is owned by it. A call activity points to a global process that lives outside this diagram and can be invoked from many diagrams. Think of it as local function vs shared library.
Can a call activity call another call activity?
Yes. The called process can itself contain call activities. BPMN does not limit call depth, but for readability keep it shallow — two or three levels before your diagrams become hard to reason about.
What happens if the called process throws an error?
The error propagates back to the call activity in the parent. You can catch it with an error boundary event on the call activity itself, the same way you would catch an error from any other activity.