Exchange Online mailbox conversion + delayed E5 license removal on termination/leave — best practice

Hi all,

Looking for guidance on a workflow involving Exchange Online and E5 license retention during termination and long-term leave. We use SailPoint Identity Security Cloud (ISC).

Scenario: when an employee is terminated or goes on long-term leave, IT converts the user’s mailbox to shared. When the user is rehired or returns from leave,the shared mailbox is converted back to a regular mailbox.

Questions:

1. Is there a recommended pattern to trigger Exchange Online
mailbox conversion (regular ↔ shared) as part of the SailPoint
lifecycle workflow? Direct connector, PowerShell, ServiceNow
ticket, manual IT step?

2. Can we configure delayed removal of a single entitlement (E5
license) within an access profile, while other entitlements
are removed immediately on lifecycle state change? The E5
license needs to remain assigned long enough for IT to perform
the mailbox conversion, then be removed automatically after N
days. Patterns I’ve seen mentioned: intermediate lifecycle
state, “retained on deprovisioning” flags, or a scheduled
workflow.

Has anyone implemented something like this? Any documentation,
examples, or pitfalls would be appreciated.

Thanks,
Sreesha

Hi @SreeshaC93 Each organization may have different requirements, infrastructure, and resources, so “recommended” solutions may vary. But I have a couple of ideas for you to consider, and you’re definitely on the right track already!

1.) I would solve this one with a Privileged Task Automation workflow. Outside of Identity Security Cloud you could address this with a PowerShell script. From an ISC PTA workflow, you can launch a PowerShell script from the Windows Server workflow action. You can trigger this workflow with the Interactive trigger, (manual initiation of the workflow), a scheduled trigger, or some kind of lifecycle event (An identity attribute changed, for example), which brings us to your second question…

2.) You can achieve this objective with access profiles and dedicated lifecycle states for a short-term leave of access situation, as you suggested!

  • In the relevant identity profile(s), configure a new lifecycle state “short-term leave” with identity state 'inactive short-term".
  • Configure an access profile to allow the ‘on-leave’ user to have only exactly the access they need.
  • In the identity profile, include this new access profile for the new lifecycle state.
    • Access profiles assigned from other lifecycle states are deprovisioned when they move into that new lifecycle state as documented here in the Admin Help. I recommend reviewing this topic also, because you may have more complex configurations to consider.

Otherwise, you could use workflows for other lifecycle management and specific requirements..

Could this work for your configuration?

In addition to what @amy_shillinglaw posted, there was an excellent session on the SailPoint Developer Day’s yesterday that covered some of this and how to build out this type of custom workflow using the PTA.  The speaker actually built out a small example on the session, and it may be of some use to you to watch the recording.  It was one of the ISC - Advanced Sessions on Wednesday.  The schedule isn’t available any longer so I can’t remember the name of the session, but it should be easy to find once the recordings are posted.