SailPoint Lifecycle Manager workflows

Lifecycle Manager ships pre-built workflows for access requests, manage-accounts, and identity lifecycle events. They handle approval, provisioning and notification out of the box.

The idea underneath lifecycle management is one sentence: access should follow employment, and it should do so without anybody filing a ticket. Somebody joins and gets what their role needs. They move to another department and lose what they no longer need as well as gaining what they do. They leave and everything is removed the same day.

The third of those is the one that matters most and is done worst. Joiners are visible, because a person who cannot work complains immediately. Leavers are invisible: nobody notices access that should have gone and did not, which is why orphaned accounts are found by auditors rather than by the people who run the system.

Movers are the hardest of the three. The instinct is to grant the new access, and the removal of the old access is what gets skipped. Somebody who has moved three times carries the union of four jobs, which is how a single individual ends up able to raise a purchase order, approve it and pay it.

Where it lives: lifecycle states sit on the identity, lifecycle events watch for changes and fire, and the work they generate becomes provisioning requests carried out by connectors against the target systems. Those three layers fail in different ways and are debugged in different places, so getting the vocabulary straight early saves a lot of confusion later.

The core LCM Provisioning workflow compiles a provisioning plan, gathers approvals, checks policies, and hands the plan to the provisioning engine and connectors.

Worth walking through what happens between the trigger and the account, because every failure sits at one of these steps.

1. An identity attribute changes, usually because the HR source refreshed.
2. A lifecycle event matches the change and fires.
3. Role assignment is recalculated: which birthright roles does this person now qualify for.
4. The difference between what they should have and what they do have becomes a set of provisioning requests.
5. Policy is checked. A request that would create a separation of duties violation is stopped or routed for approval.
6. Approvals run where they are required.
7. The connector executes against each target system, and the result is written back.

Step seven is where most operational trouble lives, because target systems are not always available and not always fast. A provisioning request that failed at the connector is not a workflow problem, and diagnosing it as one wastes a great deal of time.

The other thing to know about step seven is that it is asynchronous and it can be partial. A single identity change can produce provisioning across six systems, and four succeed while two fail. The identity now has an access profile that matches neither the old job nor the new one, and nothing in the interface shouts about it. Somebody has to be watching the failed request queue, and on most implementations that responsibility is assigned late, after the first time a mover spent a fortnight unable to do half their job.

Joiner, mover and leaver events are triggered by identity attribute changes and launch configured workflows to grant or revoke access automatically.

The design decision worth making explicitly is what counts as a trigger. Events fire on identity attribute changes, so the quality of the event depends entirely on the quality of the attribute. A termination date that HR fills in a week late produces a leaver event a week late, and no amount of workflow configuration fixes that.

The related decision is what happens between the trigger and the effect. Immediate revocation on a leaver event is correct for most access and wrong for a few things, such as a mailbox somebody needs to hand over. So real configurations usually have a disable step and a delete step separated by a defined period, with the disable immediate. Deciding that period, and who owns the exception list, is a business conversation rather than a technical one.

Two operational cases are worth designing for before they happen. Rehires, where an identity that was terminated returns and either reuses the old record or creates a second one, and the choice decides whether their old access comes back with them. And contractors, who often have an end date that keeps moving, so a leaver event driven by that date fires and has to be undone. Both are common, both are usually handled after the first time they go wrong, and both are cheaper to think about now.

Two hours in a test environment, and it is the exercise that exposes whether your lifecycle actually works.

1. Take a test identity with access from one department. Record exactly what they have.
2. Change the attribute that represents their department in the source, and let the aggregation run.
3. Watch the lifecycle event fire. Note the time between the source change and the event, because that gap is your real world exposure window.
4. Look at the provisioning plan before it executes. It should contain both grants and revokes. If it contains only grants, your role model removes nothing and you have found the problem.
5. Let it run and check each target system directly rather than trusting the status in the console.
6. Now repeat with a leaver, and check the same systems.

Step four is the whole point. A lifecycle configuration that grants correctly and revokes nothing looks successful in every dashboard and accumulates exactly the problem this feature exists to prevent. See configuring lifecycle events.

You extend LCM by editing the shipped workflows or, better, by adding subprocesses and rules so upgrades stay clean.

The rule that keeps this maintainable is to change configuration before changing code. Role definitions, event conditions, approval schemes and notification templates are all configuration, and a great deal of what teams write custom workflow for is achievable there. Custom workflow steps are legitimate for genuinely bespoke logic and each one is something that has to be understood and tested at every upgrade.

Version note: this material describes the on-premise product's workflow engine. The cloud offering approaches the same problem differently, with its own configuration model rather than the same workflow definitions, so guidance does not transfer directly between the two even though the lifecycle concepts are identical. Establish which product you are working with before following any specific instruction. See workflows, approvals and custom workflow steps.

One practice pays for itself repeatedly: make the workflow log what it decided, not just what it did. A provisioning plan that contains no revokes is either correct or a bug, and the only way to tell later is a record of the role calculation that produced it. Teams that log only outcomes end up rerunning scenarios in test to answer questions about what happened in production.

• Movers that only grant. Access accumulates and nobody notices.
• Trusting the console rather than the target system. A green status is not an account.
• Leaver events driven by a date nobody fills in on time. The workflow is correct and the exposure is real.
• Custom code where configuration would do. Every upgrade pays for it.

Configuring a joiner takes an afternoon, and building a mover and leaver process that a business will actually keep accurate is the work the course covers.