Measure What Matters: Leverage Metric Instance Tables for Smarter ServiceNow Reports

[Ram Krushna Mis]

Tired of building custom tables just for tracking durations or state changes?
Discover how ServiceNow’s out-of-the-box Metric Instance Table can help you report on key process durations and trends without custom development.

Why Metrics Matter in ServiceNow Reporting

In many cases, simple reports are enough — like counting the number of incidents created today. But what if you want to track how long an incident remained unassigned? Or how much time it spent in a certain assignment group?

That's where ServiceNow Metrics come in. Rather than creating a custom business rule or script to track these transitions, the Metric Definition and Metric Instance features offer a declarative, built-in way to gather and report on these data points.

What Are Metric Instances in ServiceNow?

A Metric Instance is a record in the metric_instance table that stores point-in-time or duration-based data about a task (like an Incident or Request).

These are auto-generated based on Metric Definitions — predefined rules that track things like:

• How long a record stayed in a specific state
• Who a task was assigned to, and for how long
• Any calculated metric using a script

Benefits of Using Metric Instance Tables

Here’s why using metric instance tables is a better strategy than building custom logic:

• No custom tables or scripts needed for duration tracking
• Easily reportable via database views or direct queries
• Works natively with Task-based tables (like Incident, Request, Change)
• Automatically updates as data changes
• Integrates into dashboards or KPIs for executive-level visibility

Metric Definition: The Building Block

To track a duration (e.g., “Assigned to Duration”), you create a Metric Definition with:

• Table: The task table (e.g., incident)
• Field: Audited field to monitor (like assigned_to or state)
• Type: Field value duration or Script calculation
• Active: Yes (to enable tracking)

Note: Field must be audited for ServiceNow to track changes.

Behind the Scenes: The metric_instance Table

Once a metric definition is active:

• A metric_instance is created each time a qualifying field change occurs.
• Fields captured include:
• Value: Who or what the field was changed to
• Duration: How long it stayed at that value
• ID: The specific task record it refers to
• Metric Definition: The reference back to the metric rule

Use Case: Track "Assigned To Duration"

Let’s say you want to analyze how long incidents are assigned to individuals:

1. Create a Metric Definition on the incident table
2. Select the assigned_to field
3. Set Type to Field value duration
4. Once enabled, ServiceNow will start capturing time spent per assignee

You can then use this data to:

• Build reports by assignee duration
• Create dashboards for team performance
• Analyze reassignment trends

Reporting Made Easy (Without Custom Tables)

To visualize or analyze metric instances:

• Use Database Views to join metric_instance with the task table (like incident)
• Create custom reports or dashboards on top of this view
• Filter by metric name, assignee, duration, etc.
• Combine with Performance Analytics for advanced KPI tracking

Pro Tips

• Metrics are only captured after the definition is created — they do not backfill. Fix Script can be leveraged for it.
• For CMDB or non-task tables, you’ll need to clone/extend the business rules to enable metrics.
• Avoid using metrics for data you already have in audit logs or can calculate with Performance Analytics Snapshots.

Conclusion

Metric Instance Tables offer a powerful yet underused way to track key process metrics without creating custom logic. They bridge the gap between basic reports and full-blown Performance Analytics — giving you better insights, faster.

If you want to avoid bloated custom tables and maintain performance while still unlocking meaningful operational data — Metric Definitions are the way to go.