Share all details about your problem, including any error messages you may have received.
*We’re currently running SailPoint IdentityIQ version 8.3p4, and we’ve noticed an issue with two of our applications — ServiceNow and a Web Services-based connector.
We’re seeing a large number of unnecessary “Modify” provisioning events being generated, even though no actual changes have occurred on the source systems. This seems to be happening even for disabled accounts, and it’s leading to:
Excessive provisioning transaction volume
High memory usage during refresh tasks
SQL tempdb getting filled up
I am looking for feedback from the community:
Has anyone experienced similar behavior with ServiceNow or Web Services apps?
Are there best practices or config recommendations to suppress unnecessary Modify events?
How do you handle provisioning logic for disabled accounts or unchanged attributes during aggregation?
Any thoughts on rule-based approaches (e.g., BeforeProvisioning) to filter out unnecessary plans?
Any insights, lessons learned, or approaches you’ve used would be greatly appreciated!*
sounds like quite unusual behavior.
Would you be able to share some more details like especially the ProvisioningPlan which is generated to see what IIQ is trying to change in the target system.
Once we have this information available we may be able to trace back the reason for the provisioning.
Do you have Attribute Synchronization configured?
Please also share details on this configuration to make sure there’s no conversion (or similar) issue.
Thank you for the prompt response and your guidance.
Could you please advise on the best way to extract the ProvisioningPlan associated with these unexpected Modify transactions? I’d like to capture the right data to share with you for further analysis.
Also, could you help me understand how to check whether Attribute Synchronization is configured for these applications (ServiceNow and Web Services)? I’d like to confirm whether that may be contributing to the behavior.
Looking forward to your suggestions — and appreciate your support on this.
Hi,
I’ve seen this happen a few times and usually the reason is you’re provisioning attributes which are not in the schema of the application. IIQ won’t be able to aggregate these attributes, so it will provision them again each refresh.
regarding the ProvisioningPlan you may set the log level to TRACE on the following class: sailpoint.provisioning.PlanEvaluator
You may want to use DevSAK ( IdentityIQ Developer Swiss Army Knife (DevSAK) - Compass and issue the following command:
setLogLevel sailpoint.provisioning.PlanEvaluator trace
or change the log level in log4j2.properties.
Please kindly note that enabling TRACE on the above mentioned class will cause some significant “noise” within your log file(s).
If possible try to reproduce on DEV/TEST to not bother your production systems.
Also I recommend that you check your Audit Configuration and enable the following events:
Provisision
Provisioning Expansion
Attribute Sync.
Please kindly share the results from AuditLog first and provide some more details regarding the “unnecessary” events.
Also it would be very helpful if you could explain how you discovered them and why you think -based on the information you have- that they are “unnecessary”.
Thanks for the insight — that actually helped connect a few dots.
I checked our provisioning policy and, yes, I can see that the attribute display Name is being provisioned, but it’s not present in the application schema for the ServiceNow connector. That definitely aligns with what you mentioned about IIQ being unable to aggregate such attributes, which likely explains the repeated Modify events.
I’d be keen to know your thoughts on the best way to handle this scenario. Appreciate your advice or any lessons learned from how you’ve handled this in your environment.
I have a few suggestions based on my experience that might help improve system performance:
Ensure that the option “Refresh only identities marked as needing refresh during aggregation” is checked in the refresh task. This setting will limit the refresh to recently modified users only.
Be aware that some web service APIs may not support the PATCH operation, depending on their specific behavior. In this case, consider implementing a custom rule or task to update and call the relevant web service, which will help prevent dangling target mappings.
Make sure that your identity attributes and target attributes are in the same format. Check for any spaces, as these may cause issues with transformed values. It is advisable to use the transformation rule in the target mapping as well.
Review and remove any unnecessary audit captures in your audit configuration or custom audit code.
Validate the refresh threads (maxThreads) to ensure optimal performance. You might also want to consider using partitioning, as some adjustments to the “RequestDefinition” may be necessary for specific processes.
I hope these suggestions help you resolve any system performance issues.