Attribute Sync is not filtiring the Account request

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

Version 8.3

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

Hello,

I’m encountering an unexpected behavior with Attribute Synchronization in Sailpoint IIQ. I’m hoping to gain some insights from the community.

Scenario:

I have an Identity Attribute named “FirstName” sourced from the HR system using an Application Rule.

import org.apache.commons.lang3.StringUtils;

String attribute = link.getAttribute("firstname");

attribute = StringUtils.stripAccents(attribute);

return attribute;

This attribute also has a Target Mapping to a web service target application, utilizing a Transformation Rule.

String identityFirstName = identity.getFirstname().toUpperCase(); 
String AbsolutFirstName = link.getAttribute("name");

if (identityFirstName.equalsIgnoreCase(AbsolutFirstName)) { 

    return AbsolutFirstName;
}else {

    return identityFirstName;
}

When running the “Refresh Identity” task with both “Synchronize Attributes” and “Refresh Identity Attributes” enabled, Attribute Sync doesn’t filter update requests for “FirstName” even if the value hasn’t changed since the last agreggation. Other attributes like email and location are filtered correctly.

Additional Details:

The “FirstName” attribute in the identity cube is lowercase, while the linked attribute might be uppercase.
I assumed the Transformation Rule would handle the case sensitivity difference.

Screenshot 2024-06-12 at 15.50.04
Screenshot 2024-06-12 at 15.50.041400×1116 112 KB

Why is Sailpoint IIQ creating a provisioning plan for the “FirstName” attribute when its value hasn’t changed since the last successful provisioning?
Additionally, why is the “FirstName” attribute not being filtered during Attribute Sync, unlike other attributes like email and location?

2

Hello,

Use a refresh with the “Refresh identity attributes” and “Always launch the workflow (even if the usual triggers do not apply)” flags active.

Let me know if the transformed value change as expected.

Regards.

3

@lfmsp Thanks for the suggestion! I appreciate the help.

However, I’m still trying to understand why Attribute Sync isn’t filtering the ‘FirstName’ attribute update request. In my scenario, I’m already using the ‘Attribute Sync’ workflow within the ‘Refresh Identity’ task. Enabling ‘Attribute Synchronization’ is necessary for Attribute Sync to function properly.

I did try running a refresh with the flags you mentioned - ‘Refresh Identity Attributes’ and ‘Always launch the workflow (even if the usual triggers do not apply)’. Unfortunately, the behavior remained the same. The ‘FirstName’ attribute update request is still included in the provisioning plan even though the value hasn’t changed.

4

values should be exactly same ( even the case) then only it will get filtered otherwise it will show as committed .

1 Like
5

That’s where I was curious about the role of transformation rules. I understand they can modify data before provisioning, but wouldn’t that only be necessary if the source data and target system have different formatting requirements (like case sensitivity in our example)?

6

Then what you can do is in transformation rule return the exact same value as available in link object Then that will get filtered .

7

Hi @Moben,

Attribute synchronization is a case sensitive operation. Make sure you either set the same case value when provisioning to the target or handle the case of the value accordingly to match your identity attribute value in the transformation rule or customization rule as part of aggregation.

Regards,
Uday

1 Like
8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.