Dictionary Override concept
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I have a table that extends another table.
If I create a new field on the child table, I can mark it as mandatory in the dictionary and it works as expected.
But if the field already exists on the parent table, I understand that I cannot modify the parent dictionary directly. In that case, does ServiceNow automatically create a Dictionary Override when I set the field as mandatory on the child table?
Is Dictionary Override the only correct way to change dictionary-level properties for inherited fields?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
no worries
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @shivasaiman
Yes,
Dictionary Override the only correct way to change dictionary-level properties for inherited fields.
For example: Parent field of the incident is inherited from the task table.I make this field as mandatory in incident table, all the remaining child tables(problem,change) and parent table(task) the field will be mandatory.
And, I made the dictionary override on the incident table . It is changed without affecting the other child tables and parent table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
My responses
Does ServiceNow automatically create a Dictionary Override when I set the field as mandatory on the child table -> No
Is Dictionary Override the only correct way to change dictionary-level properties for inherited fields? -> Yes but depends on your requirement. If you want to make mandatory on child, you can create UI policy on child
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @shivasaiman ,
Yes that's the only way which prevent global level config changes due to the extension of tables and for inherited fields.
AND No the servicenow doesn't create a Dictionary Override automatically, servicennow make this changes affecting to the parent table field also means it supports reversing inheritance heirarchy.
If my response helped mark as helpful and accept the solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @shivasaiman
You are correct in your understanding of table inheritance and field properties within ServiceNow. When a field exists on a parent table, its base dictionary definition is shared across all child tables that extend it. Directly modifying this parent dictionary entry to be mandatory would enforce that constraint on the parent table itself and all other child tables, which is typically not the desired outcome.
To address this requirement for a specific child table, you must use a Dictionary Override. ServiceNow does not automatically create a Dictionary Override when you attempt to modify an inherited field's properties directly from the child table's form or list layout configuration. You must explicitly create one.
The Dictionary Override is indeed the designated and correct architectural method for modifying dictionary-level attributes—such as mandatory, read-only, default value, or display—for an inherited field on a specific extended table. It creates a table-specific definition that supersedes the parent's definition for that field, but only within the context of the child table. This ensures that the integrity of the parent table's schema remains intact while providing the necessary flexibility to tailor the data model of the child table to its specific business requirements. Attempting to circumvent this mechanism, for instance with client-side scripts, would be a deviation from best practice, as it would not enforce the mandatory constraint at the database level and could be easily bypassed, leading to data integrity issues.
If my response helped, kindly mark it as helpful. & accept as Solution :)
Warm Regards
Sumit
Technical Consultant
