Does duplicate interaction numbers matter for records on the interaction table?

jMarshal
Mega Sage
Mega Sage

I have a customization in my instance, so that inbound emails that are targeting the interaction table always create new unassigned records (on that table), regardless if they are forwards, replies, what the subject line is, etc.

...it seems to be working fine, with the exception that I have noticed that sometimes i end up with a duplicate IMS00 number which leads me to believe that "number" is not the primary key on the interaction table...which isn't a problem for us, with how we are using the interaction module...but it is a bit confusing and I am just wondering if there's anything that anyone knows of that could work better.

Right now, what I'm doing is running a before insert BR to remove the Ref:MSG tag from any email with the target table being interaction, I've also got inbound email actions (not flows) that set fields appropriately regardless of inbound email type (3 separate ones for new, reply, forward). The fields they set are "opened for", "short desc" and "work notes"...they also set state to "new" and assigned_to as "".

The reason why I am using a BR to remove the Ref:MSG tag is because I am sending the emails from a client template in agent workspace (have a custom dictionary entry to make that available) and this means there is no "omit watermark" option (as there is on emails from the notification table).

Unfortunately we are stuck using inbound email actions for now and we are trying to avoid using universal request at this time, which is why I'm trying to get this working in the interaction table (previously, we used "new call").

Everything is working, so if the occasional duplicate IMS number ("number" column on interaction table) isn't inherently an issue on the Now Platform, I'm good. These records do have different sysIDs, so I'm thinking everything is fine...but its odd to say the least, IMO.

1 ACCEPTED SOLUTION

Sebastian L
Mega Sage

Numbers are by no means unique by default, but it is possible to "enforce" it. Check out this article: https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/field-administration/concept/c_EnforcingUniqueNumbering.html

 

If you already have a before business rule you could do something similar in the sample business rule and add to your current business rule (remember no .update :D)!  But it will not break anything other than maybe add some confusion if one searches for a number and it appears twice.. but doesn't sound like this is your case! 🙂


Best regards,
Sebastian Laursen

View solution in original post

2 REPLIES 2

Sebastian L
Mega Sage

Numbers are by no means unique by default, but it is possible to "enforce" it. Check out this article: https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/field-administration/concept/c_EnforcingUniqueNumbering.html

 

If you already have a before business rule you could do something similar in the sample business rule and add to your current business rule (remember no .update :D)!  But it will not break anything other than maybe add some confusion if one searches for a number and it appears twice.. but doesn't sound like this is your case! 🙂


Best regards,
Sebastian Laursen

exactly the feedback I was looking for. Thanks Sebastian!