Skip to content

Latest commit

 

History

History
54 lines (28 loc) · 4.77 KB

DECISIONLOG.md

File metadata and controls

54 lines (28 loc) · 4.77 KB
Raw

Methodology for Adding Labels for Choice Fields

A choice field is a type of field that allows users to select from a predefined list of options (for example, incident_subcategory and change_request_risk). These options are stored in the sys_choice table, which contains the possible values, labels, and other metadata for the choice field. Each choice field is typically associated with a specific table and column in the database and is used to standardize the input for commonly selected values, such as incident states, categories, or priorities.

Certain choice fields have labels that can depend on the dependent_value field in the sys_choice table. This dependency typically arises when the same choice field can have different labels based on the context in which it is used. Therefore some elements from sys_choice are also joined in on additional fields. Here are some common examples where dependent_value might influence the label:

  • incident_category and incident_subcategory: These fields often depend on each other. For instance, if the incident_category is "Software," the incident_subcategory might have different options compared to when the category is "Hardware." The dependent_value in this case could represent the incident_category and influence the incident_subcategory labels.

Relationships between User, Group, and Role related tables in ServiceNow

The Users table (sys_user) is linked to Roles (sys_user_role) through a many-to-many relationship via the sys_user_has_role table. This intermediary table stores records that connect each User with one or more Roles. When a Role is assigned directly to a User, a corresponding entry is created in the sys_user_has_role table. Conversely, when a Role is removed from a User, the corresponding entry is deleted from the table.

In other words, sys_user stores all user records. sys_user_role stores all roles. These are related via sys_user_has_role, which maps records of users and roles.

Similarly, Groups (sys_user_group) are associated with Users through another many-to-many relationship via the sys_user_grmember table. Each entry in sys_user_grmember stores records connecting each User and specific Group, establishing the group memberships for each User.

In other words, sys_user_group stores all group records. Again, sys_user stores all user records. These are related via sys_user_grmember, which maps records of users and groups.

Relationships between Task, Problem, Incident, and Change Request tables in ServiceNow

Tasks, Problems, Incidents, and Change Requests are related in ServiceNow. To add clarity to the logic in our models, below are summaries of each table and additional information regarding the relationship between the tables.

Tables

Tasks:

  • The base table for various task types, including Incident, Problem, Change Request, and more. Contains common fields and functions as a central point for task management.

Incidents:

  • Extends from Tasks. Represents a reported issue or service disruption. Can be related to Configuration Items (CIs) and assigned to specific groups or individuals.
  • Can be caused by and therefore linked to Problems. It can also be waiting on a Change Request.

Problems:

  • Extends from Tasks. Represents the underlying cause of one or more incidents. Therefore they can be linked to Incidents and may involve a root cause analysis.

Change Requests:

  • Extends from Tasks. Represents a proposed change to the IT infrastructure or services. Can be related to CIs and undergoes an approval process. A Change Request can result from a Problem or Incident.

Table Relationships:

Incidents and Problems are often related to Tasks through a parent-child relationship. An Incident or Problem task can have related sub-tasks. All Incident and Problem tasks exist in the main Task table. An Incident can be caused by more than one Problem, and a Problem can cause more than one Incident. Therefore the relationship is many-to-many.

Change Requests may also have a parent-child relationship with Tasks when tasks are created to implement the changes proposed in the change request.

A Change Request can result from multiple Problems or Incidents. Multiple Change Requests can be created from a Problem or Incident. Therefore the relationship is many-to-many.

You can create a Problem or Change Request from Incident, or, Change Request from Problem, or can create an Incident from Change Request in cases where it is required.

Example Relationship:

  • Suppose a user creates a Incident for an issue and then 100 other users create an Incident with the same issue. You would create a Problem for all the incidents, therefore linking all Incidents to one Problem. Once the problem record is resolved, it will close out all of the incidents as well.