Identity Attribute not updating even after refreshing the identity

IdentityIQ (IIQ) IIQ Discussion and Questions
, , , , ,
1

Hi all,

I have encountering an issue where an Identity Attribute is not updating even after refreshing the identity with the refresh identity attributes option checked.

I have the source mapping in place. Am I missing something?

Thanks in advance.

2

Hi @rishavghoshacc ,

Could you please elabarote your issue in more detail.

You are not missing mapping — you are missing aggregation.

3

@sathish3004 Even the aggregation isn’t changing the value

4

could you please share the identity xml and task xml here?

5

@rishavghoshacc You might want to check your mapping and validate if your source app link attribute is getting updated or not. Please share your identity xml for review.

6

@neel193

exportedid.xml (55.4 KB)

7

@santhirajumunganda

exportedid.xml (55.4 KB)

8

which attribute is it?

9
  1. From the identity XML, which attribute is not updating?
  2. Does the account aggregation bring the value into the account in SailPoint? If the account is not updated, the identity may not update.
  3. If the account attribute is updated, did you try a single identity refresh like this: name == "xxxxxx"?
  4. Try this as well: in the identity XML, add the attribute needsRefresh="true" after the password.
10

@robert-hails managerEmail

11

@santhirajumunganda I have tried refreshing the identity with the single refresh task. It still does not work

I have noticed that the source rule is set to the AD app but it reads the identity’s manager and return the manager’s email. Does not make sense to me but this is how it was configured before

12

if you don’t mind, can you delete the manager email attribute from the identity from debug and then refresh the user again, and see if it getting updated with the correct value.

13

based on your explanation and my understanding of the identity XML you shared:
<AttributeMetaData attribute="managerEmail" modified="1761039648791" user="answ"/>
The AttributeMetaData should normally show the source from which the value is coming. However, you mentioned that the source rule is set to the AD application, but in the XML it only shows the modified value. This might indicate an issue with the mapping.

For example, the source should appear like this:
<AttributeMetaData attribute="managerEmail" source="HRFeed:AppRule: Global_Rule_RetrunManager HRFeed$Global_Rule_RetrunManager"/>
Since the source is not showing in the XML for managerEmail, it might be a mapping issue. Could you please check the mapping again and confirm that the source rule is correctly configured?

14

Hi @rishavghoshacc ,

How this identity attribute mapping is configured?

Is modification set to “UntilFeedValueChanges“ ?

15

@rishavghoshacc Please share Identity XML. Go to Debug → Object Type as ObjectConfig → Identity. Please share it for review.

16

Try this — go to Debug → Identity → open that user’s XML, find the <AttributeMetaData attribute="managerEmail"> block and delete it, then save. After that run a single identity refresh with filter name == "username" and Refresh Identity Attributes checked.

That stale metadata is likely what’s blocking the re-evaluation. Once removed, IIQ treats it as a fresh mapping and the rule will fire again.

Also check Debug → ObjectConfig → Identity → managerEmail — if editMode is Permanent, change it to UntilFeedValueChanges, otherwise IIQ won’t overwrite the value even if the rule returns something new.