Reference tables contain values for drop-down lists and tree structures.

Notes

• Deleting a reference value:
  • An error message will appear when the reference value is used in Service Manager. In this case, you can not delete the value.
  • System values in tables preloaded when Service Manager was installed cannot be deleted.

Caution

• When you modify a reference value in a reference table, all the records containing this value will automatically be updated.

Best Practice

• You can also load values to the tables by importing data.

Menu access

References > Other references

Characteristics specific to versions 2016 and earlier

• Menu access: Asset Management / Operation / Transition / Extended CMDB / Design / Project / Strategy > References
       See the reference tables in versions 2016 and earlier

Alphabetical order of the reference tables

QuickAccess

Description of reference tables

Capacities

This table groups specific attributes associated with certain items of equipment (e.g. servers, workstations) and configuration items (CIs) used to set threshold values in terms of disk space, memory usage, CPU usage, etc.

Attributes

This table groups specific information for differentiating certain objects with each other: asset, references of catalog, locations, departments, ...

Each attribute is automatically inherited by all new entries associated with a model of asset or a catalog.

Types

This table is used to define the type of asset (i.e. equipment, license, contract), service, configuration item (CIs), release project and standard build based on common attributes.

• The table is managed using a tree structure whose number of grouping levels depends on the level of analysis required.

  example

  • The Equipment type is made up of two sublevels: Computing for IT equipment (workstations, servers, etc.) and General Asset for all other equipment (fax machines, photocopying machines, vehicles, etc.).
  • The Workstations type is made up of two sublevels: Desktops and Laptops.

• The types of assets associated with catalogs are automatically inherited by any new object linked to one of the catalog entries.

Known Error Categories

This table contains different known error categories.

Root Causes

This table contains the different causes of malfunctioning that may cause an incident. The root cause is specified in the intervention summary of a closing action when the meta-status of an incident changes to Completed in the workflow.

Cost Centers

This table groups different meta-departments where costs related to assets such as equipment, licenses or contracts may be charged back based on usage. Cost centers also enable you to monitor the expenses of each department.

• By default:
  • The total charge back amount is inherited from the catalog of the asset.
  • The asset is fully charged back to the department's cost center with which the asset is associated. 

• If several cost centers are included in the charge back, you should add them manually. The share of each cost center will be equal to the sharing value applicable by dividing the sum of all sharing values.

Click to see an example: The total monthly charge back amount of object A is $10,000.

Titles

This table groups the different titles for addressing users.

Life cycles

This table contains the different steps of the life cycle of a workflow. Theses steps enables you to view the series of progress actions for the tickets the workflow is in charge of.

       See the description.

SLAs

This table contains the different SLAs (Service Level Agreement) signed with customers to calculate the target resolution date for an incident, service request, change request, or investment request using its Support start date. SLAs are also used to measure the effectiveness and responsiveness of the IT Department and its service providers.

       See the description.

SLA Priorities

SLAs by priority are defined when you associate an SLA with a priority level. They are applicable to incidents and service requests based on the priority of the ticket.
  See the example.

• The priority of a ticket is calculated using the following formula: Impact + Urgency - 1.
• Default impact and urgency levels are defined for catalog categories. They can be overridden in the ticket. This may modify the SLA by priority of the ticket.
• In order to specify an SLA by priority for service requests, you must first go to Other Parameters and enable the {SM} Use SLAs by Priority for Services parameter.

Currencies

This table contains the different currencies used by the organization in transactions with its suppliers or employees, etc.

Main Usages

This table contains the different uses of equipment, mainly equipment belonging to the Servers type.

• The values shipped with the Service Manager setup are intended to be associated with equipment belonging to the Servers type, such as Applications, Databases, Files, Printing. If required, you can rename them.

States

This table contains the different states of America where the locations and groups of the IT Department are found.

Functions

This table groups different employee functions, generally corresponding to business activities.

Severity Levels

This table contains the different levels of severity for incidents. 

• During the ticket, the severity level is assessed by the Technical Support team based on information provided by users.
• The values shipped with the Service Manager setup are as follows: 1 – High, 2 – Medium, 3 – Low, Major incident.
• The default severity level of an incident is 2 – Medium.
  • You can increase or decrease this value.
  • It is automatically assigned to all new incidents, provided the Other Parameters {SM} Default Severity Level option is enabled.

Impacts

This table contains the different levels of impact for incidents, service requests, change requests, and investment requests, and weighs the technical and human consequences on the overall infrastructure of the organization.

This subjective data is defined in catalogs and can be reassessed by the requestor or Technical Support team when creating the object.

• The smaller the value, the greater its impact and its importance when scheduling the processing of the object.
• Associated with the urgency, the impact is used to define the priority of incidents/requests.  See the example.
  • Calculated priority of an incident/request = Impact + Urgency - 1

Holidays

This table contains the dates of public holidays in all countries / regions / states where the teams in charge of the incidents / requests are required to intervene. Once the holidays have been created, they will be associated with holiday lists.

• Holidays are taken into account when applying SLAs and OLAs/UCs, to determine the speed of intervention of IT Department or external service providers for an incident/request.
• Recurrent box: Used to indicate if the holiday occurs every year, e.g. Christmas. If you tick the box, you should not specify the Year field. If the date changes from year to year, e.g. Thanksgiving, you should tick the box and specify the date every year. The modification will automatically be updated in all associated holiday lists.

Holiday Lists

This table contains the different lists that group public holidays in all countries / regions / states where the teams in charge of the incidents / requests are required to intervene.

• The lists of holidays are taken into account when applying SLAs and OLAs/UCs, to determine the speed of intervention of IT Department or external service providers for an incident/request.

Manufacturers

This table groups together manufacturers of equipment and configuration items (CI) (Is Manufacturer box should be checked) as well as software publishers (Is Publisher box should be checked).

• The checkboxes are not mutually exclusive because a given manufacturer can produce equipment or CIs as well as software.
• Manufacturers can be merged or replaced. All objects from a manufacturer that has been replaced will inherit the new manufacturer.

• PUE (Power Usage Effectiveness): This is the ratio of the total amount of energy used by a data center facility to the energy delivered to IT equipment, e.g. servers, storage, network. This metric is used by Green IT. The ideal PUE ratio is 1. If the ratio is greater than 1, this indicates that energy is being used by various electrical equipment other than the IT equipment deployed by the data center.
   

Critical levels

This table contains different values used to define the importance of an item of equipment and its priority when processing incidents or service requests related to its use. 

• Critical equipment is indicated by one or more stars , based on the critical level, in Equipment forms and tickets. These stars also appear next to the Equipment field in Incident, Service Request and Action forms.
• The critical level will automatically increase the level of urgency of the incident or service request. As such, this will change the priority and may modify the SLA by priority.

Risk Levels

This table contains a range of values used to assess overall project risks. The cost of the project and possible project hazards can be defined in detail in the Project form.

VIP levels

This table contains different values used to define the importance of a given user and the priority when processing incidents or service requests related to this user. 

• The VIP level will automatically increase the level of urgency of the incident or service request. As such, this will change the priority and may modify the SLA by priority.

Origins

This table contains the different methods of reporting an incident, service request, or event to the IT Department. Origins are used for establishing statistics.

• The default origin proposed in input screens can be modified in Other Parameters {SM} Call Origin.
• Certain values are automatically associated with objects and cannot be modified:
  • The origin of incidents and requests entered via the Self Service portal is Self Service.
  • The origin of incidents and requests generated via the Technical Support Agent is Email.
  • The origin of incidents and requests generated by a Web service is WEB Service.
  • The origin of requests entered using the multi-cart wizard is Shopping Cart.

Countries

This table contains the different countries where the organization's sites (locations), suppliers and IT Department groups are found.

Service Hours

This table contains the service hours of different periods for each day of the week:

• Periods during which the IT Department can be reached: service hours defined in SLAs.
• Periods during which internal or external service providers can perform interventions: service hours defined in OLAs/UCs.
• Periods during which CIs (equipment or applications, etc.) are available: service hours defined in SLA availability targets.

Generally, service hours are defined for the normal business hours of a company which can be applied to the majority of SLAs, OLAs/UCs and SLA availability targets. Specific service hours are then defined to manage the exceptions of each SLA, OLA/UC or SLA availability target. 

Knowledge Prerequisites

This table contains different prerequisites that can be associated with knowledge base entries and with groups. The aim is to limit access to certain knowledge articles to users with the necessary prerequisites when a full text search is run.

• Each prerequisite is defined using a keyword.
• One or more prerequisites can be associated with a knowledge base entry in the dedicated tab found in the Knowledge form.
• One or more prerequisites can be associated with a user in the dedicated tabs found in the Employee Directory or Group Directory.
• Members of the group automatically inherit the prerequisites assigned to their group.
• When a full text search is run in the knowledge base:
  • Knowledge base entries without prerequisites can be consulted by all users.
  • Knowledge base entries with prerequisites can only be consulted by users who meet all of the prerequisites.

Click to see an example: Knowledge prerequisites associated with employees and groups.

Priorities

This table contains different values used to define the priority for handling a ticket. This enables the Support team to prioritize interventions for tickets with the same SLA target date.

• The priority of a ticket is calculated using the following formula: Impact + Urgency - 1.
• The VIP level of the recipient and the critical level of the equipment will automatically increase the urgency. As such, this will change the priority and may modify the SLA by priority.
• When a ticket is created, the Service Desk operator can override the urgency and/or impact assigned by default. This may modify the SLA by priority.
   

Questionnaires

Questionnaires are used through workflows. They are referenced in two tables depending on their nature.

• Standard questionnaires.
• Multi-section questionnaires, which are used to spread the questions into several pages.
   

Questions are referenced in a dedicated table.

• You define the properties of questions using the Manage questions wizard.
• Questions can used dynamic values which allow to define dynamic conditions and constraints for questions based on the results of SQL queries.

Depreciation Rules

This table groups different rules on the breakdown of expenses related to the purchase of assets such as equipment, licenses or contracts. Depreciation can be:

• Straight line: The asset is depreciated at a regular rate with a fixed depreciation expense during its entire usage duration. Note: This is the only option managed in Service Manager.
• Declining balance: The asset is depreciated at a declining rate with a higher depreciation expense during the first years of its usage.

Software Detection Rules

This table contains rules for detecting software on workstations using an automatic discovery tool that identifies the presence of executables and components such as registry keys.

       See the description.

Roles

This table contains roles used to indicate the groups and users who are in charge of an action or who are recipients of an email without having to name each of them individually.

       See the description.

Roles (CI)

This table contains roles associated with groups for configuration items (CIs).

SLA Availability Target

This table contains different levels of availability applicable to configuration items (CIs). Signed by the IT Department and customers, these service level agreements specify the availability percentage of a CI for a given period during which users must enjoy full access to the service. The higher the availability level, the longer the service will be available or the shorter its recovery time.  See Availability Management.

Each SLA availability target:

• Takes the normal service hours of the CI into account. CI unavailability time is calculated based on disruption to the service during service hours, and not after service hours.
• Includes an unavailability margin for scheduled tasks such as maintenance as well as for unexpected incidents, e.g. 5% unavailability.

Click to see an example: Calculation of CI unavailability time.

Statuses

This table contains the statuses of incidents, service requests, change requests and investment requests. They are used to monitor the progress of a ticket in a workflow.

• Statuses are subdivisions of meta-statuses, which define the main steps of the life cycle of tickets.

  example  The Processing in Progress meta-status includes the following statuses: Scheduled, Redirected, Escalated, Pending, Reopened

• Meta-statuses are displayed using a dedicated view from the status list.
  • They are defined by EasyVista. You cannot add new ones.
  • The change of a meta-status performs actions in the workflow. These actions are defined by EasyVista.

    example 

    • Applying an end date and stopping the SLA on a ticket when the meta-status changes from Processing in Progress to  Completed
    • Displaying the intervention summary of a closing action when the meta-status of an incident changes to Completed

• Statuses may be defined by each customer, based on its requirements.
  • Each status is associated with a meta-status.
  • Advancing through the steps of a workflow changes the status of a ticket.

Employee Availability Statuses

This table contains the availability statuses for employees.

This information appears as a color code when assigning an action to an employee (choice of Support person).
         

CIs Statuses

This table contains different statuses that can be assigned to configuration items (CIs) using the CI Status: Update wizard. These items of information are used to filter data.

Employee Availability Statuses

This table contains the availability statuses for employees.

This information appears as a color code when assigning an action to an employee (choice of Support person).
         

Knowledge Statuses

This table contains the different statuses that can be assigned to knowledge articles using the Update Status wizard.

List of fields

• Meta Status: Corresponds to a step in the life cycle of a knowledge article that can be:
  • Knowledge Base: Status used to classify items of information (e.g. tips) that are not problems or known errors.
  • Solved. 
• Initial Status: Used to indicate if the status is proposed during the creation of the knowledge article (box is checked) or if it is a status used subsequently in the life cycle (box is not checked).
• Default Status: Used to indicate if the status is the default one assigned during the creation of the knowledge article (box is checked) or not (box is not checked). The default status can subsequently be modified by one of the initial statuses.

List of tabs

• Next Status: You can select the status value for the next status of a knowledge article.
• Groups in Charge: Group of Support persons in charge of assigning a specific status to a knowledge article.

Known Error Statuses

This table contains the different statuses that can be assigned to known errors using the Update Status wizard.

List of fields

• Meta Status: Corresponds to a step in the life cycle of a known error that can be:
  • For Approval: Status where approval is pending, used to defer the publication of the solution
  • Knowledge Base: Status used to classify items of information (e.g. tips) that are not problems or known errors
  • Known Error: Status indicating that a workaround solution exists
  • Problem
  • Solved 
• Initial Status: Used to indicate if the status is proposed during the creation of the known error (box is checked) or if it is a status used subsequently in the life cycle (box is not checked).
• Default Status: Used to indicate if the status is the default one assigned during the creation of the known error (box is checked) or not (box is not checked). The default status can subsequently be modified by one of the initial statuses.

List of tabs

• Next Status: You can select the status value for the next status of a known error.
• Groups in Charge: Group of Support persons in charge of assigning a specific status to a known error.

Equipment Statuses

This table contains the statuses of equipment:

• Installed Asset: Used to indicate if the associated equipment is physically present within the IT infrastructure and available to users (box is checked) or if it is no longer physically present (box is not checked).

  example

  • Equipment belonging to the IT infrastructure  ==> Active, In Repair, In Stock
  • Equipment removed from the IT infrastructure ==> Stolen, Scrap
• In Stock: Used to identify equipment actually present in the IT infrastructure stock (box is checked) or another type of status (box is not checked).

Project Statuses

This table contains different statuses that can be manually assigned to projects.

Release Project Statuses

Statuses indicate the different stages of release projects at a given time. These items of information are used to filter data.

Pipeline Statuses

This table contains different statuses that can be assigned to configuration items (CIs) in the Service Pipeline.

License Schemes

This table groups different methods for managing licenses.

Absence Types

Absence types list all of the reasons why users may be unavailable.

This is used to identify periods in the graphical planning during which a Support person is unable to perform an action.

Agreement Types

This table contains the different agreements signed by the IT Support team.

Definition

• XLA (Experience Level Agreement): These are metrics that focus on end-user perception of the quality of IT support and services. They are used to measure real-time user experience by capturing and quantifying data on user feedback and satisfaction.
   

      See:

• Description of SLAs/OLAs
• Description of XLAs

Acquisition Types

This table contains the different methods of equipment and license acquisition.

Action Types

This table contains the different natures of actions used in a step of workflow, in a task or in a related action.

            See the List of actions types.

• By default, only tasks are displayed using a filter.
• Workflow action types cannot be deleted or added to.
• Each type of action can be charged back to the recipient of the action (definition of hourly and/or fixed costs).
• Hidden in the Action History: Used to indicate if the actions associated with action types are visible in the history of the Action form (box is checked) or not (box is not checked).
  
  

Step Types for Releases

The types of steps list all of the deployment phases for a release project.

Supplier Types

This table groups the different categories of suppliers.

Warranty Types

This table contains the different warranties for equipment.

Blackout Types

This table groups differents natures of events justifying the creation of a blackout period, i.e. a specific periods during which no modifications should be made to configuration items (CIs).

License Types

This table groups different types of licenses associated with software managed in the catalog.

• Box: License that includes media such as CDs or DVDs, manuals and other items.

• CAL (Client Access License): If a server is used, this is the license associated with each workstation/user that authorizes access to the server.

• OEM (Original Equipment Manufacturer): License associated with each software pre-installed on a workstation.

  example  Windows, antivirus

• Package: License associated with a group of software in the same suite.

  example  Pack Office groups Word, Excel, PowerPoint and Access

  • To define a package: Software Catalog > Included Software tab
  • When you generate a license for a package, you automatically generate a license for each software in the package. The number of licenses counted cannot exceed the maximum number of installations authorized for the main license.

• By Core and By CPU: Licenses associated with a server that cover the number of physical cores and/or CPUs using the software. They authorize connection rights to the server regardless of the number of users/workstations accessing it. Note: You can manage server licenses in the equipment inventory by selecting the Processors tab. You can see the association between licenses and processors in the Control of Server Licenses report available in the Reports > Licenses menu.

• SaaS (Software As A Service): License that enables a software to be accessed via a remote application as a service, instead of as a software installed on a workstation.

• Upgrade: License authorizing an earlier version to be upgraded.

• Volume: The license alone, without any media or manual.

Release Project Types

Release project types list all types of changes at the source of each release project by describing the setup of the new project version.

There are generally three release project types:

• Full release: Used for versions distributed with the full release of all validated and distributed components.
• Delta release: Used for partially modified versions requiring delta deployment where only the relevant components are deployed.
• Package release: Used for a group of releases.

Relationship Types

This table contains the different types of relationship between configuration items (CIs) displayed in the CMDB Graph. Note: You should specify if the relationship is blocking or non-blocking in the Impacting CIs and Impacted CIs tabs of each CI form (via the Blocking Component in case of Failure checkbox).

Measurement Units

This table groups different units of measurement for attributes of objects such as assets, incidents, or requests.

Urgencies

This table contains the different levels of urgency to solve incidents, service requests, change requests and investment requests. These levels are evaluated in terms of expected effort and necessary speed.

This subjective data is defined in catalogs and can be reassessed by the requestor or Technical Support team when creating the object.

• The smaller the value, the greater its urgency and its importance when scheduling the processing of the object.
• Urgency and impact are used to determine the priority of the incident/request.  See the example.
  • Calculated priority of an incident/request = Impact + Urgency - 1
  • When the recipient is associated with a VIP level or when the equipment is associated with a critical level (indicated by  in forms), the urgency level will automatically be decremented by one. This means that the urgency and the priority level increase by one.

Workflows

This table contains the different processing for incidents, service requests, change requests, investment requests, and problems that are associated with catalog entries.

       See the description.