Execution Lifecycle

Every automation run follows the same basic shape: it is triggered, initiated, executed, resolved, and recorded. Once you understand that flow, statuses and logs become much easier to read.

Use this page when you want to answer:

• Where is my job right now?
• What is the platform doing at this stage?
• What should I do if the run pauses, fails, times out, or waits for approval?

The Big Picture

START

Triggered

A user, schedule, webhook, API call, AI agent, or another job starts the run

Initiated

The platform loads the job, builds an execution plan, and creates a workflow

Running

Steps execute in dependency order, with parallel batches where possible

Resolved

The final outcome is determined

Recorded

Status, timing, outputs, errors, and trigger context are saved

END

A run starts, the system builds an execution plan, steps execute, and the result is saved.

Most runs spend only a moment in initiation, most of their time in step execution, and then become a saved execution record that you can inspect later.

What Happens During a Run

1. Triggered

A job starts when one of these sources asks Automation Hub to run it:

• Manual run from the UI
• Scheduled trigger (a Temporal cron schedule fires at the configured time)
• Webhook trigger (an external system sends an HTTP request)
• API request (a direct call to the job-executor API)
• AI agent request through the MCP server
• Call node from another job that invokes this one as a sub-job

At this point, the platform knows which job to run and what trigger context (payload, trigger type, who triggered it, and when) to associate with the execution.

2. Initiated

The system prepares the run before any step executes. This is where the execution plan is built.

What happens	Why it matters
Loads the job definition and all its steps from MongoDB	Ensures the latest version of the job is used
Loads links (step connections)	Understands how steps relate to each other
DAG execution engine builds the execution plan	Validates there are no circular dependencies, performs topological sort, builds a dependency map, and identifies conditional links (true/false branches)
Creates a JobExecution record with status INITIATED	Gives every run a unique, trackable record from the start
Creates a StepExecution record for each step	Each step gets its own trackable execution entry
Resolves retry and timeout configuration from job settings	Ensures the workflow knows how to handle slow or failing steps
Creates and starts a Temporal Workflow	Hands the execution plan to the workflow engine for reliable, durable execution

This stage usually takes less than a second. If a run fails here, the issue is usually a missing job definition, invalid step configuration, circular dependencies between steps, or a connection to the workflow engine.

3. Running

This is where the real work happens. The Temporal Workflow orchestrates step execution using a batch-based loop.

How steps execute:

1. The workflow identifies all "ready" steps -- steps whose dependencies have all completed.
2. Ready steps execute as a parallel batch. If three steps are ready at the same time, all three run simultaneously.
3. Each step is resolved through the Plugin Registry to find the right action handler, then executed.
4. After each batch completes, the workflow collects results, merges outputs, and determines the next set of ready steps.
5. For conditional steps (like an IF node), the workflow follows the appropriate branch -- the "true" link or "false" link -- based on the step's result.
6. If a step has human-in-the-loop (HIL) enabled, the workflow pauses with status ON_HOLD until someone approves or rejects.
7. The loop continues until all reachable steps have been processed or an error stops execution.

Get Ready Steps

Find all steps whose dependencies are met

Execute Batch

Run ready steps in parallel via their plugins

Collect Results

Merge outputs, follow conditional branches, find next batch

The workflow repeats this loop until every reachable step has run or execution is interrupted.

While the job is running, you can monitor:

• Current step and its status
• Completed steps and their outputs
• Step duration and timing
• Retry attempts
• Error messages and stack traces
• Logs and timestamps

4. Resolved

The run eventually reaches a final outcome. The workflow determines whether the job completed successfully, failed, was stopped by a user, timed out, or ended for another reason.

Outcome	What it means	Usual next action
COMPLETED	Every required step finished successfully	Review outputs and confirm the result
FAILED	A required step failed and error handling stopped the job	Open the failed step, read the error, fix, and rerun
PAUSED	The run was intentionally paused by a user	Investigate, adjust if needed, then resume
ON_HOLD	The run is waiting for human approval (HIL step)	Complete the approval or reject the request
TIMEOUT	The run exceeded a configured time limit	Check the slow step, then tune timeout or optimize the job
STOPPED	A user explicitly stopped the run	Review partial work before restarting
CANCELED	The system or caller cancelled the run	Check the cancellation reason before rerunning

5. Recorded

Every run becomes part of execution history. Here is what gets saved for each execution:

Recorded data	Details	Why it helps
Execution ID and Job ID	Unique identifiers for the run and the job definition	Gives every run a traceable reference
Job Name	The human-readable name of the automation	Makes it easy to find in history
Trigger context	Payload, trigger ID, trigger type, who triggered it, and when	Explains exactly why and how the run started
Start time, end time, duration	Precise timestamps and calculated execution time	Shows performance and helps identify bottlenecks
Input parameters	The data provided when the job was triggered	Shows what shaped the run
Output	Accumulated outputs from all steps	Shows what each step produced and the final result
Result and result type	The final output in its format (JSON, XML, TEXT, HTML, CSV, etc.)	Provides the deliverable in the right format
Error details	Whether an exception occurred, error type, error message, stack trace, error details, and error timestamp	Explains failures with full diagnostic information
Retry info	Whether the run is retryable, current retry count, and maximum retries	Shows how many attempts were made

History is useful for audits, troubleshooting, optimization, and proving what happened during a production automation.

Status Cheat Sheet

Use this table when you see a status and need to know what to do next.

Status	What is happening	What you should do
SCHEDULED	The job is waiting for its next scheduled trigger time	Confirm the schedule and wait
INITIATED	The platform is loading the job, building the execution plan, and creating the workflow	Wait briefly; if it fails, check job definition and step configuration
RUNNING	One or more steps are actively executing	Watch the current step, logs, and duration
PAUSED	Execution is paused by a user signal	Resume when you are ready to continue
RESUMED	A previously paused execution has been resumed and is running again	Monitor as it continues executing
ON_HOLD	A human-in-the-loop step is waiting for approval	Approve or reject the pending request
SKIPPED	A condition prevented a step or branch from running	Verify the conditional rule and input data
COMPLETED	The job finished successfully	Review results and downstream effects
FAILED	A required step failed	Inspect the failed step, fix the cause, and rerun
TIMEOUT	Execution exceeded a configured time limit	Identify the slow step before raising limits
STOPPED	A user stopped the job via a signal	Check what already ran before starting again
CANCELED	The run was cancelled by system or caller	Review the cancellation reason

Step Statuses

A job has an overall status, and each step has its own status. When troubleshooting, the step status is usually where the answer is.

Step status	Meaning	Good question to ask
RUNNING	The step is executing now	Is it taking longer than usual?
COMPLETED	The step succeeded	Does the output look correct?
FAILED	The step errored	Is the error transient, configuration-related, or data-related?
SKIPPED	The step did not run because of a condition or because it was on a branch that was not followed	Did the condition evaluate as expected?
ON_HOLD	The step is waiting for human approval	Who needs to act, and what are they approving?

Controlling a Running Automation

While a job is running, you can send signals to control its execution. These signals are delivered through Temporal and take effect at the next safe point in the workflow loop.

Pause

Pausing a run suspends execution at the next step boundary. The workflow sets an internal flag and blocks until the flag is cleared. No new steps will start while the job is paused.

Use pause when:

• You want to inspect intermediate results before the job continues
• You need to verify that an external system is ready for the next step
• You want to coordinate timing with another process

The job status changes to PAUSED and stays there until you resume.

Resume

Resuming a paused run clears the pause flag and lets the workflow continue from where it stopped. When you resume, you can optionally pass updated input variables that the remaining steps will use.

This is useful when you paused to check something, realized an input value needs to change, and want to continue with corrected data.

The job status changes to RESUMED and then back to RUNNING as steps begin executing again.

Stop

Stopping a run ends execution immediately. The workflow sets a stop flag that breaks the execution loop. Any step that is currently running will finish, but no new steps will start.

Use stop when:

• Continuing would cause unwanted changes in an external system
• You realize the job was triggered with wrong inputs
• The automation is doing something unexpected

The job status changes to STOPPED. Before rerunning, check whether any completed steps already made changes to external systems.

Reject (Human-in-the-Loop)

When a job is ON_HOLD waiting for human approval, you can reject the approval request. Rejecting causes the HIL step to fail, which typically stops the job (depending on your error handling configuration).

Use reject when the proposed action should not proceed -- for example, if the data looks wrong or the change is too risky.

Test Mode

Test mode lets you validate your workflow logic without affecting real systems.

When test mode is enabled on a job, any step that has pinned data will use that mock data instead of executing the actual plugin. The step skips the real integration (no API calls, no database queries, no emails sent) and returns the pinned data as its output.

When to use test mode:

• Building a new automation and you want to verify the flow before connecting to production systems
• Testing conditional branches to make sure the right path is followed for different inputs
• Validating that downstream steps handle upstream outputs correctly
• Demonstrating a workflow to stakeholders without triggering real actions

How it works:

1. Enable test mode on the job
2. Pin sample data on the steps you want to mock (you can pin data on some steps and leave others to execute normally)
3. Run the job
4. Steps with pinned data return their mock output instantly; steps without pinned data execute their plugin as usual

This gives you a safe sandbox to iterate on your automation design. When you are confident the flow is correct, disable test mode and run against real systems.

Common Paths Through the Lifecycle

Happy Path

Triggered

The job starts from a user, schedule, webhook, API, AI agent, or another job

Initiated

Execution plan is built and the Temporal Workflow starts

Running

Steps execute in batches, with parallel steps running simultaneously

Completed

All steps succeed and the accumulated output is saved

What to check:

• Did every step complete?
• Do the final outputs match what you expected?
• Was the duration normal?

Failure Path

Triggered

The job starts normally

Initiated

Validation passes and execution begins

Running

A step hits an error and retries are exhausted

Failed

The error type, message, stack trace, and timestamp are recorded

What to check:

• Which step failed first?
• Did the previous step produce the data this step expected?
• Is the error caused by connection, configuration, input data, permissions, or timeout?
• Was the error retryable? How many retries were attempted?
• Should this step retry, stop the job, or continue with error handling?

Approval Path (Human-in-the-Loop)

Running

The job reaches a HIL (human-in-the-loop) step

On Hold

The workflow pauses until someone approves or rejects

Running

After approval, the remaining steps continue

Completed

The run finishes and records the approval decision

What to check:

• Who needs to approve?
• What data should they review before deciding?
• What happens if the request is rejected? (The HIL step fails, and error handling determines whether the job stops or continues.)

Pause and Resume Path

Running

The job is actively executing steps

Paused

You send a pause signal to inspect data or coordinate timing

Resumed

You resume, optionally with updated input variables

Completed

The job finishes after the pause is resolved

Use pause when you want to inspect a run before it continues. When you resume, you can pass updated variables if you need to change what the remaining steps will use. A pause is intentional and reversible.

Timeout Path

Running

A step takes longer than expected

Limit Reached

The configured timeout from job settings is exceeded

Timeout

Automation Hub stops the run and records where time was spent

What to check:

• Which step consumed most of the time?
• Is the external system slow?
• Is the job processing too much data?
• Is the timeout too strict, or is the automation inefficient?

Manual Stop Path

Running

The job is still active

Stop Signal

A user sends a stop signal to the workflow

Stopped

The execution loop breaks and the run ends with partial results

Use stop when continuing would be wrong or risky. Before rerunning, check whether any previous step already changed data in an external system.

Choosing the Right Action

Situation	Best action	Why
A run is waiting for a human decision (ON_HOLD)	Approve or reject	The workflow cannot proceed until someone decides
A run is paused and the configuration is still valid	Resume	The remaining steps can continue from where they stopped
A run is paused but an input value was wrong	Resume with updated variables	You can correct the input without restarting the entire job
A step failed because of a temporary network issue	Retry	The same configuration may succeed on another attempt
A step failed because credentials are wrong	Fix connection, then rerun	Retrying bad credentials usually fails again
A run is doing something unsafe or expensive	Stop	Prevents additional steps from executing
A run timed out during a large data operation	Optimize or increase timeout	The limit may be too low, or the step may need redesign
You want to test the flow without real side effects	Enable test mode with pinned data	Steps with pinned data return mock output instead of calling real systems

Troubleshooting Failed Runs

Follow this order to avoid guessing:

1. Find the first failed step -- Later failures are often side effects of the first one.
2. Read the error message and error type -- The execution record includes the error type, error message, stack trace, and error timestamp. Start with the message and only dig into the stack trace if you need more detail.
3. Inspect the previous step output -- Confirm the failed step received the data it expected. Mismatched data shapes are a common cause of step failures.
4. Check retry info -- See whether the step was retryable, how many retries were attempted, and what the maximum was. If all retries were exhausted, the error is likely persistent, not transient.
5. Check timing -- A fast failure often means configuration or permissions. A slow failure often means timeout, load, or external system delay.
6. Review the trigger context -- Confirm the job was triggered the right way with the right payload. Sometimes the issue is not the job but what triggered it.
7. Choose the fix -- Update configuration, repair data, refresh credentials, tune timeout, enable retry, or adjust error handling.

What Good Execution History Tells You

Execution history is more than a log. It helps you improve automations over time.

Pattern	What it may mean	What to improve
Same step fails repeatedly	Configuration, credential, or data shape issue	Fix the step instead of rerunning manually
Step succeeds only after retries	External dependency is flaky or rate-limited	Use retry backoff and monitor the integration
Duration keeps increasing	More data, slower API, or inefficient step	Optimize queries, split work, or tune timeouts
Scheduled run does not appear	Trigger or schedule issue	Check trigger configuration and enabled state
Runs stop after a manual action	Operational process issue	Clarify ownership and approval workflow
Jobs frequently go ON_HOLD	HIL steps are blocking throughput	Review whether all approvals are necessary or if some can be automated
Test mode runs succeed but production runs fail	Pinned data does not match real system behavior	Update pinned data to reflect realistic outputs

Related Pages

• Jobs and Steps - understand the building blocks of a job
• Error Handling - decide whether a failed step should stop or continue
• Retry Strategies - retry transient failures automatically
• Monitoring Automations - inspect runs, step outputs, and logs
• Logging - understand execution logs in detail