Record Event Triggers

record event triggers monitor changes to records in a specified application and automatically execute playbooks when those changes occur you can configure triggers to fire on record creation, record updates, or correlation search completion, with optional conditions to filter when the playbook should run key benefits real time automation respond immediately to record changes without polling or manual intervention flexible triggering choose to trigger on record creation, updates, or both conditional execution use conditions to filter when playbooks run based on field values access to record data full access to current and previous record values in your playbook correlation support trigger on correlation search completion for advanced use cases creating a record event trigger to create a record event trigger in a playbook, from the add panel, click and drag record event to the canvas hover over the plus icon to add it to the canvas the trigger panel displays to the right of the canvas, where you can configure your record event trigger configuring the record event trigger step 1 select application in the application dropdown menu, select the desired application the dropdown shows all available applications in your tenant you can filter applications by typing in the search box example select case and incident management (cim) application note the trigger will monitor all records in the selected application you can use conditions to filter which records trigger the playbook step 2 configure trigger events select which events should trigger the playbook record created check this box to trigger when a new record is created in the application record updated check this box to trigger when an existing record is updated in the application correlation action complete (optional) trigger when a correlation search completes (managed from correlation field settings) note you must select at least one event type (record created or record updated) for the trigger to be valid step 3 configure conditions (optional) click configure to open the condition builder, allowing you to create conditions that determine when the playbook should run click create your first condition select the property type from the record event trigger properties (e g , record values fieldname ) select the condition type from the dropdown (e g , equals, contains, greater than) enter the value or select a property to compare against add additional conditions as needed, using and/or logic to combine them click apply to save your conditions record event trigger outputs when a record event trigger fires, it provides the following event data that can be accessed in your playbook event data structure $event data application information about the application id application id uid application uid name application name $event data currentuser information about the user who triggered the event id user id username username issystemuser boolean indicating if the action was performed by the system $event data record current record data id record id (internal identifier) url url to view the record in the ui values object containing all field values (keyed by field key) $event data previous (only available for record updated events) previous record data values object containing previous field values before the update (keyed by field key) $event data correlatedrecord (only available for correlation events) correlated record data id correlated record id values object containing correlated record field values accessing record data in playbooks you can access record event data in your playbook actions using the $event data prefix examples note field values are accessed using field keys (not field ids or names) field keys are typically lowercase with hyphens (e g , priority level , assigned to ) event metadata event type record event action create or update (depending on the trigger event) event fqn turbine record create or turbine record update event source turbine use case examples for record event triggers with native actions example 1 auto assign incidents based on priority scenario automatically assign high priority incidents to a senior analyst and low priority incidents to a junior analyst configuration step 1 add a record event trigger drag and drop a record event trigger onto the playbook canvas select the case and incident management (cim) application check record created and record updated to trigger on both events step 2 configure trigger conditions click configure to add conditions first condition check that record values priority exists (is defined) second condition check that record values priority equals "high" use and logic to combine conditions step 3 add a condition action drag a condition action into the flow check if $event data record values priority equals "high" if true, proceed with high priority path; otherwise, follow low priority path step 4 create variables drag a create variables action into the flow create variables incident id $event data record id priority level $event data record values priority step 5 add update record action for high priority path use update/create record action to assign to senior analyst for low priority path use update/create record action to assign to junior analyst step 6 add http action for notifications drag an http action into the high priority workflow configure post request to external system (e g , jira or servicenow) payload {"incident id" "{{$variables incident id}}", "priority level" "high"} result high priority incidents are automatically assigned to senior analysts, while low priority incidents are assigned to junior analysts notifications are sent to external systems example 2 notify on critical incidents based on severity scenario send an immediate notification to the security team when a new incident is marked with a critical severity configuration step 1 add a record event trigger drag and drop a record event trigger onto the playbook canvas select the security incident response application check record created to trigger only on new incidents step 2 configure trigger conditions click configure to add conditions first condition check that record values severity exists second condition check that record values severity equals "critical" step 3 add a condition action drag a condition action into the flow check if $event data record values severity equals "critical" step 4 create variables drag a create variables action into the flow create variables incident id $event data record id severity $event data record values severity timestamp use expression to get current timestamp step 5 add send notification action drag a send notification action into the flow configure to send notification to security team group title "critical incident {{$variables incident id}}" body "a critical severity incident has been created severity {{$variables severity}}" result the security team receives an immediate notification when a new critical incident is created, allowing them to respond swiftly example 3 automate record escalation based on time scenario automatically escalate an incident if it remains unresolved for more than 24 hours configuration step 1 add a record event trigger drag and drop a record event trigger onto the playbook canvas select the incident management application check record updated to trigger on record updates step 2 configure trigger conditions click configure to add conditions check that record values status exists and does not equal "resolved" step 3 add a condition action drag a condition action into the flow check if $event data record values time unresolved is greater than 24 hours use expression to calculate time difference from creation time step 4 add update/create record action drag an update/create record action into the flow configure to update the record status to escalated use key field to identify the record $event data record values tracking id step 5 add http action for external systems drag an http action into the flow configure post request to external system (e g , jira or servicenow) payload {"incident id" "{{$event data record id}}", "status" "escalated"} result incidents unresolved for more than 24 hours are automatically escalated, with updates sent to external systems example 4 close incident based on resolution verification scenario automatically close an incident if the resolution has been verified configuration step 1 add a record event trigger drag and drop a record event trigger onto the playbook canvas select the incident management application check record updated to trigger on record updates step 2 configure trigger conditions click configure to add conditions check that record values resolution verified exists and equals true step 3 add update/create record action drag an update/create record action into the flow configure to update the record status to closed use key field $event data record values tracking id patch value status = "closed" step 4 add http action for external system drag an http action into the flow configure post request to update external system payload {"incident id" "{{$event data record id}}", "status" "closed"} result once resolution is verified, the incident is automatically closed, and external systems are updated example 5 flag incident for review based on sla breach scenario flag incidents for review when the service level agreement (sla) is breached configuration step 1 add a record event trigger drag and drop a record event trigger onto the playbook canvas select the incident management application check record updated to trigger on record updates step 2 configure trigger conditions click configure to add conditions check that record values sla breached exists and equals true step 3 create variables drag a create variables action into the flow create variables reviewer id $event data record values assigned to time of breach current timestamp or $event data record values breach time step 4 add update/create record action drag an update/create record action into the flow configure to update the record flag field to indicate review needed patch value review flag = true step 5 add send notification action drag a send notification action into the flow configure to notify the review team title "sla breach {{$event data record values tracking id}}" body "an sla breach has been detected reviewer {{$variables reviewer id}}, time {{$variables time of breach}}" result when an sla is breached, incidents are automatically flagged for review, and the review team is notified for immediate action best practices use "is defined" checks always check that fields exist before checking their values to avoid unexpected behavior with empty fields choose appropriate trigger events use record created for initial processing (e g , assignment, initial notifications) use record updated for change based logic (e g , escalation, status changes) use both when you need to handle both scenarios use conditions wisely configure trigger conditions to filter records at the trigger level, reducing unnecessary playbook executions access field values correctly use field keys (not ids or names) to access field values $event data record values fieldkey handle previous values for update events, use $event data previous values to compare old and new values and detect specific changes avoid infinite loops be careful when updating records in playbooks triggered by record events, as this can create infinite loops use conditions or flags to prevent re triggering test with sample records test your trigger conditions with sample records to ensure they work as expected before deploying to production monitor playbook executions regularly review playbook run history to ensure triggers are firing correctly and not too frequently troubleshooting playbook not triggering verify the playbook is published and enabled check that at least one event type (record created or record updated) is selected verify the application is correct check trigger conditions ensure they match the record data structure review playbook run history for any errors unexpected multiple executions check for empty fields in conditions add "is defined" checks verify conditions are correctly configured (and/or logic) check if the playbook is updating records that trigger the same event (infinite loop) field values not accessible verify you're using field keys (not field ids or names) check that fields exist in the application ensure field keys match exactly (case sensitive) use $event data record values fieldkey format previous values not available previous values are only available for record updated events ensure record updated is checked in trigger configuration use $event data previous values fieldkey to access previous values conditions not working verify condition syntax is correct check that field keys match application field definitions ensure condition operators are appropriate for field types test conditions with sample record data infinite loop issues if your playbook updates records, ensure it doesn't trigger itself use conditions to prevent re triggering (e g , check if a flag field is already set) consider using a different trigger type or action to update records correlation events correlation events are managed from correlation field settings correlation search complete events are automatically configured when correlation fields are set up access correlated record data using $event data correlatedrecord