---
title: Record Event Triggers
slug: record-event-triggers
docTags: 
createdAt: 2025-08-11T11:13:48.000Z
---

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:

1. In a playbook, from the Add panel, click and drag **Record Event** to the canvas.
2. 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.

::Image[]{src="https://app.archbee.com/api/optimize/511c8QBH-VHiwWnyzIwUb/XY7n8oMo41IfsrX_kdCkN_canvas-record-event-trigger.png" size="46" width="409" height="313" darkWidth="409" darkHeight="313" position="center" alt="Record Event Trigger" indent="2" showCaption="false"}

## Configuring the Record Event Trigger

### Step 1: Select Application

1. 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:

1. Click **CREATE YOUR FIRST CONDITION**.
2. Select the property type from the **Record Event Trigger** properties (e.g., `record.values.fieldName`).
3. Select the condition type from the dropdown (e.g., equals, contains, greater than).
4. Enter the value or select a property to compare against.
5. Add additional conditions as needed, using AND/OR logic to combine them.
6. Click **Apply** to save your conditions.

::Image[]{src="https://app.archbee.com/api/optimize/511c8QBH-VHiwWnyzIwUb/zpcZwgBGyVdtaZGgQf_LG_record-event-condition.png" size="58" width="1109" height="629" darkWidth="1109" darkHeight="629" position="center" alt="Record Event Condition" indent="2" showCaption="false"}

## 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`: Email
    **Note:** The user.userName field currently returns the user’s email address instead of the configured Username value. This is a known issue and is currently expected behavior.
  - `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:**

1. **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.
2. **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.
3. **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.
4. **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`
5. **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.
6. **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:**

1. **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.
2. **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"`.
3. **Step 3: Add a Condition Action**
   - Drag a **Condition** action into the flow.
   - Check if `$event.data.record.values.severity` equals `"Critical"`.
4. **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
5. **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:**

1. **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.
2. **Step 2: Configure Trigger Conditions**
   - Click **Configure** to add conditions.
   - Check that `record.values.status` **exists** and **does not equal** `"Resolved"`.
3. **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.
4. **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`
5. **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:**

1. **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.
2. **Step 2: Configure Trigger Conditions**
   - Click **Configure** to add conditions.
   - Check that `record.values.resolution-verified` **exists** and **equals** `true`.
3. **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"`
4. **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:**

1. **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.
2. **Step 2: Configure Trigger Conditions**
   - Click **Configure** to add conditions.
   - Check that `record.values.SLA-breached` **exists** and **equals** `true`.
3. **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`
4. **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`
5. **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.

## Reference Fields and Reciprocal References

Record event triggers listen to lifecycle events for the **application you select** on the trigger. That scope is fixed: the trigger does not automatically follow related records in other applications.

| User action                                                                                                                                                        | Typical effect on **Record Created** / **Record Updated**                                                                                                                                                                                                          |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| A user saves a change to a **reference field** (or any field) on a **record in the trigger application**                                                           | A matching event can fire when the save completes, subject to your selected events and conditions.                                                                                                                                                                 |
| A user changes a link **only** on the other application in a **reciprocal** relationship, and the platform updates the back-reference on this application’s record | That maintenance path can differ from a direct user save on the target record. A **Record Updated** run for **this** application may not occur, or the event may indicate a system action. Inspect $event.data.currentUser (including isSystemUser) when you test. |
| You need automation when **either** side of a two-app link changes                                                                                                 | Add or tune triggers on the application where the user (or API) **performs the save** you want to catch, and test in your environment. You may use triggers in more than one application.                                                                          |

:::hint{type="info"}
If a playbook with **Record Updated** does not start after a user only changes the link from the peer application, verify behavior by saving the reference field on the **same** application as the trigger, or work with your Swimlane contact to align automation with the events your tenant emits.
:::

## 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`