At some point in time you might observe duplicates of email tokens that are not associated with the same incident (case) in your CRM environment. Analyzing the data in those records will not lead to any pattern, and it will seem like the creation of this tokens is completely random.
One cause discovered recently relates to processes. if you have a process that acknowledges the receipt of emails from customers for example, depending on the volume of communication, you will observe that this will occur at relatively even intervals (assuming a relatively even flow of incoming messages from customers).
Analyzing the settings of how these tokens are created, we will find the following section:
This is Settings > Administration > System Settings. On the E-mail tab, you can enable token tracking and configure how these tokens are being generated.
Observe that by default, the token has the format CRM: followed by 3 digits for the user and 3 digits for the message counter.
A process running in the same user context will always have the same 3 digits identical for the user numbers, and will increment the message counter on every run. Once you loop past 999 (the 3 digits), the counter resets and starts again from scratch, thus potentially producing duplicates if the incidents are not closed fast enough, or if the process is very intensively used.
You have the option to adjust the two sets of digits, based on your expected usage of the environment. If you have less that 1000 users, based on the number of users, you can reduce the user numbers. This will allow you to save space in the subject line for a longer subject.
The other adjustment is, you can increment the message counter length to allow more space between the creation of duplicates. For example, if you see that the duplication occurs every let’s say two days (basically you send more than 1000 acknowledgments in two days) and you expect to have incidents open in the system for let’s say one year, look at it this way:
1,000 process runs every two days –> 1,000,000 every 400 days
that puts you just past the year. Consequently the message counter should be incremented to 7 to cover you for a whole year.
Of course, go back from there and look at the service level agreement, and go only as far as an incident is allowed to remain open in the system. Leave some buffer time also.