Record Event Triggers

14 min

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