Need to Number pad based on the parent of extended tables

[Shane J]

SN in their infinite wisdom setup the Certificate Management records using a prefix of TASK.  They all live as extensions of another table, that in turn is an extension of Task.

We are seeing Certificate Mgmt records being created with the same TASK Numbers as pre-existing Catalog Task records.

We've tried a BR (which is running at least) as per Docs:

https://www.servicenow.com/docs/bundle/xanadu-platform-administration/page/administer/field-administ...

but as we have it now, it's just picking the next number in sequence, not the next number unique to the parent Task table.

Is there a mechanism to use 

getNextObjNumberPadded()

against a table other than 'current'?

Or should we be taking an alternate approach?

[jcmings]

I believe you can change the prefix from System Definition > Number Maintenance

[Shane J]

Was hoping to avoid that, simply because these are SN delivered.

[jcmings]

I don't personally use the Certificate Management table, but it doesn't seem intuitive to me that the records have the TASK prefix. Personally, I would change it; if there are any updates to the Certificate Management Number Maintenance record in future hotfixes/upgrades (which is unlikely), they will be flagged for your review during your instance upgrade process.

It won't be super easy to prevent those records from sharing the same number as TASK records. Thinking out loud for a sec -- you'd have to create a custom BR on your Certificate Management table that looks up the TASK record count and picks another number, but this will have no impact on the TASK table itself, meaning you'd have to somehow manipulate the TASK numbering to avoid clashing with your Certificate Management numbering. At that point, you're starting to mess with more and more of the "SN delivered" stuff. 

An alternative solution is to create a custom Number field on the Certificate Management table and then use a custom BR to set the auto-incrementing number, but this leaves you with the extra, unused OOTB number field.

It's okay to tinker with some "SN delivered" configurations, so long as you have a valid business case and are tracking your changes. I think your business case justifies it in this case. Like I mentioned above, any changes you make to OOTB functionality that ServiceNow updates during upgrades will be flagged as a "change to review" during your upgrade process. 

[Shane J]

I can't make these decisions in a vacuum but I get your point.  Will leave this unanswered for a bit just to see if anyone offers up some magic bullet.  😁