New Capability: Delete Accounts (Human and Machine) with Configurable Approvals

[NataliaYunusov]

Description

Customers can now delete human or machine accounts directly in Identity Security Cloud (ISC) — with configurable approval workflows and complete audit tracking. This removes the need for custom BeforeProvisioning rules, reduces deployment friction, and enables true end-to-end lifecycle management for human, machine, and uncorrelated accounts.

This update introduces source-level approval settings for account deletion requests via UI, API, and the workflow. Together, these capabilities provide a secure, governed, and transparent way to manage account deletions.

New Capabilities

• Source-level Account Deletion Approval Settings for:
  • Human & Uncorrelated accounts
  • Machine accounts
• Single and Multi-step approval configuration
• New Delete Account action available across supported Account UIs for applicable sources.
• Workflow enhancement: The Manage Account → Delete Account action now performs true account deletion on supported direct sources (previously limited to manual task generation for Flat File sources)
• Account deletion supported via API, enabling automation use cases
• Request tracking via My Requests → Account Requests
• Approval tracking via Approvals → Account Requests
• Full audit logging for:
  • Approval configuration changes
  • Delete Account success and failure events
• Email notifications for request submission, decision, cancellation, completion, and failure.

Problem

Customers need the ability to delete accounts — not just disable them — particularly when users are terminated or machine accounts must be decommissioned.

To help address this, we introduced account deletion via lifecycle management, . However, because this capability was only applicable to human identities in an inactive state, some customers still rely on code-based BeforeProvisioning rules to perform all necessary account deletions

Solution

ISC now provides a fully governed, trackable, and auditable account deletion capability across UI, Workflow, and API for any type of account - machine or human.

1. Configure Account Deletion Approval Settings

Admins can configure approval requirements for account deletions under:

• Source → Account Management → Approval Settings (Human & Uncorrelated Accounts)
• Source → Machine Accounts → Approval Settings (Default Machine Accounts)

Approval is set as required by default, and the source owner is pre-selected as the approver.

New ‘Approval Settings’ for human and machine accounts

2. Delete Accounts from the UI and API

Authorized users (Org Admin, Source Admin, and Account Owner) can initiate account deletion from supported Account pages.

• If approval is required → A delete request is created and routed for approval
• If approval is not required → A confirmation modal is shown before deletion
• A request to delete an account can be made via the API endpoint
  • Approval logic applies when enabled via source configuration

‘Delete Account’ under the Actions menu

Submit the request when approval is required

3. Requester and Approver view

To support the growing volume and types of requests, the Request Center navigation and structure have been updated.

• The navigation bar now includes a Request Center dropdown with:
  • New Request
  • My Requests

Request Center new dropdown menu

• Account Delete requests can be:
  • Tracked under Request Center → My Requests → Account Requests

Dedicated Account Requests page to track the account deletion requests

• Approved from Approvals → Account Requests

Account Requests page to approve/deny the account deletion requests

5. Workflow Support for True Deletion

The Manage Account → Delete Account action in Workflow now performs a true deletion on supported direct sources.

Previously, this only deleted accounts for Flat File sources. It now executes real delete operations where supported and respects source-level approval settings.

Note: When an account is deleted, any associated entitlements that are linked to the account are removed from the identity. If the identity still has a role assigned that includes entitlements on the source on which the account is being deleted, ISC will delete the account, but it will be recreated on the next identity refresh because of the active role assignment. To avoid this, we recommend removing any related Roles from the identity before deleting its accounts.

Who is affected?

All customers.

Action Required

Administrators should review the new Account Deletion Approval Settings at the source level and update the default values as needed to align with their organization’s governance policies. Approval is enabled by default for account delete requests.

Customers currently relying on custom BeforeProvisioning rules for account deletion should also evaluate whether those rules remain necessary.

Important Dates

• Sandbox: March 23rd
• Production: Week of March 30th

[TheOneAMSheriff (Amar Sheriff)]

Hi @NataliaYunusov,

Thanks for sharing this update - this is a great addition to OOTB capabilities! The ability to delete accounts (both human and machine) with configurable approvals directly in ISC addresses a long-standing gap that previously required custom BeforeProvisioning rules.

What I like:

• True end-to-end lifecycle management without custom code
• Configurable single/multi-step approvals at source level
• Full audit trail and email notifications
• Workflow support for real deletions (not just Flat File sources)
• API support for automation use cases

One consideration for the community:

Since approval is enabled by default with source owner as approver, organizations that don’t intend to use this feature immediately may need to:

1. Review and update approval settings across all sources, OR
2. Ensure source owners are correctly assigned across their environment

For large implementations with 100+ sources, this could require some initial effort to align with existing governance policies - especially if source ownership hasn’t been consistently maintained.

Suggestion: It may be helpful to have a bulk update option via API or SPConfig to configure approval settings across multiple sources efficiently. Or not enable it by default to avoid this situation.

Questions:

For the workflow Manage Account > Delete Account action - does it now respect the source-level approval settings, or does it bypass approval when triggered programmatically?

Similar question on LCS, if a Source is listed on delete accounts during an Lifecycle State, will approval on source level apply or be skipped?

Thanks again for this enhancement!
Amar

[KRM7 (Krishna Mummadi)]

@NataliaYunusov

Authorized users (Org Admin, Source Admin, and Account Owner)

Who is Account Owner here, Source owner ?

[phil_awlings (Phil Rawlings)]

This is excellent news. To be able to delete single sub-accounts when they are no longer required rather than having them sitting there disabled on an active LCS cube is going to tidy up identities no end.

[angelo_mekenkamp]

Really nice to see this announcement. This functionality was definitely missing before! Thank you a lot for spending time on this and adding it. (you can also see this being important based on the amount of likes/positive replies compared to other announcements.)

I have played around with it in our demo tenant and hereby some questions/remarks from my side:

1. I can see the updated request center buttons, the option to delete the account, but I can’t see the approval settings on the source configuration page. Neither under Account Management nor under Machine Accounts
2. We have autoApprovalEnabled turned on, but nevertheless, I as requester received the request to approve the request. Is this approval workflow not taking into account this configuration yet?
3. We use custom email templates to add our branding and formatting. But each time a new email template gets added, the default SailPoint template is used. It would be great if we can also specify a template for the templates, such that the content is still considered default and updatable by SailPoint, but that the results for new email templates are directly in the desired formatting. Now we need to update email templates in the same way as soon as they become available.
4. Isn’t the fact that the delete account action in workflows is now being changed a breaking change? After all, before it got deleted automatically from the knowledge space of ISC, but now it will trigger an approval flow first? If the workflow originally wanted to just remove the account, allowing it to appear again during account aggregation (knowing this won’t actually happen since delta aggregation was turned on). Or will current workflows using this action still work the same, but new workflows will work differently?
5. Right now the brand-new API documentation for v2026 mentions the option to remove an account: delete-account-async | SailPoint Developer Community and to delete an account: delete-account | SailPoint Developer Community. The first one is to remove accounts regardless of source, the second one is only for delimited file sources but actually works similar. What will the API be to request deletion of the account, which then may or may not have an approval flow? I am not sure if according to the HTTP standards, you can use the DELETE method, where as a result it will not delete it, but instead create a delete request, which could be rejected days later by a human. So perhaps requesting deletion potentially requiring approval would need to be a POST method then? I am not sure here, but the APIs would need to meet the general REST API RFC’s.
6. I like that it is now easier to go to the My Requests tab!
7. Is it true that we still can’t delete accounts based on lifecycle state change for identities that are not marked as inactive (long-term)? Before we needed to rely on before provisioning rules with some strange configuration to make it work. But requiring a workflow is still a workaround, since ideally this can be done directly on the lifecycle state similarly to enabling and disabling accounts, which is the fastest and most logical method for this use case. Note that here it also make sense that there is no approval required, similarly to how disabling an account based on lifecycle state configuration does not require approval.
8. I approved the delete request I requested myself, and got this odd message:
   
   

Kind regards,
Angelo

[NataliaYunusov]

New Capability: Delete Accounts (Human and Machine) with Configurable Approvals

Hi @NataliaYunusov, Thanks for sharing this update - this is a great addition to OOTB capabilities! The ability to delete accounts (both human and machine) with configurable approvals directly in ISC addresses a long-standing gap that previously required custom BeforeProvisioning rules. What I like: True end-to-end lifecycle management without custom code Configurable single/multi-step approvals at source level Full audit trail and email notifications Workflow support for real deletions (not…

Thank you for your feedback!

We turned approval on by default, so account deletions are governed by default, reducing the risk of accidental or unintended deletes in production. We will also consider adding the ability to update the approval configs in bulk.

Workflow Manage Account → Delete Account follows source-level delete approval settings. Lifecycle management–driven account delete is unchanged and bypasses approval flow.

New Capability: Delete Accounts (Human and Machine) with Configurable Approvals

Who is Account Owner here, Source owner ?

@KRM7 It’s the account owner for machine accounts. It’s only applicable to customers with MIS product license.

[NataliaYunusov]

Thanks, Angelo, I really appreciate the enthusiasm for this announcement.

1. Please confirm the source supports account deletion for this capability. If delete is not supported on that source, the Account Deletion Approval Settings section will not appear under Account Management or Machine Accounts.

2. Re: autoApprovalEnabled: It’s possible you’re looking at the setting that applies to access requests, not account deletion requests.

3. Thanks, I’ll pass this to the right team. In the meantime, if you don’t already see it covered, please log it in the Aha ideas portal so we can track demand and notify you of updates.

4. For Flat File sources, Manage Account → Delete Account in Workflow continues to behave as it did before this change. For supported direct sources, the action now performs a real delete where the connector supports it, and source-level approval settings apply when configured (approval is set to true by default on all sources to reduce the risk of accidental deletions)

5. The new account-deletion API details have not been published on the Developer Community yet. When they are, I’ll link them from this announcement (and/or reply here with the direct doc links).

6. That’s great to hear.

7. With this release, you can request deletion of accounts for identities in any lifecycle state (for example, active, or inactive short- or long-term), subject to source support and approval settings. Lifecycle-state–driven account deletion (where the source is configured to delete accounts on state change) is unchanged and bypasses the approval flow.

8. Re: the message after you approved your own request: Were you the source owner for the source where the delete was requested? If yes, that explains it: with auto-approve off, we don’t allow you to approve your own request when you’re also the assigned approver, so the request escalates; with an empty escalation chain, it falls back to the source owner again, which can make the assignment/message look confusing. Hard to answer without looking at the configuration and the actual request.
   We’re also improving this message so it’s clearer, and we’ll show the identity name instead of the raw ID, where that was confusing.

Thank you.

[christophe_choumert]

Natalia, regarding points 2 and 8, I’m a bit confused: I can’t find a trace of an autoApprove setting that would apply to account deletion requests. Where would it be located?

The Approvals system has been overhauled recently, cf.

get-approvals-config | SailPoint Developer Community

for the documentation of the new API, but there is only ACCESS_REQUEST_APPROVAL to configure, no (theoretical) ACCESS_REVOCATION_APPROVAL

[mjogadia (Mehul jogadia)]

Has the JSON of the source changed? Can we add this feature by editing the source’s JSON?

[NataliaYunusov]

Hi @christophe_choumert .

The API endpoint get-approvals-config | SailPoint Developer Community has been updated and now includes ACCOUNT_DELETE_APPROVAL_REQUEST and MACHINE_ACCOUNT_DELETE_APPROVAL_REQUEST.

Make a get call to /v2025/generic-approvals/config/ACCOUNT_DELETE_APPROVAL_REQUEST and see what’s set in autoApprove.

[NataliaYunusov]

Hi @mjogadia ,

You can patch the source feature set to add delete if it’s not there.