Identity provisioning for 1,000+ users across 600+ groups
Delivered by 1AYM
A PE-backed marketing agency
When somebody leaves, their access to Notion and Claude ends with their HR record rather than when a colleague remembers. We built the provisioning system that does it from scratch, because the client's IT team was over capacity and off-the-shelf group tooling did not fit a model where one person belongs to many groups: it covers more than 1,000 users across over 600 groups and has run for seven months. A membership matrix that size was never going to be kept right by hand.
The problem
Two tools needed access managed across the whole organisation, against a membership model where one person belongs to many groups and group membership changes as people join, move and leave.
Done manually, a matrix of that size is not merely tedious. It is unreliable in a specific and dangerous way. Manual provisioning fails safe on joiners, because someone complains when access is missing. It fails unsafe on leavers, because nobody complains about access that should have been removed. That asymmetry is how organisations accumulate active accounts belonging to people who left months ago.
Why it was built rather than configured
The internal IT team was over capacity and did not have the time to take it on, which is the ordinary reason this kind of work does not get done anywhere.
Off-the-shelf group tooling was considered and rejected. The organisation's membership model (overlapping groups, HR as the source of truth, two target systems with different provisioning semantics) did not fit the shape those tools assume, and bending the model to fit the tool would have left the mismatch to be handled manually anyway.
How it works
- HR as the source of truth
- Provisioning is driven from the HR system, so joining, moving and leaving are reflected without a separate administrative step that someone has to remember.
- Deterministic identity resolution
- Matching a person across systems is done by explicit rules rather than fuzzy heuristics, because a wrong match grants the wrong person access.
- Diff-based writes
- Each run computes the difference between intended and actual state and applies only that, so a run is idempotent and a retry cannot compound.
- Dry-run mode
- Changes can be inspected before they land, which is necessary when a single run can alter access for hundreds of people.
- Audit trail and rollback
- What changed, for whom, and why, with a defined path back from a bad run.
Outcome
The system has run for seven months. Access reflects the HR system rather than someone's memory, joiners are provisioned without a ticket, and leavers lose access because a record changed rather than because somebody noticed.
This was built inside the wider enablement engagement at the same organisation, and shares its engineering defaults: idempotency, dry runs, auditability and rollback are the baseline rather than additions.
SCIM · Notion · Claude · HR system integration · Deterministic identity resolution
Related
Written at a public-safe level: client names, internal project names and proprietary business logic are held back by agreement.
Last reviewed