Skip to content

Integrations

Integrations connect Resorcerer to systems you already use — an HRIS, a directory service — so information doesn’t have to be typed in twice, or kept current by hand.

  1. Open your org switcher and choose Organization settings, then go to Integrations.
  2. Choose Add integration and pick the system you want to connect.
  3. Enter its connection details. Credentials are encrypted before they’re stored, and are never shown again once saved — not even to you.
  4. Test the connection before saving, so a typo in a URL or a stale credential is caught immediately rather than at the next scheduled sync.

Integrations are an add-on: the Add integration button and the connection form only appear on plans that include integrations. See Plans and limits.

Most HR and payroll platforms (Workday, BambooHR, HiBob, Personio, Rippling and others) connect as an HR system integration: you authorize access in a secure window rather than entering credentials, and People Sync then reads people and groups from it. See Connect an HR system.

SCIM works the other way around from every other integration: instead of Resorcerer pulling from an upstream system on a schedule, your identity provider (Okta, Microsoft Entra ID, and others) pushes people to Resorcerer as they’re created, updated, or removed there — provisioning happens the moment it happens upstream, not at the next scheduled sync. Because of that, a SCIM integration has no schedule, no Sync now, and no connection to test — there’s nothing for Resorcerer to dial out to.

  1. Add a SCIM integration the same way as any other, from Integrations → Add integration.
  2. From its detail page, generate a bearer token and copy it immediately — it’s shown once and can’t be retrieved again later.
  3. In your identity provider’s SCIM configuration, set the SCIM endpoint URL (shown on the same page) and paste in the token.
  4. Revoke a token at any time from the same page if it’s compromised or no longer needed — revoking works even if your plan no longer includes integrations.

Everything else — People Sync’s matching, managed fields, leaver handling, and your plan’s people allowance — works exactly the same for SCIM as for any other integration.

If your identity provider also pushes groups, Resorcerer creates and maintains matching groups automatically — no separate setup beyond the SCIM integration itself. A group your identity provider creates, renames, or deletes is reflected the moment it happens upstream, the same as a person.

Membership and nesting: adding someone as a member of a group adds them to that group in Resorcerer. A group added as a member of another group is nested underneath it — the same parent/child structure as a group you build by hand. If your identity provider’s nesting would ever create a loop (a group ending up nested under itself, directly or through a chain of parents), that specific change is refused rather than applied, so your group tree can never become circular.

Ownership: a group your identity provider manages becomes read-only on its name, description, parent, and active state, the same way a synced person’s managed fields are — see Managed fields below. Membership is never locked, though: you can always add or remove members by hand, even on a group your identity provider owns, since group membership is expected to be edited from either side.

Removal: a group removed upstream is deactivated in Resorcerer, not deleted — its history and any remaining references stay intact. If it reappears later, your identity provider reactivates the same group rather than a duplicate being created, the same way it does for a rehired person.

Once an integration is connected, turn on People Sync from its detail page to keep your people directory current from that system automatically.

How matching works: each person from the upstream system carries a stable identifier. The first sync creates anyone new; every sync after that updates the same person rather than creating a duplicate. If a person already exists in Resorcerer — say, from a CSV import — and their email matches, People Sync adopts that existing record instead of creating a second one.

What gets synced: name, email, title, department, company, location, manager, start/end dates, and whether the person is active. These are all plain fields; a person’s role, level, location and company attributes are not synced, but derived from those fields by your match expressions the moment the sync saves them. Which fields a particular integration actually manages depends on what the upstream system tracks — see Managed fields below.

Leavers: someone who disappears from the upstream system on a later sync is marked inactive in Resorcerer, with an end date set. They are never deleted — if they reappear in a later sync (a rehire), the same record is reactivated rather than a new one being created.

Your plan’s people allowance still applies: if a sync would add more people than your plan allows, the whole sync is refused, and nothing it would have changed is applied — the same all-or-nothing behavior as a CSV import that would go over.

Run history: every sync — scheduled or triggered by hand with Sync now — is recorded on the integration’s detail page: when it ran, how many people were created, updated, deactivated, or left unchanged, and any row-level problems it hit. Problems are summarized as a count of errors and warnings you can expand: an error is a row that could not be synced (for example, a person another integration already owns), while a warning is a row that was synced but with a reference left unset — most often a manager who is outside the synced groups or filtered out, so that person is synced without a manager. A sync that finds nothing to change still appears in the history, with everything at zero. (SCIM has no run history — see SCIM provisioning above.)

Schedule: People Sync runs once a day by default. You can set a different schedule, down to a minimum of once an hour. (SCIM has no schedule — provisioning happens as your identity provider pushes changes.)

A field People Sync manages becomes read-only on that person’s profile, with a note naming the integration that owns it — the upstream system is the source of truth for that field, so hand-edits are blocked rather than silently overwritten on the next sync. A field the integration doesn’t manage (because the upstream system doesn’t track it, or because you unticked it under Fields the sync manages on the integration’s People Sync card) stays editable by hand, and syncing never touches it.

This applies everywhere a person can be edited — the app, the REST API, the MCP tools an AI assistant uses, and CSV import (which reports the blocked field for that row and keeps going, rather than stopping the whole file). Deleting a person managed by an integration is blocked the same way — deactivate them in the source system instead, so the next sync reflects it correctly.

Attribute overrides are the exception: a synced person’s role, level, location and company attributes are yours to pin, because no integration manages them. See Match people to attributes.

Disconnecting an integration, or turning off People Sync with the explicit choice to release the people it managed, hands every field back to being editable by hand. Nobody is deleted by this — released people simply stop being managed, exactly as if they’d been added directly or by CSV import.

Moving to a plan without integrations doesn’t disconnect anything or delete synced people. It pauses scheduled People Sync runs (and adding a new integration) until you’re back on a plan that includes it — the same “everything stays, nothing new” behavior as going over any other limit. For SCIM, this also pauses new provisioning from your identity provider and stops you from generating a new token, but existing tokens aren’t deleted and you can still revoke one at any time. See Plans and limits.