Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
I have created a workflow to trigger when there is a name change and used HTTP call to fetch the ISAM account for the identity and using Manage accounts to delete.
Workflow is getting completed successfully but in Manage accounts step it is showing as “errorMessage”: “request failed (type: Bad Request, retryable: false): 400 - 400 Bad Request”.
Can you let me know if there is anyway to make this work(FYI -i am able to delete ISAM account from lifecycle states)
Yes. from workflow (or API natively), Manager account’s delete op is for flat files account.
if you have a delete provisioning operation on this object maybe you can trigger it based on identity profile changes using a rule but i am still not sure if you can from workflow.
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:
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.
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.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
