How to link custom management items to tickets without adding fields to OOTB tables

[M_Tomy]

Dear Experts

We are working to integrate various inquiries, requests, and other ticket management into ServiceNow.
Currently, each department uses its own optimized management system, such as Redmine, Excel, or proprietary ticket management systems.
We are trying to consolidate these into ServiceNow. However, while incorporating departmental requests for this consolidation,
we have encountered suggestions to create custom fields for unique management items that are not appropriate for standard incidents or requests.

For example:

・Linking an accounting code (for reimbursing worker expenses) to incidents
・Creating custom classification codes for incident aggregation (based on each department's local rules)

These requests deviate from standard ITIL-compliant out-of-the-box functionality.
Since all these requests deviate from standard ITIL-compliant out-of-the-box functionality, we prefer not to accommodate them.
How should we handle such custom fields for unique metrics like KPIs or data analysis?
We understand each department's strong desire for control, but customizing out-of-the-box tables falls outside ServiceNow's maintenance scope, so we want to avoid it whenever possible.

Question
We're seeking a viable compromise. Please advise on a concrete mechanism to achieve this.
Ideally, we'd like to accomplish this without adding fields to the out-of-the-box tables (Incident, Request).

Thank you in advance.

[Itallo Brandão]

Hi M_Tomy,

This is a classic architectural dilemma: Standardization vs. Flexibility.

You are correct to be cautious. Over-customizing the core incident table with department-specific fields (like "Accounting Code" or "Cafeteria Menu Item") leads to "Column Sprawl," making the table heavy and harder to manage.

However, since departments need this data for their KPIs, you cannot simply ignore it. Here are the two concrete mechanisms to handle this without adding columns to the core Incident/Request tables.

1. For Requests (Service Catalog): Use "Variables"

For the Request Management side (OOTB table sc_req_item), you never need to add custom columns for data like "Accounting Code."

• Mechanism: Use Catalog Item Variables.

• How: Define "Accounting Code" as a Variable on the specific Catalog Item form.

• Visibility: Use the "Variable Editor" formatter to display these fields on the RITM and TASK forms for agents.

• Reporting: Reporting on variables is supported OOTB via the sc_item_option_mtom table or standard reporting widgets. This keeps the sc_req_item table schema completely clean.

2. For Incidents: The "Sidecar" Table Pattern (Extension Table)

For Incidents, since you cannot use Variables, the cleanest architectural compromise is to create a separate custom table to hold this "local" data and link it back to the Incident.

The Mechanism:

1. Create a Custom Table: e.g., u_incident_departmental_data.

2. Add Fields: Add your custom fields here (e.g., u_accounting_code, u_local_classification, u_kpi_metric).

3. The Link: Create a Reference Field on this new table pointing to incident.

4. UX Implementation:

   • Go to the standard Incident form.

   • Add this new table as a Related List (Tab) at the bottom.

   • Result: The Incident table schema is untouched. The data lives in your custom table.

How to make it user-friendly:

• You can configure the Related List to allow "List Edit" so agents can double-click and add the code without opening a new window.

• Reporting: To report on "Incidents by Accounting Code," you will create a Database View that joins incident and u_incident_departmental_data. This allows you to report as if they were one table.

3. Expert Advice (The "Reality Check")

While the "Sidecar" table (Option 2) meets your requirement of not touching OOTB tables, it introduces Technical Complexity (Database Views for reporting, extra clicks for agents).

ServiceNow Best Practice: Adding custom columns to the Incident table is actually fully supported and does not break upgrades, provided you use the u_ prefix.

• Recommendation: If a field like "Accounting Code" is used by 50% or more of your departments, it is better to add it to the Incident table directly.

• Compromise: If the field is unique to only one specific team (e.g., "HR sub-code"), use the Sidecar Table approach described in #2.
  
  

Hope this helps you find the right balance!

If this response helps you solve the issue, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards, Brandão.

[M_Tomy]

@Itallo Brandão 

Thank you for your reply.

Your response was very helpful.
I would like to share it with our development team.

If you happen to know, could you please clarify one additional point?

If we implement it as described in points 1 or 2, and we perform data analysis on requests or incidents using another SaaS system, would it be possible to integrate the data while linking the custom field data with the ticket information?
We plan to exchange ticket data with the external system via API integration.

Thank you in advance.