Please share any images or screenshots, if relevant.
NA
Please share any other relevant files that may be required (for example, logs).
NA
Share all details about your problem, including any error messages you may have received.
I performed an “Edit Role” operation using the SailPoint IIQ UI. The Edit Role button is at the bottom of the Role Details page (which is launched upon search of the roles and clicking a role to view the details).
I checked the Audit config and I see the Update Role Audit event enabled snippet pasted below
However when I query the SPT_AUDIT_EVENT table for the DISTINCT ACTION in the table I do not see Update Role or any form of Edit Role action listed. I have queried the database post performing the “Edit Role” operation in SailPoint UI.
SELECT DISTINCT ACTION FROM SPT_AUDIT_EVENT WHERE LOWER(ACTION) LIKE ‘%role%’
I did try the option you mentioned and was able to get the audit logs. There is challenge though. I am not able to capture the exact details of what changes were done to the object. For example in case of workgroups which we are using for some approvals. I want to enable a mechanism of who were the historical members of the workgroup. Seems the audit table is able to capture the object and the user who modified along with the operation. However which attribute of the object and what was the old and new value is not seen.
If there is a way to capture it please specify how I can get this information.
Is there a common code or utility available which will enable get the updates done to the object. basically the audit should be able to inform what changed, by whom and when. The what changed is not captured in the current out of box implementation which I feel is a gap in implementation.
You ever hear back from this? My thinking is the same. This should be an OOTB feature to track why we’re doing an audit event. Just saying something was updated doesn’t help.
Option A (recommended in 8.4): Use Access History for real “what changed” timelines
IIQ 8.4 introduced Access History, which is specifically built to track history/deltas and supports objects including Workgroups (so you can answer “who were the historical members?”).
High-level steps:
Enable/configure Access History (separate Access History DB + queue + task).
Run/schedule Dispatch Access History.
Use the Access History UI / export, or query the Access History tables (workgroup capture/events are stored there).
This is the closest thing to an OOTB “diff” feature for the use case you described.
Note: Access History event timestamps reflect when the task ran (the capture time), not necessarily the exact second the admin clicked Save — that’s documented behavior.
Option B (if you must keep it in SPT_AUDIT_EVENT): Custom audit in the save workflow
If you need attribute-level “old/new” values in your existing audit trail, you’ll need to custom-log it:
Clone the workflow that saves the Role / Workgroup (or hook the save action you control)
Read/clone the object before update
Compare it to the object after update (e.g., compute member add/remove lists)
Write a custom AuditEvent (or persist the delta into a Custom object/table)
That will gives you exactly what auditors want: what changed + who + when + old/new but it’s custom because IIQ does not store that level of detail everywhere OOTB.
