Flow Event Trigger

flow event triggers enable playbooks to listen for and respond to events emitted by other playbooks using the emit event native action this creates a powerful mechanism for inter playbook communication, allowing you to build complex, distributed workflows where one playbook can trigger another based on specific conditions or outcomes overview flow event triggers work in conjunction with the emit event native action to create event driven workflows emit event action generates events during playbook execution with custom data flow event trigger listens for specific events and initiates playbooks when those events are emitted this pattern enables you to decouple workflows into smaller, focused playbooks create reusable playbook components build event driven architectures trigger multiple playbooks from a single event process events asynchronously without blocking the emitting playbook key benefits inter playbook communication enable playbooks to communicate and trigger each other asynchronous processing emitted events are processed asynchronously, allowing the emitting playbook to continue execution event driven architecture build complex workflows based on event patterns reusability create reusable playbook components that can be triggered by multiple sources scalability events are distributed across scaled services for parallel processing creating a flow event trigger to create a flow event trigger from the add section, drag and drop flow event to the playbook canvas click on the added flow event trigger to view the trigger configuration panel configuring the flow event trigger step 1 select flow event type choose between existing flow event or create flow event option a existing flow event select existing flow event from the toggle in the flow event dropdown, choose from a list of already created flow events the dropdown shows all available flow events (sensors) in your tenant each event shows its title (human readable name) optionally add or edit a description to document the trigger's purpose note when selecting an existing flow event, the event data schema is already defined you can configure conditions but cannot modify the event data structure option b create flow event select create flow event from the toggle configure the following fields flow event title enter a human readable name for the event (e g , "email processed", "incident escalated") this is displayed in the ui flow event name a unique identifier for the event (auto generated from the title, but can be edited) must contain only letters, numbers, and underscores (a z, a z, 0 9, ) description (optional) add a description explaining the purpose of the event important the flow event name (sensor name) must match exactly between the emit event action and the flow event trigger this is the key used to match events step 2 configure event data schema (create flow event only) if you selected create flow event , you need to define the event data schema click configure to open the event data configuration dialog in the event data section, define the properties for the event data click add property to add a new data property configure each property with property name the key used to access this data in the triggered playbook property type choose from string text values number numeric values (default 0 ) boolean true or false values object nested objects (add properties within the object) array arrays of values (define the item type) attachment file attachments note the event data schema defines what data can be emitted and received both the emit event action and flow event trigger must use compatible schemas step 3 configure conditions (optional) in the configuration dialog, you can add conditions to filter when the playbook should be triggered conditions evaluate the event data and determine if the playbook should run click apply to save your configuration for more information about emit event native action, see documentation how flow event triggers work event matching flow event triggers match events based on the sensor name (flow event name), not the title the matching process works as follows emit event action emits an event with sensorname the unique identifier (flow event name) eventdata the data payload to send flow event trigger listens for events matching the sensor name must match exactly between emit event and flow event trigger optional conditions can further filter events when a match is found, the triggered playbook starts execution with the event data event processing asynchronous execution events are processed asynchronously the playbook emitting the event continues execution immediately without waiting for triggered playbooks to complete concurrent processing multiple playbooks can be triggered by the same event, and they execute concurrently no order guarantee due to distributed processing across scaled services, there is no guarantee of execution order for multiple triggered playbooks event distribution events are distributed across scaled services for parallel processing flow event trigger outputs when a flow event trigger fires, it provides event data that can be accessed in your playbook event data structure the event data is available via $event data and contains the properties defined in the event data schema additionally, you can access event metadata $event data the event data payload (properties defined in the event schema) $event type event type (always "flow" for flow events) $event action event action (always "emit" for flow events) $event fqn fully qualified event name (format sensorname type ) $event timestamp timestamp when the event was received (milliseconds since epoch) $event sensor name the sensor name (flow event name) $event sensor tags sensor tags (if any) $event agent name name of the agent that processed the event $event agent tags agent tags (if any) $event tags combined sensor and agent tags accessing event data in playbooks you can access event data in your playbook actions using the $event data prefix examples \# access event data properties $event data propertyname $event data emailsender $event data incidentid \# access nested object properties $event data user name $event data user email \# access array elements (in loops) $event data items\[0] $loop value # when looping over $event data items \# access event metadata $event sensor name $event timestamp note property names must match exactly as defined in the event data schema property names are case sensitive key considerations sensor name matching the flow event name (sensor name) must match exactly between the emit event action and the flow event trigger the title can be different, but the name must match event data schema when creating a new flow event, define the event data schema in the trigger configuration the emit event action must emit data that matches this schema asynchronous processing events are processed asynchronously the emitting playbook continues execution immediately no order guarantee multiple playbooks triggered by the same event may execute in any order event persistence events are processed in real time if a playbook is not running or disabled when an event is emitted, it will not be triggered maximum event chain depth by default, turbine limits event chaining (event > playbook > emit event > playbook) to 10 levels conditions use conditions in the flow event trigger to filter events based on data values before triggering the playbook example scenarios example 1 processing emails with event correlation scenario a playbook processes incoming emails and emits an event when an email matches certain criteria another playbook listens for this event and saves the email data to a database configuration playbook a (email processor) add an emit event action after processing emails configure the emit event sensor name email processed event data sender email sender address subject email subject content email content timestamp email timestamp playbook b (email storage) add a flow event trigger select existing flow event and choose email processed configure conditions (optional) only trigger if $event data sender contains "@company com" add actions to save email data use create record action map $event data sender to record field map $event data subject to record field map $event data content to record field result when playbook a processes an email, it emits an event playbook b listens for this event and automatically saves the email data to a database record example 2 incident escalation chain scenario when an incident is escalated, emit an event that triggers multiple playbooks one to notify stakeholders, another to update external systems, and a third to create a follow up task configuration playbook a (incident escalation) add an emit event action after escalating an incident configure the emit event sensor name incident escalated event data incidentid incident tracking id priority new priority level escalatedby user who escalated reason escalation reason playbook b (notification) add a flow event trigger for incident escalated add send notification action to notify stakeholders use $event data incidentid and $event data priority in the notification playbook c (external system update) add a flow event trigger for incident escalated add http action to update external ticketing system use $event data incidentid in the api payload playbook d (follow up task) add a flow event trigger for incident escalated add create record action to create a follow up task use $event data incidentid and $event data reason in the task result when an incident is escalated, all three playbooks execute concurrently to handle notifications, external updates, and task creation example 3 conditional event processing scenario emit an event with order data, but only trigger downstream playbooks for high value orders configuration playbook a (order processing) add an emit event action after processing an order configure the emit event sensor name order processed event data orderid order identifier amount order total amount customerid customer identifier items array of order items playbook b (high value order handler) add a flow event trigger for order processed configure conditions $event data amount greater than 1000 add actions to handle high value orders send notification to sales manager create priority fulfillment task update crm system result only orders with amounts greater than $1000 trigger the high value order handling playbook best practices consistent naming use consistent naming conventions for flow event names to avoid mismatches consider using a naming pattern like domain action (e g , email processed , incident escalated ) event data schema design design event data schemas carefully to include all necessary information avoid including sensitive data unless necessary use conditions leverage conditions in flow event triggers to filter events and reduce unnecessary playbook executions document events add descriptions to flow events to document their purpose and expected data structure error handling consider error handling in triggered playbooks, as they execute asynchronously and may fail independently event versioning if you need to change an event schema, consider creating a new flow event with a new name rather than modifying existing ones, to avoid breaking existing playbooks testing test event flows thoroughly, especially when multiple playbooks are triggered by the same event monitoring monitor playbook run history to ensure events are being received and processed correctly troubleshooting playbook not triggering verify the flow event name (sensor name) matches exactly between emit event and flow event trigger check that the playbook is published and enabled verify conditions are not filtering out all events review playbook run history for errors event data not accessible verify property names match exactly (case sensitive) check that the event data schema includes the properties you're trying to access ensure the emit event action is sending data in the expected format multiple playbooks not executing verify all playbooks have the correct flow event name configured check that all playbooks are published and enabled review conditions in each trigger to ensure events aren't being filtered out event order issues remember that events are processed asynchronously with no order guarantee if order matters, use sequential processing or add sequence numbers to event data schema mismatch ensure the event data schema matches between emit event and flow event trigger when creating a new flow event, define the schema in the trigger first, then use the same schema in the emit event action