I want to achieve ISAM account deletion for the identity whenever there is a name change and create a new ISAM account with new name

Identity Security Cloud (ISC) ISC Discussion and Questions
7

Hi @Namratha23,

That’s a great question, and a common scenario when managing identity lifecycle events. The “400 Bad Request” error you’re seeing is due to a specific limitation in the Manage Accounts workflow step.

The Root Cause: “Delete” is for Flat Files Only

The Delete operation within the Manage Accounts workflow step is designed to work only with flat file sources (also known as Delimited File sources). Since IBM Security Access Manager (ISAM) is a standard, non-flat-file source, the workflow step fails with a “Bad Request” error when you try to use Delete on it. This is a documented limitation in the official Workflow Actions documentation.

The Best Solution: Use Lifecycle States (As You Discovered!)

You mentioned that you are able to delete the ISAM account using Lifecycle States, and that is absolutely the recommended approach! In September 2025, SailPoint released a new capability allowing administrators to configure account deletion directly within Lifecycle States for supported connectors.

This method is more robust because it uses the proper provisioning process for the source, bypassing the limitation of the generic “Manage Accounts” workflow step. As long as your ISAM connector supports the delete operation, Lifecycle States are the cleanest and most reliable way to handle this.

Alternative Solutions

If for some reason you couldn’t use Lifecycle States, here are a couple of other ways you could approach this, though they are generally considered workarounds:

  1. Use “Disable” Instead of “Delete”: The simplest alternative in your workflow would be to change the Manage Accounts action from Delete to Disable. The Disable action is supported for all source types and would prevent the account from being used.

  2. Use a Before Provisioning Rule: You could keep the Disable action in your workflow and then use a Before Provisioning Rule on the ISAM source. The rule would intercept the “Disable” provisioning plan and modify it into a “Delete” plan before it gets executed on the source. This adds a bit of complexity but is a powerful way to customize provisioning logic.

To summarize, your current approach of using Lifecycle States is the best practice. The workflow was failing due to a known limitation of the Delete action in the Manage Accounts step.

Hope this helps clarify things!