# Agentic Workflow Core Concepts

{% hint style="success" %}
**Audience:** Admins, Developers, and Solution Architects

**Purpose:** Explains the foundational architecture of <code class="expression">space.vars.automations</code> in <code class="expression">space.vars.Kizen\_company\_name</code>, including how executions are structured, how context and scope work, and the system-level behaviors that govern how <code class="expression">space.vars.automations</code> run.
{% endhint %}

## Overview

<code class="expression">space.vars.automations</code> are the platform's engine for responding to events, executing logic, and producing outcomes without manual intervention. They listen for a triggering event, evaluate whether execution should begin, and then process a series of steps against a <code class="expression">space.vars.entity</code> or globally across the platform.

Before configuring triggers, designing execution logic, or working with the <code class="expression">space.vars.automations</code> API, it helps to have a clear mental model of how <code class="expression">space.vars.automations</code> are structured and how they behave. The concepts on this page apply universally, regardless of the trigger type, step configuration, or use case you are working with.

***

## Foundational Definitions

| Term                  | Definition                                                                                                                                                                                                                                                                                                                                                                                                      |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Agentic Workflow**  | A configured workflow that listens for a triggering event and executes a series of steps against a <code class="expression">space.vars.entity</code> or globally across <code class="expression">space.vars.Kizen\_company\_name</code>.                                                                                                                                                                        |
| **Event**             | A condition or occurrence that causes an <code class="expression">space.vars.automation</code> to begin evaluating whether it should start a new execution. Events may be user-initiated, data-driven, time-based, or externally triggered.                                                                                                                                                                     |
| **Execution**         | A single run of an <code class="expression">space.vars.automation</code>. Each execution is independent, maintains its own state, and progresses through the <code class="expression">space.vars.automation</code>'s steps sequentially.                                                                                                                                                                        |
| **Record Context**    | The mode in which an <code class="expression">space.vars.automation</code> operates against a specific <code class="expression">space.vars.entity</code>. Most <code class="expression">space.vars.automations</code> run in <code class="expression">space.vars.entity</code> context, meaning all step actions are scoped to a single <code class="expression">space.vars.entity</code> and its related data. |
| **Global Context**    | The mode in which an <code class="expression">space.vars.automation</code> operates without being scoped to a specific <code class="expression">space.vars.entity</code>. Global <code class="expression">space.vars.automations</code> are used for platform-wide logic that is not tied to a single entity.                                                                                                   |
| **Execution Context** | The runtime environment of a single execution, including the <code class="expression">space.vars.entity</code> it is operating on (if applicable), the current variable state, and the step being processed at any given moment.                                                                                                                                                                                |

***

## Conceptual Model

Every <code class="expression">space.vars.automation</code> in <code class="expression">space.vars.Kizen\_company\_name</code> — regardless of its trigger type, step count, or complexity — follows the same four-stage flow: an event fires, an execution is created, steps are processed in sequence, and the execution reaches a terminal state.

<div data-with-frame="true"><figure><img src="/files/XFAKcJcm7sdOMr3vW7dk" alt="" width="563"><figcaption></figcaption></figure></div>

* **An event fires:** Something happens that the <code class="expression">space.vars.automation</code> is configured to listen for like a field being updated, a form is submitted, a scheduled time arrives, or a user initiates a manual start. At this point, the <code class="expression">space.vars.automation</code> evaluates whether a new execution should begin.
* **An execution is created:** If the trigger conditions are met, <code class="expression">space.vars.Kizen\_company\_name</code> creates a new execution and places it in the processing queue. Because <code class="expression">space.vars.automations</code> are asynchronous, execution does not begin instantaneously, there is a short delay between when the event fires and when the first step begins processing. This is by design.
* **Steps are processed in sequence:** The execution works through each step in the order it is configured. Each step runs in its own transaction. Conditions branch the execution down different paths, actions perform operations, delays introduce pauses, and goals wait for conditions to be met before proceeding.
* **The execution reaches a terminal state:** When there are no more steps to process, or when a stopping condition is reached, the execution resolves. The terminal states an execution can reach are **Completed**, **Canceled**, and **Failed**.

This four-stage model is the foundation for everything else in the <code class="expression">space.vars.automations</code> documentation set. Understanding it will help you interpret execution history, design reliable logic, and troubleshoot unexpected behavior.

### Record-Scoped vs. Global Agentic Workflows

Most <code class="expression">space.vars.automations</code> in <code class="expression">space.vars.Kizen\_company\_name</code> are **Record-scoped**. This means the execution operates in the context of a single <code class="expression">space.vars.entity</code> (a <code class="expression">space.vars.contact</code>, a <code class="expression">space.vars.workflow</code>, or another Custom <code class="expression">space.vars.object</code>) and every step within that execution acts on that <code class="expression">space.vars.entity</code> and its related data.

**Global Agentic Worflows** are a distinct configuration. They operate without a <code class="expression">space.vars.entity</code> context, making them suitable for platform-wide logic that is not tied to a single <code class="expression">space.vars.entity</code>, such as running a recurring job or performing cross-object operations. Because Global <code class="expression">space.vars.automations</code> have no inherent record context, the set of available triggers and actions is more limited than in record-scoped <code class="expression">space.vars.automations</code>.

The distinction between <code class="expression">space.vars.entity</code>-scoped and global <code class="expression">space.vars.automations</code> affects what data is accessible at runtime, which triggers and actions are available, and how variables resolve during execution.

#### Key Differences

| Aspect                                                                          | Record-Scoped                                 | Global                                  |
| ------------------------------------------------------------------------------- | --------------------------------------------- | --------------------------------------- |
| Operates against a specific <code class="expression">space.vars.entity</code>   | Yes                                           | No                                      |
| Available triggers                                                              | Full set                                      | Limited                                 |
| Available actions                                                               | Full set                                      | Limited                                 |
| Supports <code class="expression">space.vars.entity</code> variables            | Yes                                           | Yes (assigned manually)                 |
| Supports <code class="expression">space.vars.workflow</code> and stage triggers | Yes                                           | No                                      |
| Common use                                                                      | Field updates, notifications, lifecycle logic | Scheduled jobs, cross-object operations |

### High-Level Components

The following table introduces the core components of an <code class="expression">space.vars.automation</code>. Each component is covered in depth in its own dedicated topic; this table is intended to orient you to what each component is and why it exists, not to serve as a complete reference.

| Component                   | What It Is                                                                                            | How It Works                                                                                                                                                                                                                          | Why Use It                                                                                                                                                                                                           |
| --------------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Trigger (Coming Soon)**   | The condition or event that causes an <code class="expression">space.vars.automation</code> to start. | Listens for a specific occurrence — such as a field update, a scheduled time, a form submission, or a webhook — and initiates a new execution when the condition is met.                                                              | To define precisely when an <code class="expression">space.vars.automation</code> should respond.                                                                                                                    |
| **Step (Coming Soon)**      | An individual unit of work within an <code class="expression">space.vars.automation</code>.           | Steps execute sequentially, and each runs in its own transaction.                                                                                                                                                                     | To define the discrete actions, decisions, or waits that make up the <code class="expression">space.vars.automation</code>'s logic.                                                                                  |
| **Condition (Coming Soon)** | A branching step that evaluates one or more criteria and routes execution based on the result.        | Evaluates the criteria against the execution context and directs execution down a yes path or a no path.                                                                                                                              | To introduce logic and decision points into an <code class="expression">space.vars.automation</code>'s flow.                                                                                                         |
| **Action (Coming Soon)**    | A step that performs an operation.                                                                    | Executes an operation — such as updating a field, sending a notification, creating a <code class="expression">space.vars.entity</code>, or calling an external system — against the execution context.                                | To produce the outcomes the <code class="expression">space.vars.automation</code> is designed to achieve.                                                                                                            |
| **Delay (Coming Soon)**     | A step that pauses execution for a defined period of time before proceeding.                          | Holds the execution for a static or variable-based duration, then releases it to the next step.                                                                                                                                       | To introduce timing into <code class="expression">space.vars.automation</code> logic, such as waiting before sending a follow-up.                                                                                    |
| **Goal (Coming Soon)**      | A step that pauses execution and waits for a specified condition to be met.                           | Monitors the execution's <code class="expression">space.vars.entity</code> for the defined condition. If the condition is met, execution proceeds down the success path. If a timeout occurs, execution proceeds down the unmet path. | To build conditional waiting behavior into <code class="expression">space.vars.workflows</code>, such as pausing a drip sequence until a <code class="expression">space.vars.contact</code> takes a specific action. |
| **Variables (Coming Soon)** | Named values that are evaluated and stored within the scope of a single execution.                    | Variables draw from <code class="expression">space.vars.entity</code> fields, trigger outputs, and other sources. They are evaluated in order and the first successful source sets the value.                                         | To pass data between steps, drive conditional logic, and make <code class="expression">space.vars.automation</code> behavior dynamic.                                                                                |

***

## System Behaviors

These principles inform how <code class="expression">space.vars.automations</code> should be designed and how their behavior should be interpreted.

| Principle                                 | What it means                                                                                                                                                                   | What it means for you                                                                                                                                            |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Asynchronous by design**                | <code class="expression">space.vars.automations</code> are queued and processed after an event fires, not in real time.                                                         | Don't rely on <code class="expression">space.vars.automations</code> for instant outcomes. Expect a short delay between an event and the start of execution.     |
| **Fully traceable**                       | Every execution and every step within it is logged automatically.                                                                                                               | Use execution history as your first tool when verifying outcomes or troubleshooting unexpected behavior.                                                         |
| **Atomic save behavior**                  | There is no versioning. Saving a change takes effect immediately, including for in-progress executions.                                                                         | Save changes to active <code class="expression">space.vars.automations</code> carefully. In-flight executions reflect your update the moment it is saved.        |
| **Step processing is atomic**             | Each step runs in its own transaction. A failed step does not roll back prior steps.                                                                                            | Partial execution is possible. Always verify step-level outcomes in execution history.                                                                           |
| **Order is guaranteed only linearly**     | Steps follow configured order on a linear path, but order is not guaranteed across parallel branches or simultaneous executions.                                                | If strict ordering matters, keep your logic linear.                                                                                                              |
| **Permissions do not apply at runtime**   | <code class="expression">space.vars.automations</code> run with elevated access, bypassing the permissions of the user who configured or triggered them.                        | Be deliberate when <code class="expression">space.vars.automations</code> modify sensitive data. Standard permission checks do not apply during execution.       |
| **Completed ≠ successful**                | A Completed status means execution finished, not that every step produced the intended result.                                                                                  | Always review execution history to confirm outcomes.                                                                                                             |
| **Steps should be retryable**             | The system may retry a failed step under certain conditions.                                                                                                                    | Where possible, design steps so running them more than once does not produce harmful side effects.                                                               |
| **Agentic Workflows are not retroactive** | Activating an <code class="expression">space.vars.automation</code> does not process <code class="expression">space.vars.entity</code>s that already met the trigger condition. | To process pre-existing <code class="expression">space.vars.entity</code>s, use a manual or bulk start after activation.                                         |
| **Triggers only listen while active**     | Deactivating an <code class="expression">space.vars.automation</code> stops trigger listening entirely. Events during inactivity are not captured or backfilled.                | There is no backlog catchup on reactivation. The <code class="expression">space.vars.automation</code> begins listening from the moment it becomes active again. |

***

## Key Use Cases

<code class="expression">space.vars.automations</code> support the following industry use cases:

### Industry Examples

{% tabs %}
{% tab title="Insurance" %} <code class="expression">space.vars.automations</code> provide the operational backbone for insurance workflows by responding to data changes, triggering follow-up actions, and managing lifecycle transitions across policies, applications, and member <code class="expression">space.vars.entities</code>.

**Examples include:**

* Triggering a renewal workflow when a policy's expiration date is within 60 days, using an On or Around Date trigger scoped to a Policy Object
* Starting an onboarding sequence when an application moves to an Approved stage, using a Stage Updated trigger
* Sending an automated follow-up to an agent when a submitted application has not been reviewed within 48 hours, using a Delay step followed by a conditional notification action
* Using a webhook-triggered <code class="expression">space.vars.automation</code> to receive inbound data from an external policy administration system and update the corresponding <code class="expression">space.vars.entity</code> in <code class="expression">space.vars.Kizen\_company\_name</code>

**How Agentic Workflows help:**

* Reduce manual handoffs across underwriting, servicing, and compliance workflows
* Enforce consistent follow-up cadences without relying on individual team members
* Respond to external system events in real time through webhook-based triggers
* Maintain audit trails through full execution history and step-level logging
  {% endtab %}

{% tab title="Healthcare" %} <code class="expression">space.vars.automations</code> enable healthcare teams to respond to clinical and administrative events, coordinate care transitions, and maintain consistent engagement across patient and referral <code class="expression">space.vars.entities</code>.

**Examples include:**

* Triggering a care pathway <code class="expression">space.vars.automation</code> when a referral <code class="expression">space.vars.entity</code> moves to an Accepted stage, automatically creating intake tasks and assigning them to the appropriate care coordinator
* Sending appointment reminders to patients using a scheduled <code class="expression">space.vars.automation</code> scoped to an Appointments Object, triggered by an On or Around Date condition relative to the scheduled visit date
* Using a Goal step to pause a follow-up sequence until a patient completes a required intake form, then routing execution based on whether the goal was met or timed out
* Triggering a notification to a supervisor when a high-priority case has not advanced stages within a defined window

**How Automations help:**

* Eliminate manual coordination steps between intake, scheduling, and care delivery
* Maintain consistent outreach cadences across large patient populations
* Surface exceptions and delays before they affect care outcomes
* Support compliance and documentation requirements through traceable execution history
  {% endtab %}

{% tab title="Finance" %} <code class="expression">space.vars.automations</code> help financial services teams manage client lifecycle events, enforce operational processes, and respond to data changes across client, account, and opportunity records.

**Examples include:**

* Starting an onboarding <code class="expression">space.vars.automation</code> when an Opportunity record moves to a Closed Won stage, triggering document requests, task assignments, and welcome communications
* Using a scheduled global <code class="expression">space.vars.automation</code> to run a daily review of accounts with upcoming review dates and create follow-up tasks for assigned advisors
* Triggering a compliance notification when a required field on a Client Profile record is left blank for more than a defined period, using a Field Updated trigger with a Delay step
* Using a webhook-triggered <code class="expression">space.vars.automation</code> to receive portfolio data from an external custodial platform and update account records in <code class="expression">space.vars.Kizen\_company\_name</code>

**How Automations help:**

* Enforce consistent onboarding and servicing processes across advisors and teams
* Reduce operational risk by automating compliance-adjacent reminders and checks
* Maintain a complete audit trail of automated actions across client and account records
* Respond to external data events through webhook integration without manual intervention
  {% endtab %}
  {% endtabs %}

***

## What's Next

With a shared vocabulary and a clear mental model in place, the next step is understanding how <code class="expression">space.vars.automations</code> are initiated. The Starting Agentic Workflows **(Topic Coming Soon)** topic covers every supported method for starting an <code class="expression">space.vars.automation</code> — from manual triggers and bulk starts to scheduled runs, event-based triggers, and webhook-driven initiation — and explains the key behaviors and configuration considerations for each.

<details>

<summary>Related Topics</summary>

* [Agentic Workflows](/docs/concepts/agentic-workflows.md)
* [Starting Agentic Workflows](/docs/concepts/agentic-workflows/starting-agentic-workflows.md)
* [Agentic Workflow Triggers](/docs/concepts/agentic-workflows/agentic-workflow-triggers.md)
* [Agentic Workflow Actions](/docs/concepts/agentic-workflows/agentic-workflow-actions.md)

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/concepts/agentic-workflows/agentic-workflow-core-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.