Integration sync
Pulls employees, employments, and organization units from each enabled integration (Entra ID, SHR, Visma OM, Intega HR, …).
How it works
The integration sync is a single job that handles every sync-capable integration:
- Loads enabled integrations — only integrations turned on for the workspace are processed; disabled or unconfigured ones are silently skipped
- Fetches data — calls the integration provider with the last successful sync timestamp so providers that support delta sync only return what changed
- Reconciles — creates new entities, updates changed ones, and reports anything it skipped (e.g. malformed source rows)
- Updates the sync status — records the start time of this run as
last_sync_aton success, or the error message on failure. Stamping start time (not completion time) means upstream changes made during the fetch are picked up on the next run
When it runs
The job runs automatically and only triggers when at least one sync-capable integration is enabled for the workspace.
Parameters
| Parameter | Description |
|---|---|
| Integration | Optional. The ID of a specific integration (e.g. entraid, shr, vom, integahr). Leave empty to sync all enabled integrations |
| Dry Run | When enabled, fetches data and reports counts without writing anything to the database. Useful for verifying credentials or seeing what an integration would do |
Job results
When syncing a single integration, the results are flat:
| Metric | Description |
|---|---|
employees (with created, updated, skipped) | Per-bucket counts for employees |
employments (with created, updated, skipped) | Per-bucket counts for employments |
org_units (with created, updated) | Per-bucket counts for org units |
errors | Provider-reported errors during fetch or reconciliation |
When syncing all integrations, the results are nested under each integration ID.
Dry-run results expose the number of items fetched (employees, employments, org_units) and a dry_run: true flag.
When a run skips because the integration is disabled or not configured, you’ll see skipped: true with a reason.
Job status
A run that completes with skipped rows or per-item errors finishes with status warning rather than completed. The data that did sync is committed; the warnings draw attention to the rest.
Related
- Integrations overview — set up and configure each integration
- Integration status — view the latest sync timestamp and error for each integration
Troubleshooting
| Issue | Solution |
|---|---|
not configured skip | The integration was never set up for this workspace. Configure it under |
disabled skip | The integration is configured but the toggle is off. Enable it on the integration page |
| Credentials error | Re-check the credentials stored on the integration page. The job re-reads them on every run |
| Same employees re-created on every run | The matching key is per-integration. Check the integration’s documentation for the field it uses to match (e.g. employee number, email) |
| Dry run shows the expected data, real run does nothing | An integration can signal skip mid-run (e.g. when employee sync is toggled off in advanced settings). The run completes successfully but no data is committed; last_sync_at is intentionally not advanced |