Scheduled Syncs and Full Resyncs

This page covers how scheduled polling works — the cadence, how incremental syncs know what to fetch, and how the optional daily full resync works.

For integrations that use webhooks rather than polling (Visit is the main example), most of this page doesn't apply — those integrations run whenever the source system tells them a record has changed.

The five-minute cadence

The scheduler fires every five minutes and checks each active subscription. If a subscription is due for a new sync, one is queued. If a sync for that subscription is still in progress, the scheduler skips it for that cycle and rechecks five minutes later. Two syncs for the same subscription never run at the same time.

This means: from the moment something changes in the source system to the moment it appears in ExpoPlatform, expect up to five minutes' delay (plus the time the sync itself takes to run).

Some integrations may be provisioned to run on a shorter interval — for example, Visit subscriptions run at one minute. That's set when the subscription is created and isn't something you configure yourself; the default of five minutes applies unless it's been provisioned otherwise.

Full sync vs incremental sync

Every subscription starts with a first full sync — fetching every record in scope from the source system. This runs once, on the first scheduled tick after the subscription is created.

Every scheduled sync after the first is incremental — it fetches only what has changed since the last successful run. Incremental syncs are much faster because the source system does the filtering. The exact filter varies by integration (see each integration's page), but the pattern is the same everywhere: ask the source for records that changed after a stored marker.

You can also trigger a manual full resync at any time — see Triggering a Sync. A manual full resync ignores the marker and fetches every record in scope again.

How incremental syncs know what to fetch

Each integration tracks a marker between runs. When the next scheduled sync runs, it asks the source system for everything that has changed since that marker. The marker is updated when the run finishes successfully.

The specifics vary by integration:

Most integrations use a timestamp marker — the start time of the previous run. The next run asks the source for records modified since that time.
Some integrations use an ID marker (Aditus Visitors uses a registration ID). The next run asks for records with a higher ID.
Visit is a special case — it's driven by webhooks and tracks a revision number per record, but the same principle applies.

A failed run leaves the marker untouched. The next run re-covers everything since the last successful sync, so nothing is lost.

Consecutive runs overlap slightly. Because the marker is the start time of the previous run, the next run's window overlaps with the tail of the previous one. Records that appear in both windows are skipped as unchanged (the sync detects nothing has actually changed for them), so this doesn't cause duplicate work — it just makes sure nothing falls between runs.

Pausing and resuming a subscription

Each subscription can be paused individually from the integration's management page in the admin UI.

When you pause, the scheduler stops picking up the subscription. No new syncs are queued.
A sync already in progress will complete normally — the pause only affects future scheduled ticks.
When you resume, the next scheduler tick (within five minutes) will pick the subscription up again.

Pausing for an extended period during an active event means data drift — the event in ExpoPlatform will fall out of step with the source system. Consider that before leaving a subscription paused for more than a few hours during registration windows.

Daily full resync

Each subscription can optionally run a daily full resync at a specific UTC time, in addition to the regular five-minute incremental schedule. When the configured time is reached, the next scheduler tick queues a full sync — paging through the entire dataset and re-applying field mapping to every record — instead of the usual incremental run.

This is useful for integrations whose incremental signal isn't fully reliable. The clearest case is Genesis, which filters incremental fetches by an update timestamp; in practice Genesis doesn't always update that timestamp when a record changes, so a regular incremental sync can miss edits. A daily full resync gives a guaranteed catch-up window each day.

The same applies to Aditus Visitors, which only pulls new registrations on scheduled syncs and otherwise never re-reads existing records. If you want existing records to be re-synced on any regular cadence, the daily full resync is how you do it.

How to configure it

In the admin UI:

Open the Auto Sync tab on the integration page and expand the relevant subscription card.
Click Enable… next to Daily Full Resync.
Pick a UTC time in five-minute increments.
Save.

To disable, clear the value on the same form.

Scheduling rules

The scheduler fires once the configured time is reached, on the same five-minute tick that handles incremental syncs.
If a sync is already in progress when the time arrives, the daily full resync is held until the subscription returns to idle, then queued on the next tick.
If the configured time is missed (system unavailable, scheduler delayed), the daily full resync fires on the next available tick within the same UTC day. Missed days are not replayed retroactively.
Each subscription only fires one daily full resync per UTC day, regardless of how many ticks pass through the configured window.

⚠️ A daily full resync re-runs the update field mapping for every existing record. Every field included in the update mapping will be overwritten with its current upstream value on every daily run. Verify the update mapping carefully before enabling — particularly for Aditus Visitors, where the update mapping is otherwise rarely exercised. See How Sync Works → What happens when a record is re-imported.