We have now implemented the before provisioning rule; however, it seems that the “Disable” function is no longer available, as the connector now attempts to delete the account directly. Disable is sometimes useful in some cases for us.
Did we configure it incorrectly? Ideally, we would like to retain the ability to perform a standard “Disable” action, while still ensuring that accounts are deleted automatically through the before‑provisioning rule on termination.
I believe the operation might be getting changed from disable to delete, which could be why the disable action is no longer being utilized.
Could you please share your BP rule (masking any customer-sensitive information, if applicable)? Alternatively, you may want to check whether something like setOperation is being used in your rule.
Also, you are correct—delete action has been added in the Identity Profile.
Sure , this is the beforeprovisioning rule which converts Disable to Delete, I don’t believe that there is customer (our) information. The stuff inside the else component is for another attribute (not relevant).
Any particular reason for going down the BP route rather than the inbuilt functionality of identityProfiles?
Yes the reason is when we were in the development/ before we went live, this feature did not exist. And the implementation partner did not want to go with the new feature in Prod without testing in SB (I agree) - and the pressure to have something which cleanes up accounts now on termination is required. We can(will) look at the identity profile way in the future. But because the feature is relatively new, I thought that others perhaps encountered the same “issue” before the identityProifle feature was released
Yes, you are converting the disable operation to delete, as you mentioned earlier. However, if you need both disable and delete actions, you can take advantage of the new feature that SailPoint recently released, which allows you to disable accounts as well as delete them.
