Introduction
A ServiceNow administrator can change one small thing on a form and suddenly spend an hour trying to find out why something else changed. The setting may not even be on the form. ServiceNow keeps a lot of its configuration as records in system tables. Once you know a few of those tables, it becomes much easier to trace what is happening. ServiceNow Training helps beginners understand where configuration records are stored across different ServiceNow tables.
Sys_Dictionary Is A Good Place To Begin
Let us take fields first. ServiceNow stores field information in the sys_dictionary table. This is where you can find details about how a field is defined. The field type, label, length, reference information, default value, and other properties are part of this configuration.
Users may have a custom field on the Incident form. It may appear correct. However, something about it often feels wrong. Maybe it is using the wrong reference table. Maybe its default value is not what you expected. Opening the form designer again may not tell you much. The dictionary record can.
This is something I would check fairly early when troubleshooting a field. People sometimes keep adjusting the form layout when the actual issue is with the field definition itself. It is useful when working with inherited fields. A field visible on the form does not always mean that it was created for that table only.
Look At sys_properties For Stored Values
The sys_properties table is a different kind of configuration area. It stores system properties. These are values that ServiceNow or an application can use to control certain behaviour.
For example, a development team may have a process that uses a particular time limit. Instead of writing that value directly into a script, they can store it as a system property.
Why? Because requirements change. If the business later wants to change the value, an administrator can update the property. Users do not need to change script just because one setting changed.
Users can find ServiceNow-created properties and properties that were added for specific applications or custom solutions. I suggest not changing a property just because its name looks familiar. Some properties often affect wider parts of an instance. Therefore, I suggest users to check what they are used for first.
Business Rules Sit In sys_script
Now consider a different problem. A user updates an incident. The record saves. Something else changes automatically. There may be no obvious setting on the form that explains it.
This is where sys_script becomes important. Business Rules are stored in this table. They run on the server and respond to database operations like inserts and updates.
Suppose a company needs to complete an action when an incident moves to another assignment group. Business Rule watches for that change. It then runs the required server-side logic.
New ServiceNow users may easily miss such configuration. One may be looking at the record while the actual logic runs somewhere behind it. When tracing unexpected record changes, I look at the conditions on the relevant Business Rules before changing the form configuration.
What Happens While The User Is Filling Out A Form?
That points us toward sys_script_client. Client Scripts are stored there. Unlike Business Rules, they run on the client side and can react while a user is working with a form.
Suppose an employee selects “Hardware” as the category for an incident. Another field needs to be cleared or filled automatically. A Client Script responds as soon as the user makes the selection. The timing offers professionals an useful clue.
Suppose a field changes immediately while you fill in the form. In such a case, the Client Script may be involved. In case the change appears only after saving the record, server-side logic is more likely. This rule may not work in every situation. However, it is a practical way to narrow down the search efforts. A ServiceNow Course can explain how tables such as sys_dictionary and sys_script support configuration and troubleshooting.
UI Policies Are Stored In sys_ui_policy
There is another common reason for a field changing on a form: a UI Policy. UI Policies are stored in sys_ui_policy. They are mainly used to make fields mandatory, read-only, or hidden when if they meet certain conditions.
Take a simple request form. A user selects a laptop as the requested item. The form then requires the laptop model. Before that selection, the model field may be optional. A UI Policy can handle that without a Client Script.
This difference is important during troubleshooting. If a field suddenly becomes mandatory, Check the UI Policies. Sometimes a simple configuration leads to such cases.
sys_db_object Tells You About Tables
Fields are only one part of the picture. ServiceNow must keep information about the tables themselves. The sys_db_object table contains that information. This becomes useful when custom applications get involved in business processes.
ServiceNow supports table inheritance. A table can extend another table. It then inherits fields and other characteristics from it.
That explains a common question from people who are new to the platform: “Why is this field available on my Incident form when I cannot find it among the fields created directly for Incident?”
The answer may be the parent table. Understanding this concept makes the process less intimidating.
A Small But Useful Table: sys_dictionary_override
sys_dictionary_override is worth knowing when inherited fields are involved. Suppose a field comes from a parent table. On one child table, the business wants that field to be mandatory. On another child table, it should remain optional.
Changing the original dictionary definition would not be a good idea because the change could affect other tables. A dictionary override allows the child table to have different behaviour. You may not need this table every day. One can join the ServiceNow Admin Course for the best hands-on practice sessions in this field.
Keep These Names Handy
Beginners do not need to memorise every ServiceNow system table. Start with the below ones:
sys_dictionary — field definitions
sys_properties — system properties
sys_script — Business Rules
sys_script_client — Client Scripts
sys_ui_policy — UI Policies
sys_db_object — table information
sys_dictionary_override — overrides for inherited fields
one must understand what type of problem each table represents.
Conclusion
ServiceNow configuration may look scattered at first when one starts working with the platform. It becomes easier once they stop looking only at the visible form. Field definitions may be in sys_dictionary. Server-side changes can come from sys_script. Form behaviour may involve sys_script_client or sys_ui_policy. Table inheritance can lead you to sys_db_object and dictionary overrides. One can join ServiceNow Training in Hyderabad for the best guidance from expert mentors. Knowing the locations gives offers users a better starting point. This makes troubleshooting real ServiceNow instances easier.
