The uniqueness check rule you’re using only verifies if the email you’re attempting to grant matches any other user’s email ID value on the Entra source.
However, even if ISC finds the email ID to be unique, Entra might still hold the same email ID value in the proxy attribute for another user. Since Entra doesn’t allow multiple users to hold the same proxy/email value, this results in the error you’re seeing.
The right solution for you would be to write a rule to handle the proxy address check too. You will need to mark the proxyaddress value as searchable and then use the attrSearchCountAccounts() function in the rule.
Hi @at2410 and @jesvin90 Obviously you could go down the route of searching proxyAddresses, I would humbly suggest, though, that you may be over-engineering a rare use case, which could be treated as a data anomaly and manually fixed either in source or ISC. For instance, jane.smith@ marries Mr Jones and becomes jane.jones@ keeping jane.smith@ as an alias. You then get a new Jane Smith - does she want to be jane.smith2@ ? Especially if she was senior in the org, she may not want the suffix. Also consider UPN/email mismatches.
Sorry if I misunderstood your suggestion, but I am not sure how it can be fixed manually for each such user and that too during provisioning!
We need to generate a unique email address value for each user before mailbox creation and update it in Entra during provisioning (birthright access). So how do you automate email generation when a matching firstname, lastname combination is hired? HR will just push it and if there is no such rule in ISC then it will fail, so you would go and manually fix all such users in ISC and Entra giving emails what they prefer (you may run out of unique values since matching ones would all prefer the same email)?
Not sure if this is how one would handle attribute uniqueness during provisioning in any implementation and it is definitely not good error handling technique (knowing that it may happen many times because having multiple matching firstname, lastname user in any implementation is not rare occurrence). I would not see this as one-off issue or data anomaly.
Someone marrying and changing names is not a frequent occurrence and request for change of email addresses using their new last name, is something which I feel should be done manually in ISC/Entra subject to availability of that email address value.
Using counters in email addresses to make them unique is something I have done and seen in multiple implementations (in other IDM product implementations too). Not really seen clients complaining or objecting to using digits to make email addresses unique. What they would be most concerned about is a process that is not automated and requiring manual intervention to fix it.
Hi @at2410 - I’m not saying don’t do the uniqueness check against primary email address (and add increments where necessary), just that extending that uniqueness check to aliases may be over-engineering the solution for a rare occurrance which could (should IMHO) be handled with a manual process which better meets business requirements. Like I say, complications come with the fact that it’s a multi-valued attribute with prefixes (from Entra Connector):
Hi Justin - As shared by Anthony - you can look at the OOB username generator - you can also look at creating cloud rule which can cater for customised logic if you want to traverse through any sources along with proxy address etc. -
