Agentic Workflow Triggers
Audience: Administrators, Solution Architects, and Developers
Purpose: Documents all supported trigger types in Kizen, explains how each one evaluates and fires, and covers the timing and throttling behaviors that govern when Agentic Workflows are initiated.
Overview
Triggers are the mechanism by which Agentic Workflows listen for and respond to events. When a trigger condition is met, Kizen initiates a new execution of the Agentic Workflow and begins processing its configured steps.
Trigger Foundations
The following ground rules apply to all Agentic Workflows, regardless of trigger type.
Every Agentic Workflow includes a manual trigger: A manual trigger is automatically added to every Agentic Workflow at creation. It provides an always-available on-demand initiation method that allows authorized users to start the Agentic Workflow against a Record at any time. The manual trigger coexists alongside any other configured triggers and does not need to be added separately.
Available trigger types depend on Agentic Workflow context: The set of supported triggers differs across Contact Agentic Workflows, Workflow Agentic Workflows, Global Agentic Workflows, and Object Agentic Workflows. Not every trigger type is available in every context. Context-specific triggers are called out explicitly in each section below.
There is no indicator for duplicate triggers: Kizen does not display a warning if the same trigger type is configured more than once on an Agentic Workflow. Duplicate triggers can cause a Record to enter the Agentic Workflow multiple times from a single event. You are responsible for identifying and removing duplicate trigger configurations.
Trigger order is not guaranteed: When multiple triggers are configured on an Agentic Workflow, the order in which they fire relative to one another is not guaranteed. Agentic Workflow logic that depends on one trigger firing before another cannot rely on ordering.
Trigger Types
Kizen Agentic Workflows support three categories of triggers. Each category covers a distinct class of initiation event.
Action-based
Fires when a specific activity type is logged on a Record.
Objects, Workflows, Contacts
Record, Global
Scheduled
Fires when a scheduled activity's due date passes without the activity being completed.
Objects, Workflows, Contacts
Record, Global
Action-based
Fires when a new Record is created for the associated Object.
Objects, Workflows, Contacts
Record
Action-based
Fires when a specified field's value changes on a Record. Supports from/to value configuration and blank transitions.
Objects, Workflows, Contacts
Record
Scheduled
Fires based on a date field value on a Record, scheduling future executions relative to that date.
Objects, Workflows, Contacts
Record
Action-based
Fires when a Record moves from one Workflow stage to another.
Workflows only
Record
Action-based
Fires when a form associated with the Record is submitted.
Record-based Agentic Workflows only
Record
Action-based
Fires when a survey associated with the Record is submitted.
Record-based Agentic Workflows only
Record
Webhook
Fires when an inbound HTTP request is received from an external system. Supports JSON payload and URL query parameter extraction.
Objects, Workflows, Contacts
Record, Global
Action-based
Fires when an email is received from a contact.
Contacts only
Record
Action-based
Fires when a specific tag is added to or removed from a Record.
Contacts only
Record
Scheduled
Fires on a user-configured recurring schedule. Runs independently of any specific Record.
Global only
Global
Trigger Timing & Throttling
Understanding when a trigger evaluates and how throttling affects that evaluation is essential for designing Agentic Workflows that behave predictably. These behaviors apply to all trigger types.
Asynchronous Queue Evaluation
Triggers do not evaluate synchronously at the moment an event occurs. When a trigger condition is met, the event is queued and evaluated asynchronously. There may be a delay between when an event fires and when the Agentic Workflow begins processing. This delay is normal and expected and is not an indication that a trigger failed or was missed.
Trigger Event Time vs. Evaluation Time
Two distinct timestamps are associated with every trigger: the time the event occurred, and the time the trigger was evaluated from the queue. These may differ, particularly under high load or when queue processing is delayed. Both values are recorded and accessible within the Agentic Workflow.
Throttling (Quiet Time Window)
Throttling functions as a quiet time or mute window. It is not a mechanism for spacing out or delaying executions.
When throttling is configured on a trigger, additional trigger evaluations for the same record are suppressed within a defined time window after the first trigger fires. Events that occur within that window are discarded and do not queue up to fire later.
Throttling prevents additional executions from being initiated within the time window.
It does not delay or redistribute executions.
Events suppressed by throttling are not recovered after the time window closes.
Trigger Timestamp Variable Source
The timestamp of the trigger event is available as a variable source within the Agentic Workflow, captured at the time the execution is created. This value is useful when steps need to reference when the triggering event occurred. For example, logging when a webhook was received or calculating a deadline relative to when a field was updated.
What's Next?
Continue to Action-Based Triggers to understand what happens after an Agentic Workflow is initiated: how executions are created, how steps are processed sequentially and atomically, how the asynchronous model affects data consistency, and how execution state is tracked and managed.
Reviewing the Agentic Workflow Execution & Processing Model in sequence with this page is recommended if you are designing Agentic Workflows where execution timing, step ordering, or data consistency are important.
Last updated
Was this helpful?