On Compass there’s this great document specifying some Account Schema best practices.
In particular, it talks about the ‘Account Name’ attribute specification you can apply to an attribute.
Here it specifies that you should not interpret this as an ‘Display Name’ like ‘Remi Tys’ in this case, but as a unique attribute on the source that should not change.
This is also what we have experienced (sometimes painstakingly) ‘out there’ with customers.
Then we move to the documentation.
Here it mentions the ‘Account Name’ attribute as the displayName of the account. (at the bottom where it describes the default correlation fallback mechanism)
Confusing, right?
Then again in the API there is mention of this as ‘displayName’, for instance the ‘Account Response’ of
How should we now interpret this attribute correctly? And how can we avoid future confusion of this attribute? (is the Compass document the source of truth here?)
Maybe this attribute should be renamed to something more logical… or at least referenced and documented in a clear way by the documentation team.
As the author of the Compass article you referenced, and also as a SailPoint resource whom the documentation team sometimes leans upon for these types of clarifications, I’m happy to provide some additional insights into what “good” looks like here while Rachel’s team works on the updates to our official docs.
The backstory which I think is the root of most of your confusion is our usage of the term displayName within our internal code base. As you well know, in the UI, account schemas typically require an Account ID and an Account Name designation. Within our code, these two attributes are referenced as nativeIdentity and displayName, respectively. That is why you see displayName in the API documentation, since the data models correspond to our actual code.
The naming is indeed unfortunate, as it implies a “name” attribute which seemingly should correspond to a “display name”-type mapping against the account data. But as explained in the Compass document, the behavior and usage of this attribute within our identity creation and correlation processes means that it is always safest to treat Account Name (displayName) as a unique identifier.
You lose nothing in terms of functionality by doing this since an identity’s Display Name is always visible to admins and end users, and their accounts are always surfaced in identity or account search results with the identity information linked. What you gain is a safeguard against unintentional correlation, particularly if customers choose to populate missing data with the same static value.
Thanks for the feedback.
Indeed by now I know what’s what and that it’s mostly differences in ‘description’ for the same thing, but it’s difficult to explain something like this to someone new.
Can I ask you a related question?
Since Account ID and Account Name are supposed to be immutable, why do some out-of-the-box connectors choose to use Account IDs and Account Names that can actually change?
A big one is Active Directory for instance, instead of objectGuid the DN is used by default, for SuccessFactors / Workday / … sources it’s the same thing… for Account ID and/or Account Name by default they are configured with attributes that can change.
Was this ‘immutability’ of those attributes not ‘by design’ from the very start of IDN, but became a restriction later on?
That would perhaps explain the discrepancies we see in both documentation and connector features.
