Hi @jxu1 - Since you’re using a transformation rule, SailPoint will always evaluate the rule and compare its returned value with the current value on the account attribute. If both values match, the provisioning transaction will be filtered out. If they differ, SailPoint will provision the value returned by the rule. In either case, a provisioning transaction will be generated. Can you please share the screenshot of provisioning transaction?
I’m trying to understand the purpose of this transformation rule. I don’t see a scenario where the email should not be synced. A direct email target mapping should be sufficient in this case.
I also noticed you’re using: identityEmail = identityEmail.trim(); linkEmail = linkEmail.trim();
If either value contains leading or trailing whitespace, SailPoint could detect a difference and trigger provisioning after every refresh.
Additionally, is the SuccessFactors aggregation changing the email value in any way?
@jxu1 Were you able to figure out what is the source of transaction where source is showing “unknown”? You can try handling this in before provisioning rule, to drop the account request if the value is same.
It seemed to be from SF connector, but I could not ensure that. I wonder if the reported issue is the native behavior to SuccessFactors connector (IIQ calling SF via OData API), that the connector would not support the delta change.
IIQ provides a “Case Insensitive” checkbox in the application configuration (under Configuration > Settings). Enabling it forces case-insensitive comparisons for account attribute values.
Is it enabled or not in the success factor application configuration? Can you try enabling that option and see if it helps if you have email addresses in camel case for example.