Allow person.accounts.<<systemname>>.attributes to set as person correlation field
complete
R
Rick van den Dijssel
In some cases as example TOPdesk we would like to use the sAMAccountName as correlation field. Because this is generated by a dependend system (AD) we would like to have support for the person.accounts<<systemname>>.attributes to be set as the person correlation field. This way we support values from dependend systems to be used as correlated value.
G
Grady Koopman
complete
Niek de Melker
You know this is already possible right? according the powershell v2 template the value of the fieldmapping is used to correlate in the targetsystem, so you could just map the samaccountname in the fieldmapping and than you have the so desired correlation based on other systems.
The person dropdown isn't required and is ignored in the template, so this already works as proposed...
R
Rick van den Dijssel
Niek de Melker: Certain governance features and the import entitlement functionality depend on your correlation settings. If the person correlation mapping is not configured, these features will not function properly. Therefore, it is crucial to set both the person and user fields. The new functionality enables you to configure properties from another system, preferably a dependent system. Please ensure that the person mapping is not left empty—this is only permitted for backward compatibility purposes.
Niek de Melker
Rick van den Dijssel I see your point. For governance this could be helpful, but it will also require custom fields in a source system if I have to calculate the fieldvalue, to prefix the employeeID with ADM- for admin AD accounts for example. The Governance module could also resolve the FieldValue to do its thing, this way there is no change in the system required and are both options supported.
With the requirement on PersonField you should really update the template, as this ignores the PersonField entirely.
R
Rick van den Dijssel
Niek de Melker: The correlation settings are not only crucial for the Governance module but also for other features. Resolving account field mappings, especially for all users in bulk, is currently not supported. This process requires checking all accounts against all persons, which is a resource-intensive operation that we prefer to avoid unless absolutely necessary. Therefore, we opted for this approach.
If you need to use a field like employeeID with ADM, you should create a custom field.
I agree that the template needs to be updated, and we will make the necessary changes.
Niek de Melker
Rick van den Dijssel Thank you for the reply. It makes sense, but the option to not select person field was confusing.
I will take your responses into account going on from here.
R
Rick van den Dijssel
Niek de Melker The option not to select an person field somewhat of a bug which is used as a feature which we cannot fixed because it will break current implementations. So I get that it was a bit confusing
R
Rick van den Dijssel
in progress