IIQ synchronization attribute always updating the email in SuccessFactors

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

8.4p2

Please share any images or screenshots, if relevant. Identity Mapping for Email.

image
image1287Ă—822 86.1 KB

Please share any other relevant files that may be required: IdentityAttributeTarget rule

image
image684Ă—522 80.2 KB

Share all details about your problem, including any error messages you may have received.

The customer reported that they are using an IIQ identityAttributeTarget rule to update the Email attribute in SuccessFactors during an identity refresh using the Synchronize Attribute option. They discovered that IIQ continues to update the Email attribute in SuccessFactors even when there is no change to the identity’s email value in IIQ.

The customer would like the synchronization to update the email in SuccessFactors only when there is a delta change in IIQ. They are asking whether IIQ is behaving as expected, and how to have IIQ sends the update only if the identity’s email is changed in IIQ.

Any pointer and suggestion are appreciated.

2

To confirm, when IIQ continues to update the email in SuccessFactors, is the identity email the same as the value in Success Factors? Or email was natively changed in Success Factors so it’s not in sync with the identity email

3

Hi,
The easiest fix would be you update the identityAttribute Target rule, where you basically get the identity current email, and the account currents email from the link, and then only return the value if there’s change, else return null.

try this solution and let me know, if it works

4

Hi @jxu1

IN your transformational rule of attribute Sync, write a logic such that if value is same then return null otherwise return the value.

Use this logic:

String returnValue = null;

if (link != null) {

    String identityEmail = identity.getEmail();
    String targetEmail = (String) link.getAttribute("email");

    if (identityEmail != null && !identityEmail.equals(targetEmail)) {
        returnValue = identityEmail;  // Only send if different
        logger.trace("Email changed. Sending update to SuccessFactors.");
    } else {
        logger.trace("No email change detected. Skipping update.");
        return null;  // Returning null prevents update
    }
}

return returnValue;
5

@jxu1 Returning null may pass the value without transformation or will try to set null value (as per the documentation: “The transformed value will be pushed to the target. If null is returned, then null will be pushed to the target.”). Please check if there is a mismatch of value between Successfactor vs what you have in IIQ. Also, if IIQ is actually updating or it is filtering out.

Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(:heart:, :+1:, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

6

Hi @jxu1, this should be handled as follows: I assure you there are differences between the identity email value and the email value available at the link level, such as extra spaces. Please trim, or if some domain changes, construct to match the target before returning

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory; 

  Log logger = LogFactory.getLog("");

  String returnValue = null;
  try { 
    
    if(null != value && value.trim().length() > 0) {
      returnValue = value;
    }

  } catch(Exception e) {
    logger.error("Rule Name || Error occured while transforming value for " + sourceIdentityAttributeName + " --> " + e.getMessage());
  }
  logger.debug("Rule Name || Return Value for " + sourceIdentityAttributeName + " --> " + returnValue);
  return returnValue;

Let me know how it worked.

@SivaLankapalli

1 Like
7

Hi Robert,

Yes, both are the same. The email in SF is updated by IIQ and SF does not change it. Customer runs SF aggregation daily and AD account aggregation daily too. Then identity refresh task with Synchronize Attribute option is executed.

8

Hi Naveen,

That is what we have tried with no luck. We compared the IIQ email to SuccessFactors link email if they are different. For the same email to IIQ and SF, we tried to send SF email back to SF but IIQ does not filter it out. The transaction log showed the email sent to SF and the same email updated in SF. We even tried to use the email within the triggerSanpshot to send back with no luck.

9

Hey Manish,

We used very similar transformation rule like yours. When IIQ returns null value to SF, it raised lots of “Failed” errors that make the customer concerns. I wonder if that is IIQ default behavior and if it does, I then let them know.

image
image250Ă—396 5.83 KB

10

If it is not being filtered on provisioning, that would imply that there is a difference even if minimal

Have you confirmed the typing and case are the same for both the identity attribute and target attribute? I’ve seen issues before where the application expects a single member list, and the identity attribute is a string (as an example) causing that daily provisioning request to occur

11

Hi @SivaLankapalli,

Here is the rule we use for Production.

import sailpoint.object.Identity;
import sailpoint.object.Link;
import altria.iiq.AltriaConstants;
import altria.iiq.ActiveDirectoryLibrary;
import altria.iiq.ALCSUtil;
import sailpoint.tools.Util;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

Logger logger = LoggerFactory.getLogger("ALCS.Attribute.Sync");    
logger.trace("START Sync Email");

String returnValue = null;
   
// get Identity's email
String identityEmail = identity.getEmail();
if (Util.isNotNullOrEmpty(identityEmail)) {
  identityEmail = identityEmail.trim();
}

if(null != link && void != link) {
  // Get PrimayEmailAddress from the link
  String linkEmail = (String) link.getAttribute(AltriaConstants.SF_EC_ATTR_PRIMARY_EMAIL_ADDRESS);
  if (linkEmail != null) {
      linkEmail = linkEmail.trim();
  }

  // Null-safe comparison
  if (!Util.nullSafeEq(identityEmail, linkEmail)) {
      logger.trace("Email matches for identity {} (identityEmail={}, linkEmail={})", identity.getName(), identityEmail, linkEmail);
      
      // Update email stored on identity to SuccessFactors PrimaryEmailAddress
      returnValue = identityEmail;       
      logger.trace("Using identity Email: {}", returnValue);
  }
}

logger.trace("END Sync PrimaryEmailAddress to SuccessFactors: {}", returnValue);
return returnValue;

I am going to run your rule in QA if it resolves the issue. Thanks!

12

Hi @neel193 ,

The returning Null value tries to set null in SF, and SF says the value cannot be null or empty. Thanks.

13

Hi @robert-hails ,

The rule used in PROD attached. The space is trimmed before the comparison. The case is sensitive and treated as the change. However, customer reported the email updated without a change. Very odd. Thanks.

14

@jxu1 I tested this in one of the demo app: PRISM. If values are same, IIQ is not even trying to send. No entry in Provisioning Transaction and no logs. Seems it is specific to SF app.

Could you please also confirm, if the transaction is initiated by Refresh task: Synchronization Attributes or some other options/modules initiated it?

2 Likes
15

Did you try returning the linkattribute instead of null, when there is no change?? If not, can you please try this one ?? It should fix it.

16

@SivaLankapalli,

We tried the provided rule in QA and the issue still appeared.

17

@naveenkumar3,

Yes, we tried to send the link (SF) email back to SF, but that triggered the transaction and the email was not filtered by IIQ.

18

Here is the case reported during the test. In audit log. the source “unknown” says Identity attribute Email changed originally from Active Directory application during attributeSync, and the change provisioned to Employees (SuccessFactors) application by the transformation rule. However the value of ad mail, identity email, and SF primaryemailaddress are identical. We expect IIQ filtered the change but it’s not.

image
image1456Ă—153 59.1 KB

19

If it is continuously happening like this?? can we write a before provisioning rule to strip out, if there are no changes??

20

Hi @jxu1 , I would recommend that you print a plan during the identity refresh in SuccessFactor after providing the rule and see. Share it here so that the issue can be checked in a better way.

Thanks,

@SivaLankapalli