Workflow – Leavers Process: Triggering Email Notification to Line Managers on a Lifecycle State

Before the introduction of the workflow feature in SailPoint IdentityNow (ISC), I was limited to using the out-of-the-box email templates provided by SailPoint ISC. This often required reliance on external tools to trigger bespoke email notification workflows based on changes in a user’s attributes. The new workflow feature in SailPoint ISC has simplified this process, allowing me to manage everything within a single system.

A common use case I frequently encounter involves sending bespoke email notifications to line managers, alerting them that a direct report will lose IT access on a specific date. This advance notice allows line managers to prepare for the leaver’s process or take corrective actions if the proposed IT access termination is incorrect.
The approach discussed in this blog can be applied to any attribute in ISC that an organization chooses as a trigger for sending notifications. For this example, we will use the lifecycle state (LCS) to handle the trigger for the email notification.

Business Requirement
As a Line Manager, I want to be notified 14 days before my direct report’s IT access is terminated so that I have sufficient time to prepare for the leaver’s process or take corrective action if the IT termination date is incorrect.

Pre-Requisite
ISC should be configured to calculate the lifecycle state of a user using the cloudLifecycleState identity profile attribute. In this scenario, a lifecycle state (LCS) called “Inactive 14” has been set up to trigger 14 days before the user’s end date attribute in ISC.

Workflow Setup

Step 1 – Identity Attribute Change Trigger
A trigger is necessary to initiate the workflow, enabling ISC to take action. In this scenario, the trigger will be based on a change in an identity attribute. In the workflow, select the trigger “Identity Attributes Changed.”

Step 2 – ‘Compare Strings’ Operator
An operator is required as a conditional step to determine the action based on the operator type. In this scenario, use the “compare strings” operator to compare and decide the action based on the results. If the condition is not met, the process is terminated with a “success” operator. If the condition is true, it moves to the next step.

Step 3 – Get Identity
If the result from the previous step is true, an action is performed to retrieve the available details about the identity.

Step 4 – Get Line Manager Details
The result from the previous step is used to extract the line manager’s information from the user profile, which is then used to populate the recipient field for the email to be sent in the next action.

Step 5 – Send Email - IT Access Termination Warning Notification
An email is sent to the line manager defined in the recipient email address. The email attribute variable of the line manager is used to fulfill this use case. The “From” and “Reply to Email Address” fields can be directly entered into the workflow. The “Body” field is where you can customize the content of the email. Variables pulled from previous actions using JSONPath can be included as long as they are declared in the templating context. Refer to this link for more details.


Step 6 – Finish Workflow End Step – ‘Success’ Operator
A success operator is always needed to indicate that the workflow has completed successfully.

Testing the Workflow
We can test this workflow using the built in test workflow functionality.

{
  "identity": {
    "id": " 2c91808476e467560176f0dc60c95c3a",
    "name": "john.doe",
    "type": "IDENTITY"
  },
  "changes": [
    {
      "attribute": "cloudLifecycleState",
      "oldValue": "active",
      "newValue": "inactive14"
    }
  ]
}

Result

3 Likes

Hi @Boje1232 - great read.

I’m curious, why not just use the email notification for manager when the user transitions to this inactive-14 LCS? It is available out of the box and you wouldn’t need the workflow.

Great questiont! The out-of-the-box Manager Notification functionality in Identity Profiles which i beleive is what you are referring to is primarily designed for lifecycle events changes, such as when a user’s status changes (e.g., hire, termination,) While it’s convenient, its scope is limited to pre-defined templates ,a narrower set of variables and in addition, managers may not want to be notified about other lifecycle state changes which makes this options not favourable for this use case.

Key Points of Differentiation:

  1. Purpose & Customization:

Out-of-the-box Email Manager Notification: Focused on lifecycle notifications and leverages a static email template. It’s efficient for standardized communication but lacks adaptability for specific organizational needs.

Workflow: Tailored to the organization’s requirements, this option allows you to craft messages with custom content, formats, and additional data points that matter to the business.

  1. Flexibility with Variables:

Out-of-the-box: Restricted to certain variables defined within the system (e.g., user name, lifecycle event type).

• *Workflow: Offers the freedom to include dynamic variables (e.g., manager name, team metrics, deadlines for action items, or links to dashboards). This flexibility ensures the content aligns with business-specific workflows.

  1. Experience & Engagement:

• The workflow provides a better user experience by being more aligned with the type of information that line managers need. For example, it can include detailed next steps, user-specific data, or action triggers that are not possible with the pre-built functionality.

  1. Use Case Versatility:

Out-of-the-box: Best suited for standard lifecycle events with no requirement for additional context or personalization.

Workflow: Ideal for show-and-tell use cases or complex communication flows where additional data points, formatting, or actions are required.

2 Likes