Share all details about your problem, including any error messages you may have received.
Hi Community,
I am looking for guidance and best practices regarding the full lifecycle of accounts managed via Roles in a JDBC/Direct Management application.
Our Current Setup:
We want to use Business and IT Roles to manage access to a custom SQL database.
Provisioning (Inbound): Works perfectly. When a Role is assigned, a Create operation is sent to our JDBC Provisioning Rule, and the account is created.
The Issue:
When the Role is removed, the account remains in the target database. IdentityIQ does not trigger a Delete operation. Instead, it often performs a Modify (attribute sync) or skips provisioning entirely because the account “Exists.”
I am looking for a robust, “set-and-forget” configuration that ensures the SQL row is removed as soon as the role is gone.
Hi @thp015 What you are experiencing is actually expected behavior in iiq due to how the platform separates account lifecycle from role lifecycle.
When a Role is assigned, iiq can trigger a Create account operation via the provisioning policy. However, when the Role is removed, iiq does not automatically assume the account should be deleted. This is because the account may still be required by other roles, contain direct entitlements, or be reused by other access models. As a result, iiq typically performs a Modify operation or no action if the account already exists.
For JDBC/Direct managed applications, the recommended approach is to explicitly implement account deprovisioning logic. The common best-practice options are:
Use a Before Provisioning Rule to dynamically add a Delete operation when the role driving the account is removed.
Also ensure that the application schema and JDBC provisioning rule support the Delete operation, otherwise iiq will never send a delete request.
Once this deprovisioning logic is in place, the lifecycle becomes fully automated:
Role Assigned → Account Created
Role Removed → Account Deleted
This provides the “set-and-forget” behavior you’re looking for.
@thp015 Please enable logs in your jdbc application’s before provisioning rule and see In case of removal of roles, if plan is available or not. If everything is filtered out, and nothing in plan for application, then before prov will not be triggered.
You may also give it a try by creating a dummy entitlement in your application, which will force IIQ to remove ent for role removals and you’ll have the plan coming to your before provisioning rule. Once controls comes there, then you can modify the plan and add delete/disable operation.
Hi @thp015 , Welcome to Sailpoint Developer forum.
This is OOTB behaviour. removal of role will only remove entitlements on target side, not remove account.
As @santhirajumunganda and @neel193 suggested , you can add logic that if there are no entitlements after your role removal request, add Delete operation in provisioning plan and see if it works.
Thank you for the help! It’s clear that I need to explicitly handle the deprovisioning logic as you suggested. I’ll give this a try in my environment.
This is a well-known IIQ behavior. IIQ does not automatically send a Delete account operation when a role is removed — it only sends Delete if the application’s Provisioning Policy has a Delete Policy defined AND the IIQ lifecycle state logic triggers deprovision. Here’s exactly what needs to be configured:
Enable Delete in Provisioning Policies — On the JDBC application, go to Configuration → Provisioning Policies and add a Delete policy. Without this, IIQ will never send a delete operation to the connector.
Configure Deprovisioning in Lifecycle Events — Create or edit a Lifecycle Event (e.g., for role removal / leaver). Under the provisioning actions for that event, configure the application to perform Disable Account or Delete Account when the role entitlement is removed.
Before Provisioning Rule (optional, for fine-grained control) — If you want the delete to fire specifically when the last entitlement from that role is removed, add a Before Provisioning Rule that transforms the provisioning plan: check if the account has no remaining entitlements and change the AccountRequest operation to Delete.
“Manage Accounts” setting — Ensure the JDBC application has “Manage New Accounts” enabled under the application’s Account settings, so IIQ actively manages the account lifecycle. Doc references: