Forum Discussion
associate an account email with user's role (not user)
In my organization, a user can wear different hats at the same time (e.g. Vice President on Administrative side, and Lieutenant on firefighting side). When acting as VP, he needs to send/receive emails using the VP email address (e.g. mailto:email address removed for privacy reasons), whereas when acting as Lieutenant, he should use that email address (mailto:email address removed for privacy reasons). And all members of our organization have their own individual email addresses (e.g. for above: mailto:email address removed for privacy reasons). Over time, an individual might get promoted on the firematic side or the administrative side and so may use different emails.
Is there a (simple) way to associate an email address with the user's role(s) rather than with a user directly?
This way we could, for example, add or remove that role from a user (e.g. remove lieutenant from their role(s), and add the captain role after a promotion) so that that user automatically gains access to that email address (for company correspondence) AND all emails sent/received from the previous captain (in their position) and remains in that "pseudo-role-account?"
Right now, I've set it up so that everyone has their own email addresses (e.g. mailto:email address removed for privacy reasons) and then add aliases to each as needed (e.g. mailto:email address removed for privacy reasons). Then re-assign these "role-based" aliases as needed (e.g. when folks leave, get promoted). This feels quite cumbersome and inefficient.
Is there a best-practice method for this?
- never mind, found a better (though more complex to implement) solution: m365 dynamic groups.
2 Replies
- frudmanCopper Contributor
whoops... above emails were blanked out.
This is what I meant:
- vice-president (at) example-fd (dot) com (role-based)
- lieutenant (at) example-fd (dot) com (role-based)
- captain (at) example-fd (dot) com (role-based)
- joe.smith (at) example-fd (dot) com (direct to an individual)
- frudmanCopper Contributornever mind, found a better (though more complex to implement) solution: m365 dynamic groups.