Web Services Connector - Delete Account when last entitlement is removed

Hello Sailers,

I have a web application and when the last entitlement is removed, the account is deleted. The application does not support an account with zero entitlements, so the Remove Entitlement operation will fail, if the last entitlement is attempted to be removed.

What is the best way for me to approach this? Should I use a WebServiceBeforeOperationRule? Or would it be better to be use a BeforeProvisioning rule deployed to ISC?

I have seen this post Webservice Connector - Remove account when there is one entitlement left from 2024, and they refer to https://community.sailpoint.com/t5/Working-With-Services-Knowledge/IdentityNow-Mock-Project/ta-p/208216 the Mock Project. But I am not a partner, I’m not sure whether I have access to the mock project, because I do not have a partner tenant.

Thanks in advance for any tips!

In my opinion SSI BP Rule cannot do what you are trying to achieve (Neither the requirement in the post). You will need a custom rule that will check the current list of entitlements being removed against user’s current list of entitlements from the source and if it’s a 100% match change the operation to Delete

You can achieve the same result if you add a before Operation Rule that will check if the access removed is the last and if it is changes the request URL and body to the Delete Operation.

SailPoint will return Status 200 and will think that the group is removed so the account will remain in SailPoint without that entitlement and it will be deleted in the next aggregation.

Rehires or granting access again from the moment the last access is removed and the aggregation runs might fail but if you use roles they should work fine.

@Oliver Thornewill von Essen

I would recommend using a Before Provisioning Rule rather than a Web Services Before Operation Rule. The Before Provisioning Rule can inspect the provisioning plan before it reaches the connector and, if the entitlement being removed is the last entitlement, replace the Remove Entitlement request with a Delete Account operation.

Benefits of this approach:

  • Handles the logic centrally before connector execution.
  • Prevents the connector from attempting an invalid “remove last entitlement” operation.
  • Works regardless of how the provisioning request was initiated (access request, certification, lifecycle event, etc.).
  • Keeps the connector configuration simpler.

The WebServiceBeforeOperationRule can also work, but it is connector-specific and is usually better suited for request manipulation immediately before the API call.

A common pattern is:

  1. Check current account entitlements.
  2. If the entitlement being removed is the last one remaining:
    • Remove the entitlement operation from the plan.
    • Convert the request to a Delete Account operation.
  3. Otherwise, proceed with the normal Remove Entitlement operation.

If account entitlement count is not available in the provisioning plan, you may need to query the account via the connector or use account data already present in ISC to determine whether it is the final entitlement.

oliverthomas09 Oliver Thomas