While reviewing spt_audit_event, I observed the following:
Aggregation (Scheduler) generates audit events such as Create, Update, Delete, with Source = Scheduler.
User-driven operations (via UI/provisioning) generate audit events such as Create, Update, Delete, EntitlementAdd, EntitlementRemove, with Source = User (e.g., spadmin).
Since both Aggregation and user-driven operations generate Create/Update/Delete events, I wanted to know:
Is there a supported way to reliably differentiate audit events generated by Aggregation from those generated by provisioning or user-driven access changes?
Any insights or best practices would be appreciated.
I observed the same. My question is more around cases where other scheduler-driven processes (for example, access revocation or workflows) may also generate audit events with Source = Scheduler. Is there any other attribute that can help distinguish aggregation events from those?
My requirement is to identify only aggregation-generated events. Since Scheduler/RequestHandler can also be used by other system-initiated processes (for example, revocation workflows or other scheduled tasks), I’m trying to understand if there’s any attribute or context that uniquely identifies events generated specifically by Aggregation.
@shsakshi Understood. these are shared Source and used for aggregation, certification, and other automated modules.
Please try with Interface. For LCM and Certification, it used to set. but not sure for aggregation. May be in-combination with Interface and Source, you should be able to get it.
Then I don’t think there is any OOTB way. If you want, you can add custom audits in your customization or correlation rules to figure out how many of them created or modified using aggregation.
One thought— any idea whether spt_provisioning_transaction could help distinguish these scenarios? As far as I understand, it stores provisioning operations (create/modify/delete) triggered by provisioning, such as access requests, and certification-driven entitlement removals. I’m wondering if correlating audit events with provisioning transactions could help separate aggregation-related events from provisioning/certification events.
The use case is to capture all changes except aggregation-specific ones.
I want to track changes coming from provisioning, access requests, certifications, and other user/system-initiated operations, but exclude changes that occur solely because of account aggregation.
Since the audit events look similar, I’m trying to find a reliable way to distinguish aggregation-related changes from the rest.
Hello Sakshi. I think there is no OOTB column on spt_audit_event that reliably separates aggregation from other operations. As your test showed, aggregation and certification remediation can produce the same Scheduler / null / delete signature, because source reflects the execution context rather than the original business operation.
Your spt_provisioning_transaction idea is a good one. I would use it as the primary record of provisioning and deprovisioning activity instead of trying to filter spt_audit_event. IIQ creates provisioning transactions for certification remediation, LCM requests, policy violation remediations, lifecycle events, and identity-refresh-driven assignments (Recording Provisioning Requests). Aggregation itself does not create them, though any separate downstream provisioning triggered afterward would be recorded independently. For direct interactive UI or admin-initiated changes, spt_audit_event.source will generally contain the username (like spadmin), making those already distinguishable.
I would not recommend joining the two tables by timestamp. A certification can create a provisioning transaction when it removes access, and a later aggregation can discover that same deletion and generate its own audit event. There is no documented one-to-one key between the two objects, so a match would only confirm provisioning occurred, not that the specific audit row came from it.
To get this working, enable Provisioning Transaction Log under Global Settings > IdentityIQ Configuration > Miscellaneous, set Maximum Log Level to Success, and configure Days before provisioning transaction event deletion to keep the volume manageable (Admin Console).
If you need one consolidated feed with exact origin tagging, a custom audit event written from the provisioning or remediation path (with the request or certification ID) would be the reliable option, though that requires development at each applicable processing point.
@shsakshi Then focus on ProvisioningTransactions. But you’ll find few redundant transactions which you can filter by setting Channel = appname or if you are writing a report, then ignore Channel=Filtered, then this’ll return all the provisioning transactions where IIQ actually tried making changes to the target application. You can also add a filter on created or modified to track changes made on specific window like in last 24 hours.
