Kizen tracks status independently at each level.
space.vars.automations, executions, and steps in space.vars.Kizen\_company\_name, so administrators and developers can monitor activity, interpret errors, and troubleshoot space.vars.automations in production.
{% endhint %}
## Overview
space.vars.Kizen\_company\_name represents the state of every space.vars.automation, 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.
Kizen tracks status independently at each level.
space.vars.automation is either active or inactive and is controlled by the **Active?** toggle in the space.vars.automation 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 space.vars.automation. Each execution holds one of the following statuses at any given time, visible in the Executions panel of the workflow editor.
| Status | What It Means |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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 space.vars.automation 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.
| Status | What It Means |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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](#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](/docs/concepts/agentic-workflows/agentic-workflow-conditions.md).
### Throttled Indicators
Throttling limits how often an space.vars.automation will trigger for a given space.vars.entity. When throttling is configured and a trigger fires inside the quiet time window, the platform space.vars.entities the event but does not create a new execution.
{% hint style="info" %}
**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.
{% endhint %}
For full detail on throttling configuration and behavior, see [Agentic Workflow Execution & Process Model](/docs/concepts/agentic-workflows/agentic-workflow-execution-and-process-model.md).
***
## 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 space.vars.automation 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
space.vars.automations 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 space.vars.automation status, executions, and step state, the next topic covers how space.vars.condition\_steps and goal steps evaluate space.vars.entity data to direct executions down the correct path, including filter logic, path selection behavior, and how space.vars.condition\_step errors are handled at runtime. Continue to [Agentic Workflow Conditions](/docs/concepts/agentic-workflows/agentic-workflow-conditions.md).