Uh-oh! Someone made the Assignment group field mandatory on the Incident form. Now it's a mandatory field on other forms such as Task, Problem, and Change. As a result, no incident, problem, or change records can be updated without the Assignment group field being filled in. This probably wasn't the intention of the person who made that field mandatory—so why did this happen?
Why modifying a form field can cascade into other forms
To understand why, first you need to know a bit about extended tables and the system dictionary. Extended tables have a parent-child relationship. Examples in the ServiceNow platform include the Incident, Problem, and Change (child) tables, which are extended from the Task (parent) table, as shown below.
A child table inherits the fields of its parent, but it may also contain some fields unique to that child class. Inherited fields are stored in the parent class and shared among the parent table and all child tables extended from that parent. Fields unique to the child class are stored in the child class and aren't shared.
Each record in a child class exists with the same sys_id in both the child class and its parent class, and both are always accessed together as one record by the platform. For example, the two incident records highlighted here exist on both the Task and Incident tables.
Because records in parent and child classes share the same sys_id, any change made to the field value in either shared record would result in the same change being made to the corresponding record in the other table as well as the same record in any tables extended from that parent.
The system dictionary is a table that contains details for each table in the ServiceNow platform and the definition for every column (field) on each table. Users with the admin role can view the dictionary entry for any field by right-clicking the field label on the form and selecting Configure Dictionary:
Here's the dictionary entry for the Assignment group field, accessed from the Incident form. It shows that this field resides on the Task table, and its Mandatory check box is selected. This field was not mandatory in the base system. Someone changed it to mandatory, and by doing so made the field mandatory for the Task table and all tables extended from it. That's why in our example scenario, no incident, problem, or change records could be updated without the Assignment group field being filled in.
Any other changes made in a dictionary entry—for example, editing the Column label, deactivating the field, or defining a default value—would also apply to that field on the parent table and all child tables extended from it.
Best Practices when working with extended tables:
When working with extended tables, be careful about modifying the value or dictionary entry of a shared field.
- If you need to define a field on a child table differently from that field on the parent table, you can define a dictionary override. For example, for a field on the Task table, a dictionary override can change the default value on the Incident table without affecting the default value for that field on the Task table or on other tables extended from the Task table, such as Problem and Change.
- Another option would be to define a new, non-shared field on the child table instead of changing the dictionary entry for the shared field.
Check out our Getting Started with Tables video demo on our NOWSupport YouTube channel:
Then delve into our Product documentation if you need more detailed info:
- System dictionary
- Data dictionary tables
- Modify dictionary entries
- Dictionary overrides
- Add a new field to a table
And speaking of extended tables, check out our post When to Create a New Table Vs. When to Extend to learn how leveraging an existing table may be more efficient than creating a new table
--
Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.
To access all of the blog posts in this series, search for "nowsupport best practices series."
2 Comments
