Understanding workflow triggers


Introduction

Introduction

Workflow triggers serve to enrol records from a data model into the execution of a workflow to create runs.

They can be broadly classified into two categories:

  • One-off triggers: which are manually initiated runs.
  • Rules-based triggers: which automatically initiate workflow runs once a workflow release is enabled

One-off

Testing runs

For testing purposes, Cargo offers options for individual node execution and batch execution.

During the draft testing stage, you can trigger each node separately using data from the start node.

During the release testing phase, the Import button in the Runs view enables the execution of the entire workflow for a selected batch of records.

Cover image

These triggers are designed for single-use and do not automatically repeat.


Rules-based

3rd party data triggers

Webhook-triggered workflows allow for real-time workflow execution in response to receipt of payloads sent via webhooks.

Whenever a data model is setup on a webhook data source, it offers a webhook URL capable of receiving JSON payloads. These payloads will be inserted into the data model that can then trigger a workflow run, where one is set up to do so. Note, that there can be a delay of ~1 mins for this enrolment to complete.

Cover image
Rules-based

1st party data triggers

Automatic enrolments correspond to saved filters on a Cargo model that monitor for record changes that fit the filter criteria — be it additions, deletions, updates, or lack of changes.

Data changes in records belonging to a segment can trigger enrollment of said records into workflow execution.


Rules-based

Workflows can trigger based on different kinds of changes

Cover image
  • New record additions: This triggers the workflow when new records are added. It's key for situations where new information needs immediate action, like adding new customers, for example.

  • Record deletions: Workflows can start when records are removed. This is useful for cleaning up related data or triggering follow-up actions.

  • Record updates: Workflows can also trigger when specific details in a record are changed. This allows systems to adjust dynamically to new information, making sure everything stays up-to-date and actions are based on the latest data.


Rules-based

Handling repeated runs

When dealing with records being enrolled repeatedly, workflows can be set to:

  • Always enroll: This method means the workflow will start every time it notices a change, no matter if the record has been through the workflow before. It's useful when you need to act on every single change, like in situations where responding quickly to data updates is important.

  • If is not currently enrolled: This way, a record will only start the workflow if it's not currently being processed. It helps avoid duplication caused by high velocity enrollments.

  • Enrol once: Choosing this option means once a record has gone through the workflow, it won't trigger the workflow again, even if there are new changes to it. This is best for when you only need to process each record once and need to absolutely avoid acting on further changes.