> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Sync members from your directory or HRIS description: >- Ask the identity sync family what this release actually supports, review your joiner, mover and leaver mappings, and expect any mapping that would grant privileged authority implicitly to refuse. route: /docs/compute/access/scim-hris page_id: docs-compute-access-scim-hris page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Administrators automating Compute membership from an external directory voice: D reader_question: What can directory sync do for my Compute membership, and what will it refuse? primary_action: Review Compute scopes and roles source_locale: en-US source_status: APPROVED source_version: docs-compute-access-scim-hris-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Before you start You need administration authority, a connected directory or HR system, and agreement on which Compute grant each of your own roles should map to. Settle that mapping with the people who own those roles first. Sync automates a decision; it does not make one. ## Read the supported subset for this release Do not plan against a provisioning standard in general. Run `describe` on the identity sync family and read what this release supports. That description publishes the exact operations and attributes available to you. Treat anything not listed there as unsupported, however common it is elsewhere. Plan against the described subset, apply, then read the mapping back. The lifecycle is the same as every other resource: describe, plan, apply, pause, revoke, read back, events. ## Know which evidence you are acting on Every sync result names its evidence class, an `observed_at` time and a `valid_until` time. A live read from the connected directory is the strongest of these. A stored projection from the last sync is weaker but usually current enough. A record somebody typed by hand is the weakest, and it is the one most likely to be stale. A projection older than its `valid_until` is stale, not wrong. Read it again rather than acting on it, and never resolve a dispute about access from a cached copy. ## Review the three mappings separately Joiners, movers and leavers fail in different ways. Review each one on its own. For a joiner, decide the smallest grant a new record should receive. The default should be the least authority that lets somebody start, because a new person is the least reviewed person you have. For a mover, decide what a changed team or title does. A change that narrows can apply directly. A change that widens should be held for an approval, so a title edit somewhere else never becomes a grant here. For a leaver, decide what removal covers. Suspending grants is straightforward; service identities that person owned are not, because they belong to the account. Transfer or revoke each one as a separate act. See [how to transfer a service identity](/docs/compute/access/service-identities). ## Implicit privileged grants are refused A mapping that would grant administration, identity, destination or finance authority without an explicit approval is refused. It names the reason and the next action. That refusal is the design, not a limitation to work around. Privileged authority is granted deliberately, by a person, and read back. An external job title never implies a Compute grant. If somebody needs administration authority, grant it explicitly and record who approved it. ## Confirm success The mapping reads back as `VERIFIED`. Run one joiner, one mover and one leaver through it, and check the result each time. The joiner holds the smallest grant. The widening mover is held for approval rather than applied. The leaver's own grants are gone and their service identities are accounted for. If a mover widened silently, stop the sync before you fix anything else. ## Pause before you revoke Pausing holds the sync in place while you correct a mapping. Membership stays as it is, and nothing new is applied. Revoking ends the sync entirely, and members it created stay behind under manual management. Pause while you are fixing; revoke when you are done with it. Read the state back after either one, and check the events. A pause you did not confirm is a sync still running. [Review Compute scopes and roles](/docs/compute/access/scopes-and-roles)