Metrics in Scoped Apps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2020 09:41 AM
Hello,
I have a table (doesn't extend Task) in a scoped app that has a "State" field which I want to keep track of time of how long a record spends in each of these states. In the ServiceNow documentation for Metric definitions I found the following:
Note: In the base system, metrics are configured to work on the task table only. To apply metrics to cmdb_ci tables, duplicate the metric events business rule that currently runs on the task table for the cmdb_ci table. Without the events created, no metric processing can occur.
However, when I look at the "metric events" business rule in the Task table, I see that it's inserting an event (metric.update) which is in the global scope. When I then look at the Script Action that runs when that event is inserted, I see that it instantiates an object (script include) called "MetricInstance". This script include is also only available in the Global scope, and the table that it writes to (metric_instance) is ALSO only available in the global scope. I know that a "quick" solution would be to make the table and script include public for other scopes to use, but this is not an option in my case.
Any help would be appreciated!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2023 08:38 AM
Hey @Jesper Slot , did you managed to solve this? I have the same requirement and still stuck. I created a global script include to manage the the GlideScriptRecordUtil but still no metrics get created for the definition. If you get your metrics created, can you please share the solutions/steps, please? Thanks!!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2023 11:23 PM - edited 01-26-2023 11:23 PM
Hi Anna, I'm afraid I gave up on this. I hadn't even seen Jace's post here, but looks like he got stuck as well.
It just made me think even more, whether to extend the task table or not.. but when you're this far in the process, it's a bit late to revert. It was just sad that I didn't discover this before.
My workaround was to implement some extra fields. We wanted to make a history on when a state-like field changed state and then ended up creating a date field per state. Not a great solution, although simple solution and in the end, the users were happy 🙂

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-26-2023 08:41 AM
Hi @Adam Stout , echoing to Jace here, can you please share the specific steps taken to get this working, please? Thanks!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-08-2024 07:58 PM
can't get my event to fire, someone help
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-05-2025 03:11 PM
Adding a reply here in case this helps anyone else. Also just wanted to give a shout out to the community members that already put in such great work and helped this community by sharing their findings.
This is what worked for me, to create a metric on a scoped table:
1. The table needs to be audited
2. You need to create a Metric Definition in the same app scope as the table.
3. You need to create a Metric Business Rule in the global scope (clone task's "metric update" business rule just pointing to the correct table)
4. The table needs to be accessible and readable by the global scope even if its in a app scope.
Beyond the metric definition, all other metric stuff should remain in the global scope. That will allow you to avoid all the issues that @Jace Benson ran into.