We’re back this month with another #NOWTipswithAcorio article, this time diving deep into all things tables. The entire ServiceNow platform is built on a relational database, which is a collection of data items organized into tables. Tables allow the data to be reorganized and used throughout the platform…without the need to alter the underlying database.
This is, in fact, what makes ServiceNow an enterprise-wide platform, allowing data to be shared and used by multiple users and interfaces.
Applications that use tables and records to manage data and processes include Incident, Problem, and CMDB.
Since tables can extend other tables, creating parent tables and child tables, it’s important to understand the basic underlying principles of tables. Let’s take it all the way back to the beginning, building a table in ServiceNow, and take it from there.
Back to the Basics – Creating a Table and Adding Attributes
All administrators and application developers in ServiceNow can create custom tables to store application data.
- Navigate to System Definition > Tables.
- Click New and complete the form.
- In the Columns section, use the Table Columns embedded list to add columns to the table.
- In the Controls section, define additional table options
- In the Application Access section, define the scope protection for the table. For more information, see Application access settings
- Click submit. Simple enough, right?
When you create a new custom table, several fields appear in the Table Columns embedded list. For all tables, required system fields are added automatically. You cannot delete or modify these fields.
Taking it up a Notch – Data Dictionary Tables
Now that you are able to create a table, there are hundreds of applications that you might be using it for. Which means that your tables might need to be a little more specific or dynamic. Whether that means creating a schema map for your tables, understanding many-to-many relationships in your table, database views, or data dictionary tables, there are always more things for you to master.
Let’s start with data dictionary tables.
These tables provide data dictionary, data modeling, and entity relationship information:
- Tables [sys_db_object]: Contains a record for each table.
- Dictionary Entries [sys_dictionary]: Contains additional details for each table and the definition for every column on each table. Each row represents either a column on a table or a table.
- Field Labels [sys_documentation]: Contains the human-readable labels and language information.
The Tables [sys_db_object] table contains a record for each table in the database.
Access the Tables list by navigating to System Definition > Tables. Administrators can create a custom table, add or modify columns in a searchable and sortable embedded list, and define the auto-number format.
The Dictionary Entries [sys_dictionary] table, also called the System Dictionary, defines every table and field in the system. It contains information about data type, character limit, default value, dependency, and other attributes of a field.
Access the system dictionary in one of these ways:
- To see the system dictionary list view, navigate to System Definition > Dictionary.
- To view particular dictionary definition, right-click the list header, form header, or field label, and select Configure Dictionary.
Dictionary attributes alter the behavior of the table or element that the dictionary record describes. Administrators can add or modify dictionary attributes.
Adding an Attribute
To add an attribute to a table or field, navigate to the System Dictionary record for the Dictionary entry, and add the attribute to the Attributes field. Attributes are comma-separated; if attributes exist on a dictionary record, add a comma, with no spaces, before adding an attribute.
For an attribute that accepts true/false values:
- To specify a value of true, you can either enter attribute or attribute=true.
- To specify a value of false, you can either ensure that the attribute does not appear or enter attribute=false. To maintain values during upgrades, do not remove an attribute that is on a table by default.
Maintaining Attribute Values for Upgrades
If you remove an attribute that is part of the base system, it is automatically restored during an upgrade. To prevent upgrades from changing the desired behavior of your system, leave the attribute on the table or field, but set its value as desired.
For example, if a field has the attribute knowledge_search=true by default, do not remove the attribute to set it to false. Instead, set it to knowledge_search=false.
One Last Tip from an Expert [plus an entire eBook of tips]
Our expert consultants are constantly talking about tables. In fact, we have entire slack channels dedicated to conversations between them. With all of the tips and tricks floating around, we turned the conversations into a ServiceNow help book, covering workflows, date fields, and (you guessed it) tables. Check out the book now, and preview a tip from an expert below.
“If you add a new State choice for one of your Task-based tables (Customer Service Case, for example), don’t forget that there are business rules and script includes in the platform that controls whether the task is considered Active or Inactive based on its State value.
If not configured correctly, the Active flag can get out of sync with the State field, especially if you are reopening cases or moving from Inactive back to Active States. If you have added a new State choice, create a dictionary override entry for the State field for your table, then override the attributes for the State field on that table and add the “close_states=” attribute. This attribute ensures custom closed states are set to Active = False appropriately.”
Need More ServiceNow Help?
Like most things in life – getting it right matters. More importantly, given the investment of time and resources, your project will need, getting ServiceNow right the first time matters – a lot – to your long-term platform success. So, don’t be afraid to turn to a ServiceNow expert for help.