Use case: Joiner, mover, leaver (JML) automation

A leaver whose access outlasts their last day by even a week is one of the most common ways former employees retain access they shouldn’t — and one of the first things an incident responder or auditor checks. Joiner, mover, leaver (JML) automation turns the three events that change someone’s relationship to your company — hired, changed roles, left — into the account and access changes that should follow automatically, without an IT ticket for each one. This page walks through how C1 handles each event and links out to setup details. It’s a closer look at the onboarding and offboarding flows introduced in the identity governance use case.

​

Start with your HR system

Every JML event starts with a change in your directory — your HRIS or identity provider, whichever you’ve designated as the source of truth. When that source reflects a hire, a role change, or a termination, C1 picks it up on the next directory sync and makes the change available to trigger automations and access profile enrollment. Automation triggers give you the building blocks: User Created fires when a new person is synced in; User Updated fires on any attribute change and lets you compare oldUser and newUser to detect a specific transition — a department change, an employment status flip from active to terminated, and so on. You’re not limited to waiting for the next scheduled sync, either. If your HRIS can call out over HTTP, an inbound webhook lets it trigger the automation directly — authenticated with HMAC or JWT — the moment a record changes, instead of on a polling interval.

​

Joiner: provision before day one

When a new hire is created in your directory, C1 can grant their baseline access automatically:

• Access profiles handle the broad strokes. Access profiles scoped by department, role, or location are what’s commonly known as birthright access — a curated bundle of apps and entitlements a person gets because of who they are, not because they asked. Membership automation enrolls a new hire in the right profiles as soon as they match the profile’s condition, with enrollment approval and provisioning able to run on auto-approve for low-risk access.
• Custom automations handle anything more specific — creating a department-specific account, notifying a team, sending a welcome email. See the employee onboarding example, triggered on User Created.

​

Mover: recalculate access on a role change

When someone’s department, title, manager, or location changes, their access should change with it — old-role access removed, new-role baseline granted. Two mechanisms handle this, and you can use either or both:

• Membership automation reacts on its own. Because access profile enrollment is condition-based, a role change that makes a user stop matching one profile and start matching another triggers unenrollment from the first and enrollment in the second automatically — no separate “mover” logic required, it’s the same joiner/leaver mechanism evaluated continuously.
• Build it explicitly with an automation when you need more control than profile enrollment gives you — for example, notifying the new manager, handling entitlements that aren’t managed through a profile, or reconciling access in a tool C1 doesn’t directly manage via a Function. See the Role transfer (department change) pattern in automation examples: a User Updated trigger that detects a department change and revokes the old department’s entitlements while granting the new baseline — the example has the exact trigger condition.

​

Leaver: offboard across every connected system

When employment status changes to terminated or disabled, membership automation unenrolls the user from their access profiles and, based on how each profile is configured, revokes some, all, or only the “unjustified” entitlements those profiles granted. For full control over the offboarding sequence — revoking everything except compliance-required access, disabling the user’s C1 status, kicking off a review for what’s left, notifying security — see the employee offboarding example, triggered on User Updated when status transitions from enabled to disabled.

​

Build the audit trail

Every automation run, enrollment, and revocation is logged. Task-level history (who was granted or revoked what, when, and by which policy) is visible on each task’s audit log, and the underlying events are available as system logs in OCSF format for export to a SIEM. If a JML automation kicks off an access review campaign — like the offboarding example’s remaining-access check — that campaign produces its own attributable, hash-verifiable report.

​

Related resources