Call

The Call node executes another job (sub-workflow) as a step within the current workflow. This enables modular workflow design where common automation sequences can be defined once and reused across multiple parent workflows. The parent workflow waits for the child job to complete before continuing.

Before You Use This Node

What you may need	Where to set it up	Why it matters
Shared input values for child jobs	Global Variables	Pass consistent values into reused jobs.
Shared files or datasets used by the child job	Files and Datasets	Prepare reusable inputs before the child workflow runs.

Actions

Action	Description
call:executeJob	Execute a sub-job and wait for its completion

call:executeJob

Triggers execution of a specified job and waits for it to finish. Input parameters can be passed to the child job, and the child job's output is returned to the parent workflow.

Parameters

Parameter	Type	Required	Description
jobId	string	Yes	The ID of the job to execute
parameters	object	No	Key-value pairs to pass as input parameters to the child job
timeout	integer	No	Maximum wait time in seconds for the child job to complete. Defaults to 3600 (1 hour)
async	boolean	No	If true, trigger the job and continue without waiting. Defaults to false

Example: Synchronous sub-job call

Example: Async fire-and-forget

Example: Reusable data processing pipeline

How Input Parameters Map to Child Jobs

The parameters object you define on the Call step becomes the child job's input context. Each key in the object is available as an input variable inside the child job.

• The keys in parameters become accessible to the child job's steps through trigger context expressions. For example, if the parent passes {"customerId": "123", "region": "EMEA"}, the child job's steps can reference these values using expressions like trigger.payload.customerId and trigger.payload.region.
• Parameter values can be static strings, numbers, or booleans, or they can be dynamic references to output from earlier steps in the parent workflow.
• The child job does not have automatic access to the parent's step outputs or workflow context beyond what is explicitly passed through parameters.

Error Propagation

How errors in the child job affect the parent workflow depends on the execution mode.

Synchronous Mode (default)

When a child job fails during synchronous execution, the parent Call step also fails. The parent step's error output includes the child's error details:

• errorType — The type of error encountered in the child job.
• errorMessage — The error message from the failed child step.
• Failed step information — Which step in the child job caused the failure.

The parent workflow then applies the Call step's error handling strategy:

• STOP_WORKFLOW — The entire parent workflow stops at the Call step.
• CONTINUE — The parent workflow ignores the child's failure and moves to the next step, using the last successful output.
• CONTINUE_WITH_ERROR_OUTPUT — The parent workflow continues, but the Call step's output contains the error details, which downstream steps can inspect and react to.

Async Mode

In async mode, the parent workflow has no visibility into child job failures. The Call step returns immediately with an executionId, and the parent continues regardless of what happens in the child job. If you need to know whether an async child job succeeded, you must check its status separately through monitoring or a subsequent API call.

Async Execution Details

When async is set to true, the Call step behaves as a fire-and-forget trigger:

• The step returns immediately after the child job is queued for execution. The response contains only the executionId of the child job.
• The parent workflow continues to the next step without waiting for the child job to start or finish.
• The child job runs independently in the background. Its execution lifecycle (queued, running, completed, failed) is entirely separate from the parent workflow.
• To check the child job's status later, use the returned executionId with the platform's monitoring dashboard or through another workflow step that queries execution status via the API.

Async mode is best suited for triggering long-running background processes, sending notifications, or kicking off independent cleanup tasks where the parent workflow does not depend on the result.

Connection

No connection required. The Call node references jobs by their internal ID within the Qinfinite platform.

Output

Synchronous call

Returns the child job's execution result:

Async call

Returns immediately with the execution ID:

If the child job fails, the parent step also fails with the child's error details included in the error output.

Best Practices

• Use Call for reusable logic. If multiple workflows need the same sequence of steps (e.g., "Send Notification", "Validate Customer", "Generate Report"), define it as a standalone job and invoke it with a Call node. This avoids duplicating steps across workflows and makes maintenance easier.
• Keep child jobs focused on one purpose. A child job should do one thing well. Avoid creating monolithic child jobs that handle many unrelated tasks. Smaller, focused jobs are easier to test, debug, and reuse.
• Be cautious with nested Call chains. A workflow where Job A calls Job B, which calls Job C, creates a deep execution chain that is harder to debug and monitor. If a failure occurs deep in the chain, tracing the root cause requires inspecting multiple execution logs. Try to keep call depth to 2 levels when possible.
• Set appropriate timeouts. The default timeout is 3600 seconds (1 hour). If your child job is expected to complete in minutes, set a shorter timeout to surface issues faster. If the child job is known to be long-running, increase the timeout accordingly to prevent premature failures.
• Use async only for fire-and-forget scenarios. Only set async to true when the parent workflow genuinely does not need the child job's result. If you need the output or need to know whether the child succeeded, use synchronous mode.