> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt > Use this file to discover all available pages before exploring further. # Call Activity or embedded subprocess - which to use > Decide between a Call Activity and a Start Embedded Subprocess node based on data ownership, lifecycle and navigation, with patterns and anti-patterns. Use a **Call Activity** when a phase owns data that the parent process should not keep, such as integration responses, intermediate calculations or preparation data. Use a **Start Embedded Subprocess** node when the phase is a set of screens that works mostly on the parent's data and must appear as a step in the parent's navigation. Both nodes split a large process into smaller ones. They differ in where the subprocess runs and where its data lives. *** ## How do the two nodes differ? | | Call Activity | Start Embedded Subprocess | | - | - | - | | **Process instance** | Starts a separate process instance with its own tokens and data | Runs inside the parent process instance. No new instance is created | | **Data** | Isolated. Input is copied from the parent, output is returned explicitly | Shared. The subprocess reads and writes the parent's data directly | | **Navigation** | Renders its screens in its own navigation areas, not in the parent's stepper or tabs | Renders under a **Parent Process** navigation area, so its screens appear as steps in the parent's navigation | | **Execution modes** | Synchronous or asynchronous, plus parallel multi-instance | Always part of the parent token's path | | **Swimlanes** | Any number | Exactly one | | **BPMN 2.0 equivalent** | Call Activity: a reusable process invoked by reference | Embedded subprocess: a process fragment that shares the parent's context | > [!NOTE] > > A process built for embedding can only be embedded. The runtime rejects a process whose root navigation area is a **Parent Process** area when it's started by a Call Activity or a Start Subprocess action (`Could not render subprocess due to root Parent Process Area.`), and when it's started on its own (`The process couldn’t start because root navigation area can only be rendered for embedded subprocesses.`). *** ## Rule of thumb **If the phase brings its own temporary data, use a Call Activity. If the phase mostly reuses data the parent already has, use an embedded subprocess.** | Question | Call Activity | Embedded subprocess | | - | - | - | | Where does the data come from? | The phase fetches or computes data the parent doesn't need afterwards | Most of the data comes from the parent and goes back to it | | What happens to temporary data? | It stays in the child instance. The parent only receives what you return | Nothing to clean up, but everything the phase writes stays on the parent instance | | What does the phase contain? | Integrations, calculations, document generation, preparation or save steps, transient overlays | Screens, user tasks, step-by-step journeys | | Does it need a step in the parent's stepper or tabs? | No | Yes | | Where do errors and incidents land? | On the child instance, separate from the parent's tokens | On the parent instance, because the subprocess shares the parent's tokens | *** ## Recommended pattern: prepare, screen, save Wrap each user-facing phase between two Call Activities: ``` [Prepare - Call Activity] → [Screen - Start Embedded Subprocess] → [Save - Call Activity] ``` ![Parent process in navigation view: Prepare offer Call Activity, Review Start Embedded Subprocess node in the Offer review step, Save offer Call Activity](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.9/embedded-subprocess-parent-navigation.png) Navigation view of a parent process built with this pattern. The embedded subprocess node (Review) sits in the Offer review step of the stepper. The Prepare offer and Save offer Call Activities aren't assigned to any step. * **Prepare** fetches, enriches and computes the data the screen needs. Raw integration responses stay in the child instance, and only the values the screen uses go back to the parent. * **Screen** renders the user tasks as steps in the parent's navigation and works on the parent's data. * **Save** persists or processes what the user entered, again without leaving intermediate data on the parent. With this pattern, the parent process becomes a sequencer: it orders the phases and holds the business data, while integration logic lives in the prepare and save processes. > [!TIP] > > If a phase varies between projects that share a library, such as a country-specific preparation step, put that phase in its own library process. A project can then replace just that process with a [resource override](https://docs.flowx.ai/5.9/docs/projects/resources.md#resources-overrides) without touching the parent. An override must keep the original process's data model and structure. *** ## When should I use a Call Activity? * **Integration-heavy phases with no user tasks:** calculations, document generation, decision calls, status updates. * **Preparation phases** that fetch or compute data before a screen is shown. * **Save phases** that persist or process the results of a screen. * **Parallel work over a list:** a [parallel multi-instance](https://docs.flowx.ai/5.9/docs/building-blocks/node/call-subprocess-tasks/call-activity-node.md#parallel-multi-instance) Call Activity starts one subprocess per array item, for example to generate several documents at once. * **Shared utilities** called from many processes, such as status updates or error handling. Each caller gets its own instance, so a change to the utility doesn't change the parent's data model. * **Transient overlays:** an error modal, a confirmation dialog before an irreversible action, or a status message while a long operation runs. The overlay resolves and the user returns to the same place in the journey. > [!WARNING] > > Start the overlay **from inside** the Call Activity. Don't trigger a Call Activity from a modal user task in the parent: invoking a Call Activity from inside a modal dismisses that modal, and it isn't restored afterwards. See [Don't chain a modal user task to a Call Activity](https://docs.flowx.ai/5.9/docs/building-blocks/process/design-principles.md#don’t-chain-a-modal-user-task-to-a-call-activity). A Call Activity can also render Pages and Steppers. Those screens join the mobile back stack while the subprocess runs and are cleared when it finishes, so use them for journeys the user shouldn't return to once completed. See [Process design principles](https://docs.flowx.ai/5.9/docs/building-blocks/process/design-principles.md#call-activity-subprocesses-with-pages-or-steppers-appear-in-mobile-back-nav). *** ## When should I use an embedded subprocess? * **Screens and user tasks** that must appear as a named step in the parent's stepper, tabs or navigation areas. * **Reusable UI fragments** that several parent processes show as part of their own journey. * **Error screens that are a step of the journey.** If the error screen should appear in the stepper, embed it. If it's a transient interruption, use a Call Activity. * **Phases where copying data in and out is wasted work.** An embedded subprocess shares the parent's data, so it needs no **Copy from Current State**, **Exclude from Current State** or **Append Params to Parent Process** configuration. > [!WARNING] > > **Requirements for an embedded subprocess** > > * The subprocess must have exactly **one swimlane**, and its swimlane permissions are inherited from the parent. > * Its root navigation area must be a **Parent Process** area. > * Both rules apply to every subprocess it embeds in turn. > > Otherwise the runtime reports `Could not render subprocess due to multiple swimlanes or missing Parent Process Area.` See the [error glossary](https://docs.flowx.ai/5.9/docs/resources/error-glossary.md#could-not-render-subprocess-due-to-multiple-swimlanes-or-missing-parent-process-area) and the [runtime considerations](https://docs.flowx.ai/5.9/docs/building-blocks/node/call-subprocess-tasks/start-embedded-subprocess.md#runtime-considerations) for the node. *** ## Anti-patterns ### One Call Activity per quick integration Each Call Activity starts a process instance. Wrapping every single backend call in its own Call Activity adds instance overhead and makes the process graph hard to read. Group integrations that always run together into one Call Activity. ### A subprocess that only starts more subprocesses Starting a subprocess just to pass parameters and immediately launch several Call Activities from inside it pays the instance cost twice. To run the same work for several inputs, use a parallel multi-instance Call Activity directly from the parent. ### Embedded subprocesses as integration gateways An embedded subprocess that wraps integrations and is embedded from many processes couples all of them to the same data keys: any change to the integration lands in every caller's data model. Move shared integrations into Call Activities, so each caller receives only the output it maps. ### Circular embedding Avoid chains where a process embeds a process that, directly or through other subprocesses, embeds the first one again. Use Call Activities for shared utilities, so each call has its own lifecycle and the dependency doesn't loop back into the parent's instance. *** ## Decision table | Scenario | Use | | - | - | | Backend call, no UI | Call Activity | | Several integrations that always run together | One Call Activity for all of them | | The same work for each item in a list | Parallel multi-instance Call Activity | | Data preparation before a screen | Call Activity | | Saving or processing a screen's results | Call Activity | | Calculations without user tasks | Call Activity | | Transient error modal, confirmation dialog or status overlay | Call Activity, with the modal inside it | | A screen that is a named step in the stepper or tabs | Embedded subprocess | | A reusable screen or modal that is a named step of the journey | Embedded subprocess | | A phase that differs per project or country | Its own library process, invoked by a Call Activity and replaced with a resource override | *** ## Related resources > [card] [Call Activity node](https://docs.flowx.ai/5.9/docs/building-blocks/node/call-subprocess-tasks/call-activity-node.md) > > Sync and async modes, library subprocesses, parallel multi-instance > [card] [Start Embedded Subprocess node](https://docs.flowx.ai/5.9/docs/building-blocks/node/call-subprocess-tasks/start-embedded-subprocess.md) > > Parent Process area, swimlane rules, configuration steps > [card] [Subprocess management](https://docs.flowx.ai/5.9/docs/building-blocks/process/subprocess.md) > > Start modes, parameter inheritance, returning data to the parent > [card] [Process design principles](https://docs.flowx.ai/5.9/docs/building-blocks/process/design-principles.md) > > Modal, subprocess and navigation rules for process design ## Related topics - [Call activity node](https://docs.flowx.ai/5.9/docs/building-blocks/node/call-subprocess-tasks/call-activity-node.md) - [Start embedded subprocess](https://docs.flowx.ai/5.9/docs/building-blocks/node/call-subprocess-tasks/start-embedded-subprocess.md) - [Subprocess management](https://docs.flowx.ai/5.9/docs/building-blocks/process/subprocess.md) - [Send data to user interface](https://docs.flowx.ai/5.9/docs/building-blocks/actions/send-data-to-user-interface.md) - [Start subprocess action](https://docs.flowx.ai/5.9/docs/building-blocks/actions/start-subprocess-action.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.