Lifecycle States and Joiner Mover Leaver Automation

On this page

• The lifecycle model
• The automation layer: events, schedules and forms
• Joiner
• Leaver
• Mover
• Rehire
• Notifications and ITSM routing
• Nightly validation during rollout
• Design cautions
• Actions

Joiner, mover and leaver (JML) is the visible face of the program. This page describes how the automation was built from lifecycle states, event-triggered workflows, manager forms and scheduled jobs, and the places where it needed human help.

The lifecycle model

The HR-driven identity profile had five lifecycle states, all driven by the computed cloudLifecycleState attribute described on the identity model page.

The lifecycle action source list is explicit

This is the most expensive caveat in this section. Each lifecycle state action names its target sources by ID. At the end of the program the Inactive disable action covered 13 of 146 sources: the directories and the earliest crown-jewel applications. Sources added later were not on the list, including some with no other disable path.

That is not necessarily wrong. Several later applications were handled by compensating mechanisms, for example a scheduled workflow that disables accounts in a payroll SaaS on a half-month calendar, or a manual leaver process. But it has to be a decision, not an accident.

Make this a standing checklist item for every new source:

1. Is the source account-managed by ISC (it can disable accounts)?
2. If yes, is it on the Inactive and Emergency Termination action lists?
3. If no, what disables or reviews access for a leaver, and who owns it?

There is also an organisation setting that controls whether a lifecycle change honours a source's own "can enable" feature flag. It was off. Know its value before you assume lifecycle actions are skipped for sources that cannot enable accounts.

The automation layer: events, schedules and forms

All JML behaviour sat in workflows reacting to platform events. The trigger types used:

Filters use JSONPath over the event payload. A leaver trigger watches for cloudLifecycleState changing to inactive; a rehire trigger watches the same attribute going from inactive to active or preJoiner. These filters are exact, so keep the attribute names and values stable.

Joiner

1. HR creates the person. The design asked for at least 14 calendar days between request and start date.
2. The HR source aggregates hourly. ISC creates the identity, computes lifecycle state, login name and email, and moves the lifecycle to preJoiner once the start date is within the processing window.
3. The lifecycle action enables the directory account. Creation happens in the user's local time zone, 14 days before start.
4. Directory provisioning sets the identity-derived attributes, places the account in the right organisational unit, adds baseline groups and generates an initial password.
5. A post-provisioning workflow fires on the committed directory create. It waits (a sleep step) so downstream sync can settle, then:

• emails the line manager the credentials and a link to the IT requirements form,
• notifies local IT, the HR contact, the finance contact and the central team,
• writes the email and login name back to HR (see the identity page).

1. When the manager submits the form, a form-submitted workflow branches on the answers (for example which applications are needed) and sends mails to the ITSM mailbox that opens tickets. Each branch is a comparison step, so the workflow grows with every application option.

Joiner caveats

Leaver

The leaver design had three coordinated parts.

1. Reminders and the manager form. When an end date is set or changes, a workflow compares it to now and starts a reminder sequence: weekly reminders to the manager until a week before separation, then daily, with the country HR contact copied. The manager completes a leaver form (asset recovery, out-of-office text, who gets the mailbox).
2. The termination moment. At 22:00 local on the end date the lifecycle becomes inactive. The Inactive action disables the account on the listed sources. The directory disable policy moves the account to a disabled container, hides it from the address list and stamps a note.
3. Aftercare. A daily scheduled workflow finds leavers by their next-processing date through a search call and loops over them to finish off-boarding. Notifications go to the central team, HR, the finance contact, local IT and the manager.

Leaver caveats

• Timing and time zones. Automated tasks run in the user's local time after midnight; the cut-off is 22:00 local on the end date. A last day entered wrongly in HR (or an earlier "IDM disable date" than the stated end date) disables the person early. Several tickets were exactly this.
• Group removal is abrupt. On the first day of production the disable removed all groups, including the one that must always remain (the cloud-sync group), cutting a user off from mail who was still active in HR. Fix: keep a list of groups that are never removed, and delay removal of the rest for a number of days after the end date. The design said "seven days after termination only the base groups remain"; build it that way.
• Re-adding groups on rehire is not automatic. Previously removed groups do not come back; users must request them again. State this in comms.
• Mailbox side effects need a home. Converting the mailbox to shared, setting an out-of-office message, assigning a leaver licence and hiding from the address list were scripted steps in the legacy tool. Inventory them, decide which remain scripts, which become group-driven, and which become workflow steps. Do not assume ISC does them.
• Contractors and vendors. Vendor contract expiry arrives as a disable request, not an HR event. Provide an intake and an approval path.
• Extended access. HR sometimes asks to extend access after a recorded end date (handover, garden leave). The only clean path is to change the disable date in HR before it passes. Tell HR.

Mover

A mover is any change in a mapped attribute, but only some changes need action.

Attribute sync is the mover engine

ISC pushes only the attributes you enable in the source's attribute sync configuration. In the directory source about 8 attributes were on and 9 were off (names, display name, phone, employee ID, country code, user type, department were off at the end). This is by design: sync what the application team asked for, nothing else.

Rehire

Rehire is a lifecycle transition from inactive back to active or preJoiner for an identity that already exists.

• The directory account is re-enabled and moved out of the disabled container.
• A new initial password is generated and sent to the manager.
• Baseline groups return; business groups do not (see above).
• The workflow variant for a second directory domain triggers on enable rather than create.
• Rehire workflows showed many canceled executions. Investigate cancellations before accepting them as normal; ours were a mix of expected branches and unfinished waits.

Notifications and ITSM routing

Mail was the glue between ISC and everything else. Treat notification design as its own workstream.

Nightly validation during rollout

For the first weeks of production the team exported a joiner list and a leaver list each night from search (display name, email, created date, lifecycle state, source account count, start or end date, manager) and compared them to HR. Source account count was a cheap health signal: a joiner with fewer accounts than the baseline had a provisioning gap. This took an hour a day and caught problems before users did.

Design cautions

• Wait steps and form steps leave many executions in Executing or Canceled. Monitor the count, and know what a normal ratio looks like.
• A mover or joiner workflow branching on a dozen application flags becomes unmaintainable. Prefer data-driven branches (a form that lists requested access items) over one comparison step per application.
• Do not trigger a workflow from an attribute you also edit for testing. We kept "manual trigger" workflows keyed to a department change; they are a hack and should be disabled once real triggers work.
• Put the scheduled catch-up next to every event trigger. Events are lost, and the sweep repairs them.

Actions

• Enumerate lifecycle states and write down each state's account actions and source list.
• Add "update the lifecycle source list" to every source onboarding checklist.
• Build the re-send mechanism for forms before go-live.
• Define groups that are never removed and delay the removal of the rest.
• Inventory legacy mailbox and licensing scripts and assign each a new owner.
• Build the notification matrix and test every path end to end.