Maintaining Data Ownership for Custom tables

[Gaurav Bajaj]

Data Governance in ServiceNow cover various pillars - data quality, data security, data regulation, data life cycle and many others. I'm going to talk about one of the critical factors today which is data ownership. Data ownership is the cornerstone of strong governance When every dataset has a clear owner, accountability is built into the process. This ensures data remains accurate, well-maintained, and trusted as the foundation for smarter business decisions.

Today, I want to talk about one of scenarios where data maintaining data ownership become even more important which is when we create custom tables(especially when these tables are related to storing foundation data, CMDB data or reference data to support a process)

A few years back, I was working in a large enterprise environment where ServiceNow was used across multiple business units—IT, Operations, HR, cyber security, Risk and others. Each team had their ServiceNow vendors and development team. There was a frequent request to create custom table for their business processes either to store reference data or majorly for new CI types as well.

Problem at that point in time was that there was no central governance around custom tables. Tables were created without tracking accountability and ownership to maintain the data in these tables in long run. This lead to poor data quality, orphan records and  leading to impact on business process itself.

The solution we implemented was simple but powerful—we introduced a Custom Data Dictionary table and made it mandatory that any new custom table be recorded there. The practice was then codified into our design authority reviews and became part of our technical standards across the enterprise. From that point, every custom table had an owner, purpose, and lifecycle management.

Why a Custom Data Dictionary?

ServiceNow already provides a system dictionary for technical metadata, but governance requires business context as well. For example:

• Who owns the data in this table?
• What type of data is stored?
• Where does the data originate from?
• How often should it be audited for quality?

Capturing these details provides transparency and allows administrators and data stewards to apply consistent governance practices.

Designing the “Custom Data Dictionary” Table

You can create a simple custom table called Custom Data Dictionary [u_custom_data_dictionary] with fields like:

Field	Purpose
Table Name	Reference to the custom table being tracked
Business Owner	Person or group responsible for data stewardship
Type of Data Supported	Categorize the data (e.g., transactional, reference, master, configuration)
Source of Data	Where data originates (integration, manual entry, other system)
Audit Frequency	How often data quality checks should be performed
Notes / Purpose	Brief description of why this table exists

Benefits of This Approach

• Improved Data Ownership
  Every custom table is tied to a business owner, ensuring accountability.

• Data Quality & Cleansing
  With audit frequency recorded, teams can schedule regular checks and cleansing activities. We further mapped the audit frequency to data certification process.

• Support for Data Rotation Policies
  Identifying the type and source of data makes it easier to enforce retention and archival strategies.

• Governance Transparency
  The dictionary becomes a one-stop reference for platform admins and governance teams.

• Long-Term Sustainability
  New admins and developers don’t have to guess the purpose of a table—context is documented.

Last thing to remember is that this can only work when this process is embedded as part of technical Governance to ensure that every time a new custom table is to be created, it needs to be recorded in custom data dictionary table.