Record modified trigger

Reference for the record modified trigger: start an automation when a record is created, updated, or deleted.

Overview

The Record Modified trigger fires whenever a record of a specified object type is created, updated, or deleted. It is the starting point for any automation that responds to data changes in Skedulo.

You choose which object type to watch, which operations to respond to, and optionally add an EQL filter to narrow down which records should trigger the workflow.

Configuration

Object type

Select the standard or custom object to monitor, for example, Jobs, Contacts, or Accounts.

Operations

Choose which operations should start the workflow. You can enable one or more:

Operation When it fires
Insert A new record of this object type was created
Update An existing record was modified
Delete An existing record was deleted

Run when (optional)

The Run when section lets you filter which records of the selected object type actually trigger the workflow, using an EQL (Elastic Query Language) expression. The automation only runs when the filter evaluates to true for the record that changed. Use it to avoid running a workflow for every record change when you only care about a subset.

Run when has two modes, toggled with the Simple / Advanced buttons:

  • Simple: a structured, no-code builder: pick a field, operator, and value from dropdowns. This is the default mode.
  • Advanced: write the EQL expression directly as text.

Switching from Advanced to Simple isn’t always possible: if the current expression is more complex than the Simple builder can represent, switching is blocked and a warning offers to Clear and switch, which discards the current expression.

Example: only run for contacts that have a parent account:

Current.AccountId != null

Example: only run for jobs of type Break Fix:

Current.Type == 'Break Fix'

Trigger output

When the record modified trigger fires, it injects a set of output values into the workflow that are available to all subsequent steps. All trigger output is accessed via the $trigger namespace.

Variable Type Description
$trigger.objectType string The API name of the object type that changed, for example, Jobs or Contacts
$trigger.operation string The operation that caused the trigger to fire: Insert, Update, or Delete
$trigger.userId string The ID of the user whose action caused the event
$trigger.current object The record’s field values. On insert and update, this is the state after the change; on delete, this is the record’s final state before it was removed. Available on insert, update, and delete.
$trigger.previous object The state of the record before the change. Available on update only; null on insert and delete. See note below.
$trigger.metadata object Arbitrary metadata attached to the event. The structure varies by event source.

$trigger.current and $trigger.previous

$trigger.current and $trigger.previous expose the record’s field values as named properties. Access individual fields using dot notation. Below is an example of accessing fields from a Contacts record:

$trigger.current.FirstName
$trigger.current.AccountId
$trigger.current.MailingStreet

The fields available depend on the object type selected for the trigger. Use the variable picker (click the $ icon next to any field in the builder) to browse all available fields.

The availability of $trigger.current and $trigger.previous depends on the operation:

Operation $trigger.current $trigger.previous
Insert ✅ Record state after creation null: no prior state exists
Update ✅ Record state after the update ✅ Record state before the update
Delete ✅ Record state before deletion null: record no longer exists

$trigger.operation values

Value Description
Insert A new record was created
Update An existing record was modified
Delete A record was deleted

You can use $trigger.operation in a Choice condition to branch the workflow differently depending on what kind of change occurred, for example, to handle inserts and updates with different logic in the same automation.

Example: branch on insert vs. update:

$trigger.operation = 'Insert'

$trigger.metadata

The metadata object contains supplementary information about the event. The exact structure depends on the source of the change, and not all events populate every field. Inspect it using the variable picker or an Echo step to see what is available for your specific use case.

Expression examples

The following table shows common patterns for referencing trigger output in JSONata expressions.

Goal Expression
Get a field from the triggering record $trigger.current.FieldName
Get the full name of a Contact $trigger.current.FirstName & ' ' & $trigger.current.LastName
Check whether the record has a parent account $trigger.current.AccountId != null
Check whether a specific field changed $trigger.previous.Status != $trigger.current.Status
Show what a field changed from and to $trigger.previous.Status & ' → ' & $trigger.current.Status
Use a field value with a fallback when null $trigger.current.Description != null ? $trigger.current.Description : 'No description provided'
Check the operation type $trigger.operation = 'Insert'
Get the ID of the user who made the change $trigger.userId
Get the object type that triggered the event $trigger.objectType

See also