Introduction to triggered actions

Perform actions in response to Skedulo event triggers.

Triggered actions are Skedulo’s newer iteration of webhooks. A trigger defines what Skedulo event causes an action to be performed in response.

Triggered actions can be inserted, updated, and deleted, and are defined via the /triggered_actions endpoints.

Triggers

Triggered actions can be configured to fire whenever an object is modified and perform an action in response. For example, a trigger can fire whenever a job status changes and perform an action by sending an SMS notification.

  • object_modified: These triggers fire when an object that can be tracked for changes is inserted, updated or deleted.

Tracking is automatically enabled on most standard objects, and all custom objects created after 10 May 2024. Objects created prior to this date will need to have tracking manually enabled. Additionally, Skedulo for Salesforce teams require additional configuration within Salesforce.

Enable tracking on a custom object

To manually enable tracking on an object, do the following steps.

  1. Find the objectId of the custom object by making the following request: curl --location --request POST “https://api.skedulo.com/custom/schemas” --header "Authorization: Bearer <token>"

  2. Pass the objectId to this endpoint: curl --location --request POST "https://api.skedulo.com/custom/standalone/schema/{objectId}/track" --header "Authorization: Bearer <token>"

Trigger composition

To configure the trigger, you must provide the following information:

  • The trigger type.
  • The target schema/object name.
  • An EQL filter. The filter specifies when the action should be performed and can refer to the operation name and the current and previous data objects.

A validation check runs whenever a triggered action is inserted or updated. This ensures that the trigger and action are valid and that the trigger can provide the data required by the action.

Actions

Actions fire in response to a trigger event. Only certain actions are valid for a trigger – a call_url action, or a send_sms action.

  • call_url: This action performs a POST HTTP request to a provided URL, with a configured list of header names and values that are added to the request. The body of the request is a JSON array including at least one object determined via a GraphQL fragment. The GraphQL fragment is validated against the data provided by the trigger.

    The JSON array allows for combining multiple events into a single action. See the section about retries for more information about call_url actions, including when they are retried and their timeout period.

    The call_url action may contain Configuration Variable templates within these fields:

    • action.url
    • action.headers

    See our triggered action guide for an example.

  • send_sms: Sends an SMS message to a phone number provided in the configuration. The phone number to use can be defined statically or as an EQL field name. The message template is defined in {{mustache}} format and may include EQL field names that can be extracted from the data provided by the trigger. The EQL field expression can use dot notation to refer to a field of a lookup reference. For example, for a trigger on the Jobs object, the phone number can be Contact.MobilePhone.

Use EQL filters in triggered actions

Triggered actions require an EQL filter in order to determine whether a given change event causes the action to be performed. Triggered Action EQL filters may refer to the Operation that caused the change (INSERT, UPDATE OR DELETE) and must refer to fields via the Current or Previous parent object. For example, Operation == 'INSERT' AND Current.JobStatus != Previous.JobStatus.

For more information about using EQL filters, see the EQL filter section.