Agentic Workflow Status & Lifecycle
Audience: Administrators, Developers, and Solution Architects
Purpose: Defines the statuses, indicators, and behavioral signals that represent the state of Agentic Workflows, executions, and steps in Kizen, so administrators and developers can monitor activity, interpret errors, and troubleshoot Agentic Workflows in production.
Overview
Kizen represents the state of every Agentic Workflow, its execution, and step through a defined set of statuses and visual indicators. Reading these accurately is essential for monitoring workflow activity, identifying when something requires attention, and resolving issues quickly.
Agentic Workflow Active vs. Inactive
An Agentic Workflow is either active or inactive and is controlled by the Active? toggle in the Agentic Workflow editor.
Active: Triggers are listening for events. When trigger conditions are met, the workflow creates new executions.
Inactive: Triggers are stopped. No new executions are created, regardless of what events occur.
Two things worth noting when toggling the active state:
Deactivating a workflow pauses any executions currently in progress. If a step is actively running when the workflow is deactivated, that step completes before the execution pauses.
Reactivating a workflow does not backfill missed events. Trigger events that occurred while the workflow was inactive are gone.
Execution Status Types
An execution is a single run of an Agentic Workflow. Each execution holds one of the following statuses at any given time, visible in the Executions panel of the workflow editor.
Active
The execution is currently being processed or is waiting in the queue for its next step.
Paused
The execution is waiting to resume. A user or another workflow applied an explicit pause. See Paused vs. Paused on Failure below for the distinction between a healthy pause and an error-triggered one. This state can also happen due to an Agentic Workflow being inactive.
Canceled
The execution has been terminated and will not resume. An execution can be canceled manually by a user or by a Stop Execution action step. Canceled executions cannot be restarted.
Completed
The execution has reached a terminal state and will not progress further. Completed does not mean every step succeeded; it means the execution finished. Please review the step history to confirm what actually happened.
Failed
The execution terminated because an unexpected system error could not be recovered through automatic retry. Failed is a terminal state and cannot be resumed.
Step Status Types
Each step within an execution has its own status, visible in the execution history view.
Step statuses are distinct from execution statuses. A step can be marked Failed while the overall execution reaches Completed. Step-level statuses are the primary tool for troubleshooting when an execution does not produce the expected outcome.
Pending
The step is waiting in the queue to be processed.
Pending Retry
The step encountered an unexpected error and has been queued for an automatic retry.
Completed
The step finished successfully.
Failed
The step encountered an error, but the execution continued to the next step. This occurs when the step is configured for Continue and Notify on Failure or Continue on Failure and Do Not Notify behavior.
Paused by Failure
The step encountered an error and the execution was paused for user intervention. This occurs when the step is configured for Pause and Notify on Failure behavior, or when an invalid filter is encountered on a condition or goal step.
Debug Waiting
The step is paused in a debug session waiting for a manual advance action. See Debug Mode Behavior below.
Agentic Workflow Errors & Indicators
The platform uses specific visual cues to signal when something requires attention. This section covers the indicators that distinguish healthy state from error state and explains what each means operationally.
Paused vs. Paused on Failure
An execution can be paused for two very different reasons:
Paused: A manual pause was applied to the execution. The execution will remain paused unless an action is taken by the user
Paused by Failure: A step encountered an error the system could not automatically recover from, and the execution is held until a user intervenes. When this happens, all branches of the workflow pause, not just the branch containing the failed step. Action is required: review the error, resolve the underlying issue if possible, and restart the execution and either skip the step or retry the step.
For detail on path-selection behavior when a condition or goal step causes a pause, see Agentic Workflow Conditions.
Throttled Indicators
Throttling limits how often an Agentic Workflow will trigger for a given Record. When throttling is configured and a trigger fires inside the quiet time window, the platform Records the event but does not create a new execution.
Note: A throttled indicator is expected behavior, not an error. It means the platform applied the throttling rule the workflow was configured with. If the indicator is unexpected, review the throttling configuration on the trigger.
For full detail on throttling configuration and behavior, see Agentic Workflow Execution & Process Model.
Agentic Workflow Behaviors
The following behaviors describe how specific actions and modes affect execution state at runtime.
Cancel Behavior
When an execution is canceled, either manually by a user or by a Stop Execution action step, it transitions to the Canceled status and does not continue. Canceled executions cannot be resumed or restarted.
Debug Mode Behavior
Debug mode lets developers and administrators step through an Agentic Workflow interactively before activating it for production use. When an execution is running in debug mode, the platform pauses at each step in a Debug Waiting state until the user manually advances it.
Debug mode also changes error handling behavior. Outside debug mode, an unexpected step error triggers an automatic retry. Inside debug mode, the same error pauses the step on failure instead, so the issue can be inspected directly.
Notification Settings
Agentic Workflows support notifications when errors occur. Notification settings are configured per workflow through the Error Notification Settings dialog.
The dialog provides two configuration options:
Additional Error Notification Email: An email address that receives notifications in addition to the workflow owner. Leave blank to send notifications only to the owner.
Error Notification Severity: Sets the minimum severity level at which errors are reported in the Notification Center.
For errors that pause an execution, the platform sends a notification email up to once every 24 hours per workflow. Each step that errors sends a distinct notification.
What's Next
Now that you can interpret Agentic Workflow status, executions, and step state, the next topic covers how Conditions and goal steps evaluate Record data to direct executions down the correct path, including filter logic, path selection behavior, and how Condition errors are handled at runtime. Continue to Agentic Workflow Conditions.
Last updated
Was this helpful?