Starting Agentic Workflows
Audience: Administrators, Developers, Solution Architects
Purpose: Documents every supported method for initiating an Agentic Workflow in Kizen and explains the key behaviors and configuration considerations for each, so readers can choose the right initiation approach before configuring triggers or designing execution logic.
Overview
Agentic Workflows in Kizen can be initiated in several ways: by a user acting directly on a Record, on a scheduled date and time, in response to a data event or external signal, or by another Agentic Workflow. The method you choose determines when an execution begins, what Record context is available at runtime, and how the resulting execution is identified and tracked.
Understanding the available initiation methods is the first step toward designing Agentic Workflows that start at the right time, in the right context, and for the right reasons.
Manual & User-Initiated Starts
Agentic Workflows can be started manually by any authorized user using the following methods.
Manual Trigger
Starts an execution on demand from a Record
Present on every Agentic Workflow; cannot be removed
Start from a Record
Initiates an execution directly from the Record interface
Starts immediately in the context of that Record. See Records
Bulk Start via Modify Agentic Workflow
Starts an Agentic Workflow across multiple Records simultaneously using the Modify Agentic Workflow bulk action
Appears in execution history as a manual trigger initiated by the user. See Bulk Start: Execution History Behavior
Layout Action Block
Surfaces a curated set of Agentic Workflows on a Record layout so users can initiate them directly from the Record view
Requires layout configuration. See Record Layout Customization
Resume Paused Toggle
Controls whether existing paused executions are resumed or whether new executions are created when starting manually or in bulk
Toggle is available at the time of start
Reactivation
Restarts trigger listening when an inactive Agentic Workflow is turned active again
Does not process events that occurred while inactive. See No Backlog Behavior on Reactivation
Bulk Start: Execution History Behavior
When an Agentic Workflow is started via the Modify Agentic Workflow bulk action, each resulting execution appears in execution history as a manual trigger initiated by the user, not as a distinct bulk trigger type. If you are auditing executions or troubleshooting unexpected runs, bulk-initiated executions are attributed to the user who performed the action and are indistinguishable in the execution list from individual manual starts.
No Backlog Behavior on Reactivation
When an Agentic Workflow is deactivated, it stops listening for triggers entirely. Reactivating an Agentic Workflow does not cause it to retroactively process Records or events that occurred while it was inactive. There is no backlog catchup. The Agentic Workflow begins listening from the moment it becomes active again.
This is a firm behavioral boundary, not a configuration option. If you need to run an Agentic Workflow against Records that were not processed during an inactive period, use a bulk start to target them manually after reactivating.
Scheduled & Event-Based Starts
Event-based triggers fire when a specific action occurs on a Record. For more information on these types of starts see, Action Based Triggers.
Scheduled triggers fire based on time rather than a user action or data change. For more information on these types of starts see, Scheduled Triggers.
Automation-to-Automation Starts
An Agentic Workflow can include a Start Agentic Workflow action that initiates another Agentic Workflow. This step can target an Agentic Workflow on the same Record, on a related Record, on a Record identified by a variable, or a global Agentic Workflow with no Record context. This pattern is useful for chaining specialized Agentic Workflows together, separating concerns across distinct Agentic Workflow configurations, or handing off execution once a specific phase of a Workflow is complete.
When an Agentic Workflow is started this way, the resulting execution appears in execution history identifying both the called and calling Agentic Workflows, formatted as the called Agentic Workflow name started by the calling Agentic Workflow name. This makes it distinguishable from a manual trigger or an event-based trigger, and provides a clear audit trail showing which Agentic Workflow initiated the execution and which Agentic Workflow was started as a result.
Note: The ability to pass variable overrides when starting an Agentic Workflow from another Agentic Workflow is a planned capability and is not yet supported. Variable overrides would allow the initiated execution to be seeded with data from the calling Agentic Workflow's context.
What's Next
The next step is a deeper look at Agentic Workflow Triggers, including how each trigger type evaluates conditions, how timing and throttling affect execution, and the rules that govern each trigger's behavior. For more information, continue to the Agentic Workflow Triggers topic.
Last updated
Was this helpful?