Best Practice - Incident Management - to extend or not to extend and impacts

[JuliaAllenSN]

Questions still often arise around whether the Incident table should be extended to support very high-volume use cases, as well as the potential impact of that decision on the platform’s future state. To address this, the following provides a high-level overview researched from ServiceNow internal knowledge and best practices, outlining:

• when extending the Incident table is not recommended,

• scenarios where extension may be appropriate, and

• the downstream implications of extending it.

This content is intended as a refresher. Many customers are still in the foundational stages of their ServiceNow journey, and that is entirely appropriate. The purpose is to educate, reinforce best practices, and support decisions that minimize technical debt while helping future-proof the instance as it evolves. 

Best Practice: When to NOT extend incident

Generally, the rule of thumb is do not extend the incident table.

The scenarios below outline situations where extending the table is not recommended. In many cases, alternative approaches—such as process refinement, adoption of modern incident management practices, or re-evaluating the underlying use case—provide more effective and sustainable solutions. These options often apply even within large, complex enterprise environments and help avoid unnecessary technical debt or long-term customization overhead.

The following represent the most common drivers behind requests to extend the table, along with guidance on why this approach should be avoided.

Do not extend if:

Situation	Recommendation	Benefit
You need more data on incidents (foundational level still using category / sub-category)	If you only need extra attributes (10 new fields, flags, reference fields, etc.), you should: Add custom fields directly on incident and use UI policies/business rules for select groups to see/use. Do not add to cat/sub-category list. Use related tables (e.g., a 1‑many “details” table referencing incident) if it’s very repeatable child data. Other: explore setting up services	Cleaner reporting and analytics: All incidents stay in one table (incident), so dashboards, MTTR, volume trends, problem candidates, etc. don’t have to stitch together multiple child tables.  You avoid fragmenting categorization, which is called out as key for trend analysis and assignment in the Incident Process Guide Less technical complexity: Custom fields + UI policies/business rules are straightforward to maintain and upgrade.  You avoid duplicating business rules/SLAs/notifications across multiple incident-like tables. Better performance at scale: Staying on the base incident schema avoids extra joins or cross-table aggregation in reports. A separate 1‑many details table for repeatable child data lets you keep the incident row slim, which helps list views and queries. User experience consistency: Analysts always work in the same Incident workspace/form.  Differences are handled by field visibility and form layouts per group, not completely different tables.
What you are truly looking at is not an incident	Review your data and ensure it’s actually an incident (is it broken?) or is it a request and then separate out.	​Process correctness and clarity: standards draw a firm line between incident (unplanned break/fix) and service request (ask for something new) ​Accurate SLAs: Incidents generally have more aggressive SLAs; requests often follow request‑fulfillment SLAs. Mixing them makes both sets of metrics meaningless. ​Better problem/root cause analysis: When only true break/fix events are in Incident, trend analysis and problem management can actually find chronic issues. ​Cleaner user experience in portals: Users can distinguish “report something broken” vs. “request something” flows, which matches Service Catalog and Incident process guidance
You want different lifecycles or SLAs.	If you do not follow standard incident SLA’s, states and reporting extending incident creates confusion – reports like ‘all incidents will start mixing different processes	Meaningful ‘all incidents’ reporting: If every record under incident shares the same notion of priority, state, and SLA policy, reports like “All P1s” or “All open incidents” are comparable.  If you introduce non‑incident processes with different lifecycles under the same table, those reports become misleading. Simpler process governance: When everything under incident obeys that lifecycle, training, audits, and compliance checks are far simpler. Easier automation and routing: Business rules, SLAs, and alerts can assume “if table = incident, treat it this way” without a maze of exceptions for pseudo‑incident types. If another process truly needs different SLAs and states, it deserves its own table/process (Case, Request, custom app, etc.), not a special “kind of incident.”
You are trying to sidestep licensing/entitlements.	As with other tables, new custom tables and some extensions have entitlement implications (see custom table guide); if you are choosing incident as a parent purely for entitlement – that is a red flag.	​Compliance with ServiceNow licensing: The Custom Table Guide and order forms make it clear that new tables and some extensions have explicit entitlements and limits. Using incident as a parent only to dodge custom table counts is a red flag from a licensing and audit perspective. ​Future proofing for refactoring later: If entitlements or counting rules tighten, clever workarounds often become liabilities.  Modeling things correctly now (and sizing App Engine / custom tables appropriately) avoids painful refactors later. ​Better partner and customer trust: When you explain architecture and licensing to a customer, being able to say “we’re aligned to the official Custom Table Guide and not gaming entitlements” builds credibility.

Best Practice: When to extend incident
Architect review and approval required for upgrade manageability and future impact

There are a few exceptions to this rule. Below is when you could extend incident and it is advised for your specific organization, to still have an architectural review and approval for upgrade manageability and future impact

Only extend if:

Situation	Recommendation	Benefit
If it really is a type of incident	The record is still “an unplanned disruption or reduction in service quality” and should obey the same definition and lifecycle as an incident	​Preserves the incident definition and KPIs All records in the child table are still true incidents (unplanned disruption / quality reduction), so: ​Your global incident metrics (volume, MTTR, P1 counts, trends) stay meaningful and comparable. ​You don’t pollute Incident with requests or other work types, which protects DT’s Incident standards and SOPs. ​Problem, change, and supplier processes that rely on incident trends remain valid.
​You want to inherit all incident behavior.	You explicitly want: Same state model, SLAs, assignment patterns, notifications, and reports as normal incidents. To keep it in the same operational and governance flow as other incidents (same SOPs, major incident handling, etc.	​Maximum reuse of the Incident process and configuration Because the child table extends incident, it automatically inherits: ​State model, SLAs, priority logic, assignment patterns, notifications, reports, and integrations. ​That gives you: Less duplicated configuration (you don’t rebuild SLAs, flows, notifications in a separate app). Less risk that this “special incident” drifts away from standard DT Incident policy and tooling. Easier maintenance and upgrades, since most behavior is still governed in one place.
​You need a distinctly different configuration on top.	For example: Very different forms / UI policies. Unique business rules or workflows that would be messy to condition just on a field. Separate security boundaries or reporting slices that are easier with a distinct table.	​Targeted specialization without over‑complicating base Incident ​The child table lets you add only where it’s truly different: Custom forms / UI policies tailored to that incident type. Unique business rules or workflows that would be ugly to express as if team = X and type = Y in base Incident. Separate ACLs or reporting views when you need tighter security/visibility for that incident type. ​You avoid: Turning base Incident into a “Christmas tree” of conditional logic for one team. Creating a completely separate non‑incident process that loses all the benefits from point 2.

Best Practice: Impacts on AI auto‑categorization, routing, reporting, SLAs, or integrations
Architect review and approval required for upgrade manageability and future impact

-------------------------

Downstream Impacts: AI auto‑categorization (Predictive Intelligence)

Predictive Intelligence for Incident Management is trained on incident records and their categorization/assignment patterns

If you keep a single Incident table and add fields / controlled choices:

If you extend or heavily fork Incident (new child table, divergent categories):

More, better training data in one place Auto‑categorization can learn from a consistent category/subcategory scheme and from extra custom fields (e.g., business service, CI) that improve predictions Simpler model configuration One model targeting incident for prediction of category, assignment group, etc., instead of multiple fragmented targets.

Fragmented training data Models trained only on incident won’t “see” data stored in a child table (unless you explicitly configure a separate solution for that table). If child-table records use different category schemes, the model’s suggestions become less reliable or inconsistent across teams. Harder to maintain multiple models You may end up needing separate predictive models per table or per category scheme, which is more work to train, tune, and govern.

-----------------

Downstream Impacts: Routing / assignment

Incident categorization is explicitly used to drive routing/assignment and to establish trends for problem and supplier management

If you stay on base Incident with added fields:

If you extend Incident or diverge the categorization model:

Single source of truth for routing Rules can use standard category/subcategory plus custom fields to target teams, without duplicating logic. AI + rules working together Clean, consistent categorization and impact/urgency/CI data improves both rule‑based and AI‑assisted routing

More complex routing logic Business rules and assignment rules may need duplicates per table or per category schema. Any AI‑assisted routing that assumes “incident + standard categories” needs extra conditions for the child table. Less accurate “pattern‑based” routing When similar issues live in different tables or use different categories, rules based on historical patterns (e.g., “VPN issues → Network group”) are less consistent.

----------------------

Downstream Impacts: Reporting and Analytics

The process guides emphasize that categorization is used to establish incident type/frequency trends, support problem management, and drive SLA/priority decisions

Keeping Incident intact with extra fields / detail tables:

Extending Incident / splitting the data model:

Consistent trend analysis Every incident sits in one logical dataset; you can slice by category, assignment group, business service, or custom team fields. Team‑specific and global reporting both work Teams can use their own custom fields (e.g., u_team_category) for local metrics, while DT can still use standard categories for org‑wide KPIs.

Broken “global” views “All Incidents by Category” now requires combining incident and child tables, often with incompatible category lists. Command Center, DT, and leadership dashboards become harder to interpret (“Why doesn’t Team X’s data show up in global trend reports?”). Harder problem management Problem records that rely on incident categorization and frequency across the estate miss part of the signal.

-------------------------

Downstream Impacts: SLAs and Lifecycle Behavior

Incident SLAs and prioritization are tightly tied to impact, urgency, priority, and state on the Incident table

If you keep a single Incident lifecycle:	If you use different lifecycles or SLAs on a child Incident table:
Predictable SLAs and escalations SLAs can be defined once and conditionally adapted via fields (e.g., different SLAs by business service or team) without duplicating entire tables. Simpler AI/automation for SLA risk prediction Any AI or reporting around “which incidents are at risk of breaching” only needs to look at one table and a predictable set of fields.	Mixed processes under “Incident” “All open incidents breaching SLA” will intermix records that are actually on different SLA policies or states. It becomes unclear what “P1 incident” means if one table’s P1 follows very different rules than another’s. More SLA configuration to maintain Additional tables mean additional SLA definitions, schedules, and conditions to synchronize.

------------------------------

Downstream Impacts: Integrations

Many integrations assume standard Incident APIs and table structure (inbound from monitoring, outbound to reporting/data lakes, bi‑directional with tools like Okta, CMDB‑driven flows, etc.)

If you keep Incident as the single integration surface and just add fields:

If you extend Incident or introduce a non‑standard Incident table:

Integrations continue to work with minimal change Inbound systems don’t need to know about new tables; they can send/receive the same Incident payload with optional extra fields. New fields flow naturally into existing exports Reporting and warehouse jobs that already extract from incident can be updated incrementally to include new fields.

Integration gaps Integrations that create or update incident records will not automatically support your child table or additional lifecycle. Downstream consumers (Snowflake, analytics platforms) may only be extracting from incident, so the extended data is invisible unless every pipeline is updated. Higher regression risk Every schema or process change on Incident or its child table has to be tested against more integrations.

--------------------------

Impacts on AI auto‑categorization, routing, reporting, SLAs, or integrations
Summary

​Customizing within the Incident table (extra fields, UI policies, related detail tables) generally:

• Improves AI auto‑categorization and routing by giving models more consistent, high‑quality data.
• Keeps reporting, SLAs, and SOPs trustworthy, because “incident” still means one well‑defined process.
• Avoids surprises in integrations that expect the standard Incident schema.

​Extending Incident into separate child tables or forking the data model purely for team‑specific categorization does the opposite: it fractures your AI training data, complicates routing, weakens global reporting, and increases integration and SLA complexity.