Understanding workflow triggers
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
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.
These triggers are designed for single-use and do not automatically repeat.
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.
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.
Workflows can trigger based on different kinds of changes
-
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.
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.