Imports & schedules
How data is imported from connected systems, the shared sync-schedule model with its 15-minute cadence floor, and how imports feed the Expected-vs-Actual model.
Imports are how the platform learns the current state of a connected system — who has accounts, which entitlements exist, and who holds them. Each system runs on its own independent schedule, and the same schedule primitive that drives imports also drives scheduled workflows. This page explains the import model, the schedule model, and how imported data becomes the Actual side of the reconciliation comparison.
What an import is
An import is a read from a connected system. It pulls the system's current objects — accounts, entitlements, and the assignments between them — into the platform so they can be governed. Imports are strictly read-only run types: syncing, health-checking, probing, and discovery. Writing back to a system (creating accounts, granting access) is a separate concern — a provisioning operation, tracked as a provisioning job — and is never part of an import.
The distinction matters: imports tell the platform what the system actually looks like right now. Governance decides what it should look like. Reconciliation compares the two.
💡 Tip
Business data — identities, accounts, entitlements, and assignments — must arrive through imports from live systems, never be seeded directly. Human-resources data flows in as identities; target systems flow in as accounts, entitlements, and assignments. Only configuration (connectors, account-type blueprints, policies, rules) is set up directly.
The sync-schedule model
Every connected system carries its own sync schedule, evaluated independently against that system's own last-run time. One system's cadence is never altered by another's. A schedule has a kind:
| Kind | Meaning |
|---|---|
interval |
Run every N minutes |
daily |
Run once a day at a set time |
weekly |
Run on chosen days of the week at a set time |
monthly |
Run on chosen days of the month (or an "nth weekday", e.g. the second Tuesday) at a set time |
manual |
Never run automatically — imports only when triggered by hand |
Each schedule carries its own timezone, and richer schedules can add a validity window (a start and end date), an intraday time window for interval schedules ("only within work hours"), and a "repeat every N" multiplier for cadences like biweekly or quarterly.
The 15-minute cadence floor
A sync interval may not be faster than 15 minutes. A value of 0 means manual-only and is always allowed; anything from 1 to 14 minutes is rejected. The reason is performance, not cost: the scheduler tick is about a minute and syncs within a tick run one after another, so a sub-15-minute cadence adds sweep load that slows other systems without any meaningful gain in freshness.
The floor is enforced centrally in the schedule parser, so it applies uniformly to every consumer of the schedule primitive. The configuration surface reflects this — presets start at hourly, and the custom input is clamped at 15 with a soft advisory in the 15-to-59-minute range: allowed, but not recommended.
The shared schedule primitive
The schedule model is a single shared primitive, not a per-feature reimplementation. Two real consumers use the identical schedule shape and the identical parser:
- Connector sync — a system's
sync_schedule, driving when it imports. - Scheduled workflows — a workflow's trigger schedule, driving when a
trigger_type=scheduledworkflow fires.
Because both go through the same parser, the 15-minute floor, the timezone handling, and every schedule kind behave the same everywhere. A multi-type timeline can therefore project the next fire times of both connectors and scheduled workflows onto one view — so "what runs when, across both imports and workflows" is a fact on screen rather than something inferred from a list of one-line summaries.
Event-triggered workflows are a separate mechanism (they react to an event, not a clock) and are outside the schedule primitive.
Ordering and dependencies between systems
Schedules are independent, but imports can declare a data dependency on another system — for example, an Entra sync that needs Active Directory to resolve samAccountName first. When two systems with a declared dependency both come due in the same scheduler tick, the platform orders them so the upstream system imports before the downstream one. A dependency only has teeth when both ends are due at once; it never changes either system's own cadence. Each system's import also runs in isolation — one broken system's failure is caught and logged, and the others continue.
How imports feed the Expected-vs-Actual model
An import produces the Actual state: exactly what exists in the connected system as of that run. The governance model produces the Expected state: what should exist, according to access grant policy matches, approved access requests, role-based assignments, and explicit keeps.
Reconciliation compares the two, per identity, per system:
- Actual comes from the most recent import.
- Expected comes from the governance model.
- Any difference is drift — an attribute changed by hand, an assignment that exists in the system but is not expected, or an account the model expects that is missing.
So imports are strictly upstream of reconciliation. They are not a competing view of access — they are the sensor that tells reconciliation what is really out there. A stale or failed import means reconciliation is comparing against old Actual data, which is why import health and schedules are worth watching. Throughout the product this comparison is labelled Expected / Actual.