I am seeking guidance on how we can enable users to choose their preferred email address.
For example, the HR source may list a user as Jackson Smith, but the user prefers their email to be jack.smith@domain.com. While predefined logic based on preferred names can generate unique addresses, there are scenarios where this logic cannot produce the user’s actual preference.
Is there a way to let users select their preferred email address — either by presenting them with a list of available options or by providing a free-text field where they can enter their preferred local part (e.g., jack.smith).
Case 1 : Email address generation for new joiner.
Case 2: Post marriage email address change. (Some self service form). In this case old email address should be preserved as alias.
How do you plan to interact with the user before their email is established? I see this less as a SailPoint issue and more as a process refinement for the organization. One option within SailPoint could be to notify the manager when a new user is onboarded, outlining the available options so the manager and user can decide how to proceed. Another possibility is sending a form to the user’s personal email, though that depends on trusting them to provide a valid address. Personally, I would prefer to define clear rules and set the user’s email at the start, rather than collecting individual preferences.
Hi @248048 could you maybe clarify why you say there are scenarios where logic based on preferred names cannot produce the user’s actual preference? I think you could be storing up issues when you give users free rein to generate their own prefix. There are numerous reasons why you would want prefixes to be standardised (agreeing with @nbhansali).
you can try to utilize interactive trigger workflow using forms for user interaction using launchers.However for new user its better to go with a defined logic as new user
We’re working on a use case similar to this and it does pose some definite challenges. I would say the best path would be to have the preferred email address come from your source system. However, in many cases, SailPoint is where the email address is formed, such as in our use case.
What we’ve done:
Create workflow with launcher that presents a form showing the current email address and aliases.
Allow user to add an alias and/or change the primary sendAs
These attributes are stored in a separate delimited file source with accounts correlated to the users, and using firstValid logic, identity attributes pick up either the original email address, or the user provided address. Those identity attributes are synced to the target system.
Challenges: determining uniqueness - workflows are good at for loops, but not good at while loops. We’ve had to test for uniqueness and return an error if not unique, rather than increment a numeric value appended to the selected email to ensure uniqueness.
Perhaps a better approach, if you have the appetite for doing so, would be to create a custom UI or app that would handle the user interface and the logic to ensure the uniqueness. You may still have to store the user provided preference in a separate delimited file source or database of some kind.
Overall, from what I can tell, this is not something that ISC was ever designed to handle, so it’s going to be custom, and anything custom with this level of complexity carries with it the risk of instability and difficulty of maintenance. Proceed with caution.