How to reduce DB load from SailPoint provisioning transaction audits?

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

We’re evaluating whether to re‑enable provisioning transactions in SailPoint because they were previously helpful for troubleshooting. However, the main issue we’re seeing is that modify transactions create a huge volume of data and quickly fill up the database.

From a usefulness standpoint, create, disable, and delete transactions seem more valuable, whereas successful modify transactions—especially filtered ones—don’t add much operational insight.

Question:
Is there a recommended approach or configuration to log only specific provisioning transaction types (e.g., create/disable/delete) while skipping successful modify transactions to reduce DB load?
Alternatively, is there a best practice for filtering or throttling provisioning transaction audits?

3

No, SailPoint does not provide an out-of-the-box way to selectively log provisioning transaction types.

Here’s the practical reality and the recommended approach.

IdentityIQ treats provisioning transactions as an all-or-nothing audit feature. Once enabled, it logs every transaction type—create, modify, disable, delete—without native filtering by operation type or success status. There is no configuration switch to exclude successful modify transactions, even filtered ones, and no built-in throttling mechanism for transaction volume.

Best-practice approach used in real environments:

  • Keep provisioning transactions disabled by default to avoid DB growth.

  • Temporarily enable them only during troubleshooting windows, then turn them back off.

  • Use target-side logs (AD, LDAP, app logs) and IIQ debug logs for day-to-day operations instead of transaction records.

  • If long-term visibility is required, implement DB retention/cleanup jobs to purge old provisioning transaction data on a fixed schedule.

4

I am currently looking for into writing an extension class which can suppress modify and keep other options enabled

5

either that or I’m sure you could handle with a custom task to clean up unwanted events

6

@abhishek_chowdhury IIQ should be updating the ProvisioningTransaction using one of the workflow libraries in Provision With Retries workflow. These libraries are internal APIs and we don’t have option to customize it. You can reach out to Sailpoint to see if they can help you with the customization or you can also try modifying it.

Alternatively, you can probably try few things:

1. Create a separate provisioning_transaction_clone table in a new database but in the same server.. Establish the sync between spt_provisioning_transaction and provisioning_transaction_clone and only sync the operations which you want. To visualize it you can create a simple UI using plugins or you can just run sql queries. Enable auto deletion for spt_provisioning_transaction which will clean up the data periodically.

2. You can also integrate your database with any ES based data visualization tool like Kibana, where you can sync the spt_provisioning_transaction table to Kibana and do the periodic cleanup in IIQ.

7

@abhishek_chowdhury We have a similar issue and here’s what we implemented:

  • Keep all provisioning transactions enabled.
  • Backup the provisioning transactions entries older than 60 days to a a different DB table.
  • Delete entries older than 60 days. (already backed up)
  • We have different views created using spt_identity and new table to visualize the data whenever needed.

Hope this helps!

8

You cannot do that. one of my customer had this issue and I created a rule to delete them on hourly basis to ensure db space is not occupied