Hello David. @baoussounda approach should cover account creation and aggregation. cloudDelimiter with isMultiValued: true should split the delimited identity value during account creation, while defining the LDAP account attribute as multi-valued in the account schema allows aggregation to store all values as a list.
For change detection:
Native Change Detection compares stored account data with newly aggregated account data, so the identity attribute string is not involved. For native updates, it should work provided Account Updates and that attribute are selected for monitoring.
Attribute Sync is different. cloudDelimiter does not make the identity attribute truly multi-valued, and the official documentation states that multi-valued sync requires custom rules.
A Before Provisioning Rule can add a Set AttributeRequest containing the actual list, but it only runs after a provisioning plan exists. One documented pattern is to use a helper single-valued synced identity attribute with an Identity Attribute Rule to detect the mismatch and trigger provisioning. Dakota’s KB article describes that approach.
Also, compare the LDAP values as sets rather than ordered lists, since LDAP multi-valued attributes do not guarantee value order.