accountAttribute transform still retrieving values from older authoritative accounts

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi everyone,

I’m facing an issue with duplicate accounts on my authoritative source (SuccessFactors HRMS) and would like to understand whether this is expected behavior or if I’m missing something.

Scenario

For some identities, there are multiple authoritative accounts:

  • One active account (the newest account)

  • One or more old inactive accounts

The newest account can be identified because it has the highest PersonID value.

The problem is that when the attribute on the newest account is null (for example, Termination Date), SailPoint continues searching the remaining authoritative accounts and retrieves the value from an older inactive account. This results in the identity attribute being populated with data from an account that should no longer be considered.

What I tried

To ensure SailPoint only evaluates the newest account, I updated my accountAttribute transform to sort the accounts by PersonID in descending order and return only the first link.

{
    "identityAttributeName": "endDate",
    "transformDefinition": {
        "type": "reference",
        "attributes": {
            "id": "Custom: Format End Date",
            "input": {
                "type": "accountAttribute",
                "attributes": {
                    "sourceName": "SuccessFactors HRMS",
                    "attributeName": "Termination Date",
                    "accountSortAttribute": "PersonID",
                    "accountSortDescending": true,
                    "accountReturnFirstLink": true,
                    "sourceId": "33asdfsdfsdfhht544a0c53cd5"
                }
            }
        }
    }
}

After making this change, I ran Identity Processing, but SailPoint still retrieves the value from the older account when the attribute on the newest account is null.

Is there a recommended approach to ensure SailPoint always evaluates only the newest authoritative account (highest PersonID) and does not fall back to older inactive accounts?

Any insights or recommendations would be greatly appreciated.

Thank you!

2

Can you try to add - “accountPropertyFilter”: “(== \”\“)”,

3

what it should do?
as we are not filtering by specific attribute value.

4

Hello Ahmed, your thinking is correct. accountReturnFirstLink: true tells ISC to return the value from the first sorted account even if it’s null, instead of falling through to the next account.

If it’s still picking the old inactive account, two things I would check:

  1. Make sure PersonID is actually populated on all duplicate HR accounts in the schema. Also, accountSortAttribute does string-based sorting, not numeric, so “9” would sort above “100” in descending order. If your PersonID values aren’t uniform in length, the sort may not land on the account you expect.
  2. Remove sourceId from your transform. The accountAttribute docs only support sourceName, applicationId, or applicationName as source references. sourceId is not a documented attribute here.

I would also add an accountPropertyFilter to filter out inactive HR records before sorting. That’s more reliable than depending on sort order alone:

{
  "type": "accountAttribute",
  "attributes": {
    "sourceName": "SuccessFactors HRMS",
    "attributeName": "Termination Date",
    "accountSortAttribute": "PersonID",
    "accountSortDescending": true,
    "accountReturnFirstLink": true,
    "accountPropertyFilter": "(workerStatus == \"Active\")"
  }
}

Replace workerStatus with the actual attribute name from your SuccessFactors schema.

And the accountPropertyFilter": "(== \"\")" suggestion from above may not work because the filter needs to evaluate against a real account attribute.

5

Hi @punna0001 , Thanks for your response

I have some questions to understand.

1- what will happen if this user terminated and we use “accountPropertyFilter”: “(workerStatus == \“Active\”)” to get data only from active accounts only ?

2- is there a way to sort with ID in a numeric way ?

6

For point 1, yes, if the user is terminated and workerStatus changes to inactive, an active-only filter would filter out the account that actually has the Termination Date. So I would not use an active-only filter for this attribute. Instead, check if your SuccessFactors schema has something that identifies the latest HR record regardless of status, like a primary record flag, effective date, or last modified date.

For point 2, I do not see a documented option in the accountAttribute transform to force numeric sorting. So I would not depend on PersonID unless the values are fixed length. If you have a date field on the schema (like effective date or last modified), use that instead since date values in ISO format sort correctly as strings.

For both cases, the key part is accountReturnFirstLink: true so ISC returns the value from the selected account even if Termination Date is null, instead of falling back to an older account.

7

what if i have the hire date in Unix timestamp ?

and what will happen if one of the accounts doesn’t have a hire date ?

8

If the hire date is a Unix timestamp, it may work only if the value is consistent on all accounts, same format and same unit. If any account does not have hire date, I would avoid using it for sorting because the missing value behavior is not clearly documented.

Better to use a field that is always populated, like created, effective date, last modified date, or latest record flag. And with accountReturnFirstLink: true, ISC returns from the selected first account even if the value is null. It will not fall back to an older account.

9

Thanks for helping @punna0001