Share all details about your problem, including any error messages you may have received.
*On IIQ v8.3, for Email identity attribute, the source mapping had 4 different application rules. This is because depending on the employee type, the email had to be fetched from 4 different applications.
Recently one of these rules were modified, and two other rules were removed from the source mapping list from SailPoint UI. Even after these changes, it was noticed that SailPoint was still executing the rules which were removed, and also the old version of the retained rule.
Is it mandatory to restart services after source mapping is updated?
I do not see any relevant documentation which says so. In fact, I do not see any proper documentation of Rules after version 7.2, which is quite outdated now.*
What to do when source mapping rules aren’t taking effect:
Clear Caches within SailPoint IIQ:
Navigate to the Debug page in SailPoint IIQ.
Look for options to “Clear all caches” or “Reset configuration caches.” This is often found under a “Configuration Objects” dropdown or a similar menu. This is the first step and often resolves rule-related caching issues.
After clearing caches, try running an aggregation or a refresh task for the identity attribute to see if the new rules are applied.
Restart the SailPoint IIQ Application Server:
If clearing caches within IIQ doesn’t work, a restart of the application server (e.g., Tomcat) hosting SailPoint IIQ is the most reliable way to ensure all caches are cleared and the latest configurations and rules are loaded. This is often the definitive solution for stubborn caching issues.
Review the Aggregation/Refresh Task:
Ensure that the aggregation task for the application and any subsequent identity refresh tasks are configured to pick up changes. Sometimes, tasks might be configured to only process “needsRefresh” identities or have other filters that prevent them from fully re-evaluating all attributes.
In your specific case, where rules were removed and others modified, the most likely culprit is caching. Clearing the caches within IIQ (via the debug page) or performing a full application server restart should resolve the issue and force SailPoint to load the updated rule definitions.
Yes, after service restart it started to work as needed. But this behavior was a surprise. Will try the other option too to clear cache.
Meanwhile, all application rules are now clubbed into a Global Rule as that was a recommended approach to maintain one single rule. But this seems to be creating more issues. Every identity seems to be getting refreshed when any application aggregation runs and the logs written inside the Global Rule is printed for every identity in the system.
As per SailPoint documentation, Global Rules are executed only when an Identity is Refreshed. But this doesnt seem to be the case.
Hi @karamchandr_wipro
Global Rules run during Identity Refresh tasks, in IdentityIQ the reality is that any authoritative application aggregation triggers a refresh of related identity attributes, which includes executing global rules. This means global rules run much more frequently than just during dedicated refresh jobs—actually, every aggregation acts like a partial identity refresh for affected identities.
So when you combine all application rules into one global rule, it naturally causes the global rule logic to run for every identity with an account on the aggregated application, which can be a lot of identities. That’s why your logs print for every identity during each aggregation, making it feel like the whole system is refreshing constantly.
This is by design: the aggregation engine doesn’t limit global rules to only changed accounts because any account update might affect identity attributes. That’s also why admins see performance impacts and increased logging.
Best approach:
Use global rules when you need consolidated logic across multiple sources, but try to keep the logic efficient and add conditional checks to skip irrelevant identities quickly.
If performance or noise is a problem, consider if some attribute mappings can remain as application-specific rules to reduce the scope.
Always clear caches or restart IIQ after changes to ensure you’re testing the latest rule logic
