Refresh task does not reconcile stale AttributeMetaData when an attribute source is removed/ updated from the Identity Mapping

IdentityIQ (IIQ) IIQ Discussion and Questions
1

It’s IIQ 8.4 and ran into an issue after changing the source of an identity attribute. I’m trying to understand whether this is expected behavior or if there’s a supported way to reconcile the existing AttributeMetaData.

For example, our department identity attribute was originally sourced from Active Directory:department, so identities had metadata like:

<AttributeMetaData attribute="department" source="Active Directory:department"/>

We later removed Active Directory as the source for this attribute and changed the Identity Mapping to use our HR source instead.

After aggregating HR, confirming the HR account is correctly correlated and contains the expected department value, we ran an Identity Refresh with Refresh identity attributes enabled. However, for many identities the department value did not update.

When checking an affected identity in Debug, the old AttributeMetaData is still pointing to Active Directory:department, even though Active Directory is no longer configured as a source for this identity attribute.

What is interesting is that if I manually remove that AttributeMetaData entry from the identity, save it, and run the same Identity Refresh again, the department value updates correctly from HR and new metadata is created for the new source.

It also doesn’t seem completely consistent across the population. Some identities picked up the new source correctly, while others remained tied to the old metadata.

At the moment, the workaround would be to clear the stale AttributeMetaData for the affected attribute in bulk using a rule and then run an Identity Refresh. That works, but it doesn’t feel like an ideal approach when changing a source for a large number of identities.

Is there a supported task option, refresh argument, or configuration that forces IIQ to re-evaluate or rebuild AttributeMetaData when an identity attribute source is changed or removed?

If not, is clearing the metadata through a custom rule the recommended approach, or would this be considered a gap/possible enhancement in the Identity Refresh behavior?

Note: The example (Active Directory:department) is not exact with me, just modified it to keep the post simple

2

You can create a task which does below

  1. Query all active identities.
  2. Remove the stale AttributeMetaData entry.
  3. Save the identity.
  4. Add the identity to a collection.
  5. Pass the collection (or each identity) to Identitizer.
  6. Let Identitizer refresh/recalculate the identities.
  7. Commit the transaction.

Just a note , commit periodically (e.g., every 100-200 identities) to avoid memory issues if there are large number of users.

3

I have run into this before.

Since you already confirmed that removing the AttributeMetaData for the affected attribute and running Refresh Identity Attributes immediately picks up the correct value, I would not spend too much time troubleshooting the new source mapping itself. That is a good indication that you are dealing with stale attribute metadata/state on the Identity.

I don’t know of an OOTB IIQ 8.4 task option that specifically clears or rebuilds AttributeMetaData.

Instead of running a separate cleanup rule and then another Identity Refresh every time, I would use a small custom rule as the preRefreshRule on your regular Refresh All Identities task.

The flow would be:

HR Aggregation
      ↓
Refresh All Identities
      ↓
preRefreshRule
      ↓
Remove AttributeMetaData
for the affected attribute(s)
      ↓
Refresh Identity Attributes
      ↓
IIQ evaluates the configured mapping again
      ↓
Expected value is populated

Keep the cleanup very targeted. For example, if only department is affected, remove metadata only for department rather than clearing all Identity metadata.

Then configure the rule on the Identity Refresh task:

<entry key="preRefreshRule"
       value="Your Attribute Metadata Cleanup Rule"/>

The advantage is that the metadata is removed immediately before IIQ refreshes that same Identity, so you don’t have to maintain a separate cleanup task followed by a refresh task.

I would treat this as a temporary remediation, not something I would leave permanently.

I used this approach in an environment with roughly 400K identities where we were seeing similar stale Identity Attribute behavior. We left the pre-refresh cleanup in place for a few weeks while improving the underlying IIQ maintenance/hygiene.

After things stabilized, we removed the pre-refresh rule during a couple of weekend refresh cycles and monitored the results. Once normal aggregation and Identity Refresh were consistently maintaining the attributes correctly, we removed the rule permanently.

So for your immediate issue, I would recommend:

Targeted metadata cleanup rule → configure it as preRefreshRule → run normal Refresh Identity Attributes → monitor → remove the rule once the environment stabilizes.

I would also investigate what originally caused the Identity state to become stale, because changing the mapping may only have exposed an existing problem rather than caused it.

4

@bilaltahir A related defect was fixed in IIQ 8.5 under IIQTC-626 — it addressed a scenario where identity attribute values were incorrectly handled when the identity no longer had an account for the associated application source-mapping rule. Reference: Source mapping Rule should not remove the value is account is missing - IdentityIQ (IIQ) / IIQ Discussion and Questions - SailPoint Developer Community. Please check if this helps in your case.

Here is a sample preRefreshRule snipped that you can use to clear out specific attribute metadata:

import sailpoint.object.Identity;
import sailpoint.object.AttributeMetaData;
import java.util.Map;

String targetAttribute = "department";

if (identity != null) {
    Map attrMetaMap = identity.getAttributeMetaData();
    if (attrMetaMap != null && attrMetaMap.containsKey(targetAttribute)) {
        attrMetaMap.remove(targetAttribute);
        log.info("Removed stale AttributeMetaData for [" + targetAttribute 
                 + "] on identity: " + identity.getName());
    }
}

save it as a rule and then add the prerefreshrule entry in the task from the debug:
<entry key="preRefreshRule" value="AttributeMetaData Cleanup Rule"/>