Emergency Terminations of Identities Using IdentityNow

Emergency Terminations of Identities in Identity Now is one of the most common use cases we come across in Organizations these days

In some cases, when an identity is terminated in an authoritative source, the identity’s accounts and access need to be disabled immediately. This use case can be handled in a few different ways.

  • Automatic lifecycle state change
  • Manual lifecycle state change
  • Workflow

Please continue reading to learn how to configure emergency termination using each of the three approaches.

Automated Lifecycle State Change

In this approach, we create a new lifecycle state (LCS) to handle identity termination. Once the authoritative source accounts are aggregated, the lifecycle status attribute transform will detect the change and update the LCS of the identity. Based on the LCS configuration, a disable operation will be invoked on the source accounts. Access profiles granted by the “active” LCS will be revoked automatically. In addition, if the user has any roles assigned via LCS criteria, those will also be revoked automatically.

While this approach is simple, there may be a slight time delay depending on the authoritative source aggregation schedule. If you need to terminate identity’s faster, please see the next two methods.


Please use the following steps to setup an automatic lifecycle state for emergency termination.

  1. Create a new lifecycle state (LCS) in authoritative source’s identity profile called “Emergency Termination”.

    Go to Admin → Identities → Identity Profile → Provisioning and Click Add

    • LCS Name = Emergency Termination
    • LCS Technical Name = emergencyTermination
  2. Enable the LCS

  3. In this new lifecycle state, we can add the source accounts to disable in the list below. Once done, click Save.


  4. In “Mapping” tab for lifecycle state identity profile attribute, add/modify your lifecycle state transform, if you have one. The transform provided in this example will translate the employeeStatus attribute on the source to a valid lifecycle state in IdentityNow. You can use the transforms API or the SailPoint CLI to create/update your LCS transform.


      "attributes": {
        "table": {
          "Active": "active",
          "On Leave": "onLeave",
          "Terminated": "emergencyTermination",
          "Retired": "terminated",
          "default": "Invalid"
      "type": "lookup",
      "name": "Lifecycle State"

    If you have deployed a LCS Complex Data Source (Cloud Rule), you will have to modify the logic inside that rule and deploy it using SailPoint Expert Services.

  5. Finally, click on apply changes on top to trigger the identity profile refresh


To test this setup:

  1. Request the HR team to terminate a user
  2. Aggregate the authoritative source (automated or manual)
  3. Verify the identity LCS shows “Emergency Termination” on identity details page


Manual Lifecycle State Change

In this approach, we will terminate the identity by manually setting their lifecycle state to “Emergency Termination”. This can be useful in scenarios where automation is not possible, or there needs to be greater control over when the termination needs to happen. For example, the SAP team informs the IAM team about the user termination. An IdentityNow administrator then logs into IdentityNow and modifies the lifecycle state of this identity manually.

This approach is similar to the first one, except that the LCS change is manual and not automatic. The advantage of this approach is that it doesn’t require any code/logic to be modified in the LCS rule or transform. The disadvantage is the manual Intervention required.


For setting up the “Emergency Termination” LCS please refer to steps 1, 2, and 3 in the setup section of Automated Lifecycle State Change.

To change the LCS manually:

  • Go to Admin → Identities → Identity Details

  • From the LCS dropdown menu, select “Emergency Termination”


  • After processing is complete, you should be able to see the user LCS change as below.



To overcome the time delays and avoid any manual interventions, we can use an IdentityNow Workflow to handle the use case in real time. In this approach we will be using an external trigger to kick off the workflow.

Workflow Design

  • The authoritative source will invoke the workflow using an API call
  • This API call will be our external trigger to begin the workflow
  • Within the workflow we will read information sent by the authoritative source to perform the following actions:
    • Identify the identity to be terminated
    • Use the “Manage Access” action to remove the identity access (non birthright)
    • Use the “Manage Accounts” action to disable the target accounts of the identity
    • Notify the manager of identity termination

Building the Workflow using UI Builder

Step 1 - Trigger

In External Trigger, Use New Access Token button to generate a Client ID and Secret that can be used to generate a token and invoke this Workflow. Once they are generated you will also get the URL that can be invoked by the Auth source.

Ex. https://tenant-name.api.identitynow.com/beta/workflows/execute/external/:id

Step 2 – Compare Strings


Step 3 - Get List of Identities

Search Query - attributes.identificationNumber.exact:{{$.trigger.employee_id}}

Step 4 - Get Identity

Identity - $.getListOfIdentities.identities[0].id

Step 5 - Get Access

Step 6 - Get Accounts

Step 7 - Manage Access

Comments: Emergency Termination of user in Authoritative Source

Step 8 - Manage Accounts

Note: In this example I am terminating only one source account with sourceId mentioned above.

Step 9 - Get Identity 1 ( Manager )

Identity - $.getIdentity.managerRef.id

Step 10 - Send Email

Recipient Email Address - $.getIdentity1.attributes.email

Step 11 - Finish your workflow with two Operation: End : Success

The complete Workflow looks like below:

Testing the Workflow

We can test this workflow using the built in test workflow functionality or using Postman to call the API:

Testing in IDN

Test payload input

  "action": "terminated",
  "employee_id": "1234567"

Testing using Postman

POST https://{tenant-name}.api.identitynow.com/beta/workflows/execute/external/{workflowId}

Header – Content-Type application/json
Authorization – Bearer Token {{access-token}}
Body –

  "action": "terminated",
  "employee_id": "1234567"

Once the workflow is tested successfully, you can enable it from workflow dashboard page.

Please see attached the JSON file for this Workflow. You may use it as a starting point and customize it further to meet your business requirements.

EmergencyTerminations.json (4.6 KB)


This approach works in real-time and without any manual intervention. This workflow can be further edited to add HTTP Actions to Service Now system to create ticket for disconnected systems de-provisioning or use email action to notify the system admins directly. Workflows offer a lot of flexibility, allowing us to configure it for specific actions as per business needs.


Thanks for this @sharvari :confetti_ball:


Thanks for the blog @sharvari . I have a question with the workflow option. When you are removing Access in Manage Access step does the workflow removes access granted via request center?
If it can will the access gets added back because the access is granted by access request route.

1 Like

This is great! I have a similar requirement but not for termination but just for “revoke”. We have a life cycle event to disable accounts on selected connected systems that will not allow users to authenticate on those systems.

I can make use of this and tweak it as per my need.


Yes, the Remove Access action removes the access via Request Center route, so if you have any approvals before access removal those will be triggered. If not, its auto approved and access will be removed immediately. The access won’t be added back automatically by the system.

But if your access is part of any Birthright role assignment based on membership criteria it will still be there if identity meets the role criteria.

1 Like

Thanks for the feedback, Raghunath. I am glad you find this helpful.

1 Like

@sharvari Thanks great post.

@sharvari This was insightful. I have a question around step 8, where you disable an account by specifying the source* ID in the filter. Does the workflow disable a connected source’s account in the target as well?

In an unrelated workflow when I attempted Manage Accounts step with action being Delete, it did delete the link on the UI to the account, but the actual account of the user on the target system (in my case, an AD account) was still present. Does it do downstream provisioning when we use this step in the workflow?

1 Like

Thanks Sushant.

Yes, the Manage Accounts step does take care of downstream provisioning as per option selected.

In step 8, we are disabling the account on connected source in IDN which in turn disables it in target system. If you don’t provide the filter on source ID, this step will trigger a disable on all the accounts returned by Get Accounts in step 6. If source is connected the provisioning action will be fired immediately, if its a disconnected system a manual task will be created.

For Manage Accounts Action in Workflow the Delete Accounts option is only applicable to accounts on flat file sources, it doesn’t work for other source types.


That makes a lot of sense then, thanks @sharvari!

I just noticed this is highlighted with a box in the documentation here:


Great article! Very comprehensive around the most supportable ways to accomplish this very common (and very important) use case. Especially love the detailed screenshots and code snippets needed to implement each type of solution. Kudos, @sharvari!


The manage account action confuses me. i am trying to use it in my workflow and it does not seem to work at all. My workflow completes successfully but the accounts do not get disabled. Here are the two different methods i tried and got the same result. I wan to disable all accounts the identity has.
What should i set this to to achieve what i am trying? Thank you in advance!

I also tried, after seeing this,
and it still returns the following

  "failedAccounts": [
  "successfulAccounts": null

This will work only when you have a Get Accounts(getAccounts) step before Manage Accounts step. If your step name is getAccounts1 or something else you need to modify the JSON accordingly.

1 Like

This is an excellent write up! We are currently using option two, rule out option one, and thanks to this post are fast tracked to option three.

1 Like

awesome, it helped a lot, thanks.

1 Like

Great write-up. Can anyone explain how the approach 3 is going to change the LCS?

Thanks Jyoti.

Approach 3 helps with terminating the accounts/access immediately using workflow but the actually LCS will be modified to inactive/termination once your HR data is aggregated into the system probably a few hours later.

If you wish to update it right away, you can add an HTTP action to workflow and call the Set Lifecycle State API.


Nice article @sharvari …!

1 Like

Thanks Sharvari. Very good explanation. !

1 Like