Skip to main content
Visit Freshworks.com Visit Freshworks

I am curious how others are handling this scenario ---

What do you do when an email address gets reused over time?  For example John Smith joins our company and then leaves in 2021.  Then a different John Smith gets hired in 2023, and we've since deleted his mailbox. In freshservice we already have a John Smith as a requester using the “Email Address” we would assign to the new John Smith (our schema is first_name.last_name@domain.com).

Deactivating the requester when they leave the company would make sense and preserve ticket data but yet that would still prevent us from adding a new requester with the same email address.

Forgetting the user does free us up to use that email address again but then we have ticket data that no longer has the old Requester’s name associated with it but a “Forgotten User” designation.

So I ask again, how are you all handling this situation and what are some best practices based on the fact that email addresses in the real business world do get reused from time to time.

Appreciate any feedback, thank you!

Hi.

This scenario has not happened to us, yet.
Not saying that this is the right or best approach, but, as that old email in FS with ticket history (understanding your keeping that data) needs to be preserved, as it was from a different John Smith, you could change the Email of that requester to, let’s say, John.Smith.OLDID@domain.com, using a Personnel ID that matches the old one.

 

As it will be for historic purposes, the Requester invitation that would be sent to the John.Smith.OLDID@domain.com can be ignored, as it actually won’t be received by no mailboxes.

 

This would keep his old tickets referenced to him, and you will have the John.Smith@domain.com email free to be re-registered as a valid requester.

 

Regards,

As a best practice, you should never re-use a username or individual email address, especially if you’re in any kind of regulated industry, like finance or healthcare.  Auditors in the US like to see that 1:1 relationship between an individual and the actions they perform.  I’m not sure if it’s actually a compliance issue, e.g. Sarbanes-Oxley, but it’s definitely better to use new/fresh/unique accounts.

Since we have no archiving solution in office 365, its easy. We never delete any account. Therefore we never run into this issue.  Seriously though, the challenge would be between an account removed in AD but remnants in corresponding SAAS applications. During our onboarding process I check AD for a duplicate name before creating it but never thought about check FS itself for a conflict.

I would assume I don’t need to check every SAAS app we use since the user must have existing in FS at one time. I would think I need to check FS as well as AD for onboarding now. Unless FS already uses an ObjectID for user accounts and not email as the primary key.  Then it might not matter and FS can have multiples of the same email.  I guess , I need to test this theory.

Since we have no archiving solution in office 365, its easy. We never delete any account. Therefore we never run into this issue.  Seriously though, the challenge would be between an account removed in AD but remnants in corresponding SAAS applications. During our onboarding process I check AD for a duplicate name before creating it but never thought about check FS itself for a conflict.

I would assume I don’t need to check every SAAS app we use since the user must have existing in FS at one time. I would think I need to check FS as well as AD for onboarding now. Unless FS already uses an ObjectID for user accounts and not email as the primary key.  Then it might not matter and FS can have multiples of the same email.  I guess , I need to test this theory.

Hi.

In Neo, email address is a primary key.

 

Reply


Terms of Use