Top 10 ServiceNow Tables Every Developer Should Know

[Its_Azar]

 

1. sys_user – The Users Table

This table stores all user records in the system — basically everyone who logs in or interacts with ServiceNow. It includes user details like name, email, roles, department, and manager.
Pro tip: You’ll often use gs.getUser() or GlideRecord queries on sys_user when building user-based logic.

Example:

var user = new GlideRecord('sys_user');
user.addQuery('email', 'LIKE', 'kpmg.com');
user.query();

 

2. Incident – The Core of ITSM

Probably the most famous table in ServiceNow!
Every support issue logged by users is stored here. Understanding its fields like short_description, category, priority, and state is key when you’re automating workflows or creating SLAs.

Tip: Many custom tables extend task, but incident is the most used example of it.

 

3. Task – The Parent of All Work Tables

This is the foundation for many process tables like incident, problem, change_request, and sc_task.
If you understand the task table, you’ll instantly understand how work management flows across modules.

Why it matters:
Business rules or scripts on task can affect all child tables that extend it. Always test carefully!

 

4. Cmdb_ci – The CMDB Base Table

This one powers your Configuration Management Database (CMDB).
All CIs (Configuration Items) — from servers to laptops to apps — start here, and then extend into specific CI tables like cmdb_ci_server, cmdb_ci_appl, etc.

Example: Want all active servers?

var ci = new GlideRecord('cmdb_ci_server');
ci.addQuery('install_status', 1); // Installed
ci.query();

5. sc_request – The Request Table

Every time someone submits a catalog order, a record is created in sc_request.
It represents the entire order, containing one or more Requested Items (RITMs).

Think of it like this:
Request = “Order” → RITM = “Items inside that order.”

 

6. sc_req_item – The Requested Item (RITM)

Each catalog item you submit creates a RITM record.
Most automation and approvals happen here. This table is also extended by catalog tasks (sc_task).

Tip: When building catalog flows or workflows, always reference current.request to link RITMs to their parent requests.

 

7. sc_task – The Catalog Task Table

Once a catalog item (RITM) is created, the system often generates one or more catalog tasks. These tasks go to fulfillment teams.
If you’re customizing approval or fulfillment logic, you’ll work with sc_task a lot.

Example: Auto-close tasks when RITM closes.

 

8. sys_email – The Email Engine

All inbound and outbound emails are logged here.
Whenever you debug notifications or email replies, this is the table to check.

Tip: Look at the type (sent, received) and subject fields for debugging email triggers.

 

9. sys_properties – System Properties Table

This is where you configure system-level settings — like default time zones, feature toggles, or API keys (though sensitive data should go to Credential records).

Tip: You can create custom properties for your scripts and read them using gs.getProperty('property_name').

 

10. sys_audit – Change History Table

If auditing is enabled, this table tracks all changes made to fields.
It’s your go-to for “Who changed this value?” questions.

Example use: Review updates to high-impact fields like assignment group or priority.

 

Bonus: sys_db_object

If you ever forget which tables exist — this table lists every table in your instance!
Perfect for exploring relationships and debugging.

 

Final Thoughts

These 10 tables form the backbone of most ServiceNow implementations.
As you grow in your developer journey, spend time exploring how these tables connect — via reference fields, extensions, and relationships.

Understanding them not only saves time but also helps you write cleaner, more efficient code and design scalable solutions.

If you’re new to ServiceNow, open your instance, explore these tables in the navigator, and use “Show Schema Map” — it’s one of the best ways to learn how ServiceNow’s data model works under the hood.