Agentic Workflow Core Concepts
Audience: Admins, Developers, and Solution Architects
Purpose: Explains the foundational architecture of Agentic Workflows in Kizen, including how executions are structured, how context and scope work, and the system-level behaviors that govern how Agentic Workflows run.
Overview
Agentic Workflows 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 Record or globally across the platform.
Before configuring triggers, designing execution logic, or working with the Agentic Workflows API, it helps to have a clear mental model of how Agentic Workflows 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
Agentic Workflow
A configured workflow that listens for a triggering event and executes a series of steps against a Record or globally across Kizen.
Event
A condition or occurrence that causes an Agentic Workflow 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 Agentic Workflow. Each execution is independent, maintains its own state, and progresses through the Agentic Workflow's steps sequentially.
Record Context
The mode in which an Agentic Workflow operates against a specific Record. Most Agentic Workflows run in Record context, meaning all step actions are scoped to a single Record and its related data.
Global Context
The mode in which an Agentic Workflow operates without being scoped to a specific Record. Global Agentic Workflows 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 Record it is operating on (if applicable), the current variable state, and the step being processed at any given moment.
Conceptual Model
Every Agentic Workflow in Kizen — 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.
An event fires: Something happens that the Agentic Workflow 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 Agentic Workflow evaluates whether a new execution should begin.
An execution is created: If the trigger conditions are met, Kizen creates a new execution and places it in the processing queue. Because Agentic Workflows 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 Agentic Workflows documentation set. Understanding it will help you interpret execution history, design reliable logic, and troubleshoot unexpected behavior.
Record-Scoped vs. Global Agentic Workflows
Most Agentic Workflows in Kizen are Record-scoped. This means the execution operates in the context of a single Record (a Contact, a Workflow, or another Custom Object) and every step within that execution acts on that Record and its related data.
Global Agentic Worflows are a distinct configuration. They operate without a Record context, making them suitable for platform-wide logic that is not tied to a single Record, such as running a recurring job or performing cross-object operations. Because Global Agentic Workflows have no inherent record context, the set of available triggers and actions is more limited than in record-scoped Agentic Workflows.
The distinction between Record-scoped and global Agentic Workflows affects what data is accessible at runtime, which triggers and actions are available, and how variables resolve during execution.
Key Differences
Operates against a specific Record
Yes
No
Available triggers
Full set
Limited
Available actions
Full set
Limited
Supports Record variables
Yes
Yes (assigned manually)
Supports Workflow 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 Agentic Workflow. 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.
Trigger (Coming Soon)
The condition or event that causes an Agentic Workflow 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 Agentic Workflow should respond.
Step (Coming Soon)
An individual unit of work within an Agentic Workflow.
Steps execute sequentially, and each runs in its own transaction.
To define the discrete actions, decisions, or waits that make up the Agentic Workflow'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 Agentic Workflow's flow.
Action (Coming Soon)
A step that performs an operation.
Executes an operation — such as updating a field, sending a notification, creating a Record, or calling an external system — against the execution context.
To produce the outcomes the Agentic Workflow 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 Agentic Workflow 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 Record 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 Workflows, such as pausing a drip sequence until a Contact takes a specific action.
Variables (Coming Soon)
Named values that are evaluated and stored within the scope of a single execution.
Variables draw from Record 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 Agentic Workflow behavior dynamic.
System Behaviors
These principles inform how Agentic Workflows should be designed and how their behavior should be interpreted.
Asynchronous by design
Agentic Workflows are queued and processed after an event fires, not in real time.
Don't rely on Agentic Workflows 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 Agentic Workflows 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
Agentic Workflows run with elevated access, bypassing the permissions of the user who configured or triggered them.
Be deliberate when Agentic Workflows 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 Agentic Workflow does not process Records that already met the trigger condition.
To process pre-existing Records, use a manual or bulk start after activation.
Triggers only listen while active
Deactivating an Agentic Workflow stops trigger listening entirely. Events during inactivity are not captured or backfilled.
There is no backlog catchup on reactivation. The Agentic Workflow begins listening from the moment it becomes active again.
Key Use Cases
Agentic Workflows support the following industry use cases:
Industry Examples
Agentic Workflows 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 Records.
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 Agentic Workflow to receive inbound data from an external policy administration system and update the corresponding Record in Kizen
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
Agentic Workflows enable healthcare teams to respond to clinical and administrative events, coordinate care transitions, and maintain consistent engagement across patient and referral Records.
Examples include:
Triggering a care pathway Agentic Workflow when a referral Record 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 Agentic Workflow 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
Agentic Workflows 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 Agentic Workflow when an Opportunity record moves to a Closed Won stage, triggering document requests, task assignments, and welcome communications
Using a scheduled global Agentic Workflow 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 Agentic Workflow to receive portfolio data from an external custodial platform and update account records in Kizen
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
What's Next
With a shared vocabulary and a clear mental model in place, the next step is understanding how Agentic Workflows are initiated. The Starting Agentic Workflows (Topic Coming Soon) topic covers every supported method for starting an Agentic Workflow — 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.
Last updated
Was this helpful?