Please share any images or screenshots, if relevant.
No
Please share any other relevant files that may be required (for example, logs).
No
Share all details about your problem, including any error messages you may have received.
I want to track history of the configuration changes made to an application from IIQ UI or from debug page. In case an adminstrator changes for e.g. user filter of Azure AD connector, the audit history should show - at least, the user who changed, what configuration was changed, and when the change was performed.
Is it possible to acheive this on IIQ?
I do not want to track aggregation or updates to accounts etc. Only application config specific changes need to be tracked.
You can enable Class Action audits for the Application class via Global Settings > Audit Configuration > Class Actions > Application and you can enable it for Create, Update and Delete operations. To be clear, the audit event will not include the exact configuration that was changed, it will just give you the user that performed the change and the time. If you need to track configuration changes at a “what configuration was changed” level, you need to ensure that changes are checked into source control (like Git) first and then pushed out to the IIQ operating environment. This is a best practice since you’ll easily be able to revert and review history on the specific changes and why they were done. Restrict the ability to make changes in the IIQ GUI to only trusted team members that will ensure any changes they make in the GUI is checked into source control.
You can do that via navigation to Gear Icon — Global Settings — Audit Configuration page.
Check for various tabs in that page and based on your requirement enable the audit for the required operations.
The part that What changed cannot be tracked from SailPoint itself makes it an incomplete solution. But yes, this can be acheived via Git source control.
Also the audit entries cannot be restricted to config changes alone. Audit entries are also made when a scheduled task triggers. For critical applications with frequent imports it makes 10+ entries every day. I understand this can be filtered and exported into a report, but tracking all these non-config changes also could have performance impacts.
You can follow the suggestion from Pradeep. Another way is to write a custom plugin which plugsin to the save button on the debug page to capture the diff. But this only captures the changes made via debug. A similar functionality can be used on the save button for the applications, but that will be more different than that of the debug page.
Even that wouldn’t cover the UI import functionality. Unfortunately that’s the best we have with the system.