Is there a table definition in Service Now? Can my analysis approach be improved?

SB87 · ‎01-20-2023

My objective:

To identify tables and fields in Service Now for external reporting purposes, specifically around Incident, Change, Problem, etc. The reporting is to deliver metrics like a SLA's met, SLA's that have breached, how many incidents/change_requests/problems were raised in a given time (I am aware there is reporting in ServiceNow, but this is for the data warehouse reporting).

My questions:

What is the best approach to understand the meaning of a table? For example, I have received answers to one of my other questions where I was provided "tables of interest" relating to change_request. One of these is "task_cmdb_ci_service", another is "task_ci", but I cannot find anywhere that explains the definition/purpose of a table. Is there an easy way to source this information?
How can I identify important tables related to a specific area? For example, for 'incident' I also discovered 'task' which is a base/core table that stores task information. I also discovered 'task_sla' which stores sla information related to a task record. There is also 'incident_sla' which I believe is a database view (i.e. returns task_sla records specific to incident).

These are some of the tables I'm focusing on:

Table Name	Description
alm_asset
change_request
change_task
incident
problem
sc_request
sys_user
task
task_sla

The problem I am encountering, for example, is that I am aware 'change_request' is the main change request table; but also 'change_task' appears to be closely associated and important, as it stores a piece of work related to the change request. For example, there can be tasks to plan the change, implement the change, and test, and review the work.

I can't help but feel slightly overwhelmed and that my approach is flawed. I've looked at the database schema and can identify related tables, but there are so many that I do not feel all are relevant or as important as others.

Any advice, tips, pointers would be hugely appreciated!

Sebas Di Loreto · ‎01-20-2023

@SB87

I understand why you might be so confused with the amount of tables and information but judging to what I read from you, you are getting there and you pretty much have it. The root of you decision must be "what information am I looking for?" and, of course, you have to understand the incident, problem and change management processes in SN.

I can give you a summary of what tables are important for each process since I have dealt with them for years now.

INCIDENT:

incident (of course): stores all the incident fields.
incident_task: only if you decided to use it as part of your process BUT Major Incident Management may use it as well.

CHANGE:

change_request: stores all the change request fields.
change_task: stores all the change task fields.

PROBLEM:

problem: stores all the problem fields.
problem_task: stores all the problem task fields.

COMMON TABLES FOR ALL 3:

task_sla: stores how a certain ticket is performing in regard to a certain sla definition. This could be a big table and usually it would be better to get the specific DB views for each like: incident_sla, change_request_sla, problem_sla.
task_ci (Affected CIs): stores what other CIs, in addition to the main ci (cmdb_ci) on the tickets, are being AFFECTED.
task_cmdb_ci_impacted (Impacted CIs): stores what services are IMPACTED by the situation occurring on the ticket.
metric_instance: stores all the metrics instances that have been triggered by the tickets. This could be a big table and usually it would be better to get the specific DB views for each like: incident_metric, change_request_metric, problem_metric.

If I helped you with your case, please click the Thumb Icon and mark as Correct.

View solution in original post

Sebas Di Loreto · ‎01-20-2023

@SB87

I understand why you might be so confused with the amount of tables and information but judging to what I read from you, you are getting there and you pretty much have it. The root of you decision must be "what information am I looking for?" and, of course, you have to understand the incident, problem and change management processes in SN.

I can give you a summary of what tables are important for each process since I have dealt with them for years now.

INCIDENT:

incident (of course): stores all the incident fields.
incident_task: only if you decided to use it as part of your process BUT Major Incident Management may use it as well.

CHANGE:

change_request: stores all the change request fields.
change_task: stores all the change task fields.

PROBLEM:

problem: stores all the problem fields.
problem_task: stores all the problem task fields.

COMMON TABLES FOR ALL 3:

task_sla: stores how a certain ticket is performing in regard to a certain sla definition. This could be a big table and usually it would be better to get the specific DB views for each like: incident_sla, change_request_sla, problem_sla.
task_ci (Affected CIs): stores what other CIs, in addition to the main ci (cmdb_ci) on the tickets, are being AFFECTED.
task_cmdb_ci_impacted (Impacted CIs): stores what services are IMPACTED by the situation occurring on the ticket.
metric_instance: stores all the metrics instances that have been triggered by the tickets. This could be a big table and usually it would be better to get the specific DB views for each like: incident_metric, change_request_metric, problem_metric.

If I helped you with your case, please click the Thumb Icon and mark as Correct.

SB87 · ‎01-23-2023

Sebastian,

Just a quick thank you for taking the time to provide this information. In fact, this is the second time you have responded to a post of mine and they are always insightful and useful.

A couple of those tables I have yet to look at, so will spend some time analysing. metric_instance sounds interesting and one that might be a great use.

Kind regards,
Sal