Enforce unique numbering

[Gabor10]

Hello Experts!

I'd like to hear your experience with this topic as the official Workaround provided by ServiceNow seems sub-optimal to say the least.

Even if you try and optimize the provided code (GlideAggreagete, setLimit(), whatever) it is still inefficient to query the whole table on every insert just to fix the duplicate number issue which happens very rarely anyway.

Personally I am thinking about disabling the "Default value" of the "Number" field on "Task" level and create a Before / insert BR to take care of the Number generation on insert:

(function executeRule(current, previous /*null when async*/) {

current.number = getNextObjNumberPadded();

})(current, previous);

This way we would never pass the Number to Client Side and I am speculating this would fix the issue, but can not be sure as it is already impossible to reproduce the issue deliberately. 

How did your organization tackle the issue? What are you experiences? I'd be happy to have a conversation going on the topic.

[Allen Andreas · Accepted solution]

Hi,

I'm unsure the context of why you're reviewing this. Meaning, were you asked to stop duplication and this is your take on it?

With that said, the client side having the number available to it isn't really the reason for duplicates in the system (unless the field was not read-only and then people were entering values manually, using same numbered records -- which out of box, oddly, the number field is not read-only on most tables, but this is easily resolved by making it read-only).

You can easily reproduce the issue...the duplicates would come from scripting or importing records from another instance where those numbers have already been used. That's pretty much 99% of when this happens. You can set the number field to unique (as mentioned in the support article) or...use that business rule script they were talking about.

If you remove the default number being supplied something in the client and proceed with your business rule as you'd like, you can do that, but you'd want to review any scripts and things that may be trying to leverage that number in client side. I've seen use cases where a supplementary field (like a custom number field for integration or something) uses the out of box number field in client side to build the value for this custom field, etc. So you'd just want to view that perhaps as a change request and run it through your process.

I'm unsure if that business rule would catch the XML imports of duplicates, but you could try. Same with scripting and the user uses "setWorkflow(false)". So you can only attempt to mitigate, but again, the default number being available in the client, I don't think it the full-on fix combined with your BR. There'd still need to be some sort of fix script ran, if needed. Which, as you've mentioned, would be rare and most likely happen due to user error, than the system doing it itself.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Gabor10]

Yes, me and my colleagues dislike the official WA, so we are all trying to come up with alternative solutions.

Thank you for your inputs, they are very valuable.

• We've never imported tickets to our production instance, so I'd like to think that it is not the cause of the duplicate numbers. 
• Scripting causes the duplicates, I am also a bit skeptical - could you please elaborate what do you exactly mean by that? 
• We've also made the Number field read-only in the dictionary way-way back, still, duplicate numbers are created occasionally (1 in 20k or something like that)
• Great point about the setWorkflow(false), I did not really think about that one. I would have to check if any of our scripts (that also insert tasks) are using it

Besides these, are there any reason you are confident it's not the Client Side part that is causing the occasional duplicates?

[Allen Andreas]

Hello,

I'll let bullet point 4 of yours cancel out your skepticism of my valuable input that you found in bullet 2, haha, as that is just one way that scripting can do that.

As far as my confidence that it's not the client side part, I don't know what your instance settings are (or really the context here but the little you're revealing as you reply), but if they were default and like everyone else, then I have a high degree of confidence because if that were the case...we'd be having a huge issue on the forums and everyone would be experiencing it. Most don't.

Anyways, there are some system properties you can set to help with numbering and only use a number on insert such as this property: https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/field-administrati... -- the out of box method uses a number upon the record being loaded. Meaning if you have 2 people creating an incident, but they haven't fully saved yet, they're just opening the form and working on it, out of box, person A would "claim" INC00001 and person B would "claim" INC00002, for example. Neither 1 or 2 have been "saved" yet in the system, but the numbers have been claimed. This is a method that helps prevent duplicates and also give the users their "claimed" number ahead of time.

If neither save, and now person C comes along and creates an incident and opens the form, their number would be INC00003 and so on.

INC00001 and INC00002 would never end up existing in your instance as those claimed numbers were never saved, but the padding has moved on.

The point here is that out of box, that's how the client side would handle the numbering. While it does create gaps, and you can change that behavior using the system property I mentioned above (which I believe it what you were wanting to do with your BR possibly, anyway), it prevents those duplicates while still showing the numbers in the client.

So if the field is read-only, then it shouldn't be from the client side.

You'd want to review your duplicates and the audit trail and perhaps track things down and see if it's being created from script, a user, etc.

Please mark reply as Helpful/Correct, if applicable. Thanks!