How to set an inherited field unique in child(extened) table without impcting parent table

[JimSWQ]

Hi everyone, I'm trying to enforce uniqueness on a field inherited from a parent table, but only for a specific child table. Since ServiceNow creates database indexes at the parent level, and Dictionary Overrides don't support the 'Unique' attribute, what is the best practice for this? Is a Before Business Rule with a GlideRecord check the standard approach here, or is there a cleaner platform configuration I'm missing? Thanks!

[BillMartin]

@JimSWQ 

In ServiceNow, you can’t enforce a child-only DB unique constraint on an inherited field because the Unique index is created at the dictionary definition level (parent), and dictionary overrides can’t add Unique. So there’s no pure platform config that will give you “unique only for this child” on the inherited column.

The common pattern is either:

1. Before Insert/Before Update BR on the child that queries the child table for duplicates and aborts with an error (standard approach, just guard it to run only when the field changes), or

2. If you want the cleanest and most reliable enforcement, add a child-specific field (e.g., u_child_unique_key) populated from the inherited value, then mark that field as Unique so you get an actual DB constraint at the child level.

If strict uniqueness matters (and you want to avoid concurrency edge cases), option #2 is usually the best long-term approach.

Please mark as helpful and accept as solution if you find the response lucrative.

[Matthew_13]

Hi Friend

 ServiceNow doesn’t give you an out-of-the-box way to say his inherited field must be unique, but only on this one child table. Uniqueness is enforced with database indexes, and those are global by nature. Dictionary Overrides can’t help because they don’t support the unique attribute.

When people need this behavior, there are really only two realistic approaches. If the child table has its own physical table, the cleanest solution is to create a unique database index on the child table for that inherited column. That gives you true uniqueness, avoids race conditions, and doesn’t require scripting.

If that isn’t possible in your case, then yes, a Before Insert / Before Update Business Rule that checks for duplicates on the child table is the normal and accepted approach. It’s very common, it works well for most business scenarios, and it’s exactly what most ServiceNow teams do. The only downside is that it isn’t perfectly safe under heavy concurrent inserts, which is usually not a concern for typical business data.

@JimSWQ - Please mark Accepted Solution and Thumbs Up if you find Helpful!!