Plays can process records in batches—either in real-time when changes are detected, or on a predefined schedule. This page explains how to configure schedules, change detection modes, enrolment rules, and health monitoring.
The minimum sync interval depends on the model type—it may be as short as 5
minutes, 30 minutes, or up to 1 day. If you select an interval shorter than
the allowed minimum or the model was already refreshed during that period, the
sync will be skipped.
Schedule types
Configure when and how your play triggers:
| Type | Description |
|---|
| Manual | Enrol records manually via the Enroll manually button |
| Real-time | Trigger your play instantly when changes are detected |
| Interval | Schedule your play to run on a set interval (e.g., once per hour) |
| Cron | Schedule your play using a cron expression for precise timing |
| Dependency | Schedule after another play finishes running |
Real-time triggers are currently only available for HubSpot and
Salesforce integrations.
Conditions
Use Filters to control which records are eligible to trigger the play. Only records matching your filter conditions will be enrolled.
For real-time schedules, SQL, segment, occurrence, and related model conditions
are not supported. OR within groups and AND between multiple groups are also not
available.
Changes mode
The Changes section controls which types of data changes trigger the play. The available options depend on your schedule type.
For Real-time schedules
Real-time schedules receive records as they are created or updated in the source system. This means Cargo knows exactly what action occurred—whether a record was just created or updated.
| Mode | Behavior |
|---|
| Created records only | Only newly created records that match the conditions will be enrolled |
| Created and updated records | Both created and updated records that match the conditions will be enrolled |
In real-time mode, created means the record was literally just created in
the source system.
Beware of feedback loops with “Created and updated records”When a play is triggered in real-time on created and updated records, any
action in the play that writes data back to the source system (e.g.
updating a field in HubSpot or Salesforce) will itself generate an update
event. If the enrolment rule is set to Always enrol, that update will
re-trigger the play on the same record, creating a loop.For example, if 1,360 records are enrolled and a tool writes a score back to
each record, every write triggers a new update event, which re-enrolls the
record, which runs the tool again, and so on—potentially multiplying the
number of tool executions by orders of magnitude.How to prevent this:
- Switch the enrolment rule to Enrol once or If is not currently enrolled so each record is only processed once.
- If you need to use Always enrol, switch the changes mode to Created records only so updates are ignored.
- Alternatively, add a filter condition that excludes records that have already been processed (e.g. “Fit Score is unknown”).
For Interval, Cron, and Dependency schedules
Scheduled syncs work by comparing snapshots—Cargo fetches all matching records and compares them to the previous sync to detect changes. This is fundamentally different from real-time mode.
| Mode | Behavior |
|---|
| New records only | Only new records that match the conditions will be enrolled in the play |
| New and updated records | New and updated records that match the conditions will be enrolled in the play |
| Full | Process all matching records, regardless of whether they’ve changed |
| Custom | Advanced mode for custom change detection logic |
“New” vs “Created” an important distinctionIn scheduled mode, a new record is any record that appears in the sync that wasn’t there during the previous sync. This includes:
- Records that were just created in the source system
- Existing records that now match your filter conditions (when they didn’t before)
- Records that were restored or undeleted
In real-time mode, Cargo only knows when a record is created or updated—it cannot detect when an existing record starts matching your filter for the first time. Enrolment rules
Control how the play handles records that trigger multiple times:
| Rule | Behavior |
|---|
| Always enrol | Enrol the record into a new play run every time the trigger fires for that record |
| Enrol once | Only enrol each record once, even if the trigger fires multiple times for the same record |
| If is not currently enrolled | Only enrol a record if it’s not already in an active run, preventing concurrent runs |
When combining Always enrol with a Real-time schedule set to detect
created and updated records, every write-back from the play to the source
system will re-trigger the play. Use Enrol once or If is not currently
enrolled to avoid unintended re-processing. See the warning in the
Changes mode section for details. Health monitoring
Monitor the health of your play runs and set up alerts:
- Batch Health threshold — Set the percentage of runs that need to be successful for a batch to be considered healthy (0-100%)
- Health alert — Configure a Slack notification to be alerted when a batch falls below your health threshold
