Reference Tables
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, ...
example
- Workstation attributes: Processor, speed, memory, disk size
- Location attributes: Specific working hours, site surface area, headcount
- Department attributes: Specific phone numbers, headcount
Each attribute is automatically inherited by all new entries associated with a model of asset or a catalog.
example When you create an item of equipment using a catalog entry, it automatically inherits the attributes of this reference.
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.
example
- Equipment: Groups equipment based on function: workstations, printers, servers, etc.
- Licenses: Groups licenses based on the type of software covered: CAD, accounting, etc.
- Contracts: Groups contracts based on type: subscription, insurance, maintenance, leasing, etc.
- CI: Groups configuration items based on application type: business, desktop, printer, etc.
- Hardware and Software: Groups release projects based on the type of change.
- 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.
example Equipment incompatibility, user manipulation error, equipment breakdown, virus
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.
- Case 1: Two cost centers CC1 and CC2 enjoy equal usage of object A.
- The amount charged back to each cost center is identical.
- The same sharing value is assigned to both.
Cost center | Sharing value | Share of cost center | Charged back amount |
---|---|---|---|
(= Sharing value / Sum of sharing values) | |||
CC1 |
1 |
1 / 2 = 50% |
50% * 10000 = 5000 |
CC2 |
1 |
1 / 2 = 50% |
50% * 10000 = 5000 |
Sum of sharing values = 2 |
- Case 2: A third cost center CC3 has started usage of object A. In this cost center, there are three times as many users as in the other two cost centers.
- The amount charged back to CC3 must be three times that for the other cost centers.
- You must therefore assign a sharing value that is three times bigger.
Cost center | Sharing value | Share of cost center | Charged back amount |
---|---|---|---|
(= Sharing value / Sum of sharing values) | |||
CC1 |
1 |
1 / 5 = 20% |
20% * 10000 = 2000 |
CC2 |
1 |
1 / 5 = 20% |
20% * 10000 = 2000 |
CC3 |
3 |
3 / 5 = 60% |
60% * 10000 = 6000 |
Sum of sharing values = 5 |
- Case 3: Cost center CC1 no longer uses object A. The charge back amount should therefore be cancelled.
- Cost CCS must be deleted from the cost centers list.
- Charge back amounts will automatically be recalculated. The sharing value of each cost center will not be affected.
Cost center | Sharing value | Share of cost center | Charged back amount |
---|---|---|---|
(= Sharing value / Sum of sharing values) | |||
CC1 |
1 |
1 / 4 = 25% |
25% * 10000 = 2500 |
CC2 |
3 |
3 / 4 = 75% |
75% * 10000 = 7500 |
Sum of sharing values = 4 |
Titles
This table groups the different titles for addressing users.
example Ms., Mr.
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.
example USD, EUR
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.
example Accountant, Buyer, Product Leader
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.
example
- 1 – Low, 2 – Medium, 3 – High
- A software deployment project that is vital to the company will have a higher risk level than a project to upgrade a non-essential application
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.
example Phone, Email, Web service
- 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.
example
- Normal service hours: Mondays to Fridays, 9 am to 6 pm
- Specific service hours: Mondays to Fridays, 9 am to 6 pm, Saturdays, 9 am to 6 pm
==> The specific service hours are associated with the SLA availability target of the Business application CI to ensure availability on Saturdays
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.
Knowledge no. | Title | Prerequisite |
---|---|---|
KB 10 | How to display documents in the print queue | - |
KB 20 | How to display my expense accounts | Payroll |
KB 30 | How to display the properties of my video card | Video, Equipment |
User | Prerequisite |
---|---|
Andrew Smith | Payroll |
Emily Jones | Payroll, Equipment |
Lucas Taylor | Equipment, Video |
Sarah Davis | - |
Group | Prerequisite |
---|---|
Oracle DBA | Database |
Maintenance | Equipment, Software, Video |
User/Group | Visible knowledge base entries |
---|---|
Andrew Smith | KB 10 and KB 20 |
Emily Jones | KB 10 and KB 20 |
Lucas Taylor | KB 10 and KB 30 |
Sarah Davis | KB 10 |
Oracle DBA | KB 10 |
Maintenance | KB 10 and KB 30 |
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.
example An incident related to the Payroll Department printer is reported on the 10th of the month.
- The impact is assessed as important because the Department has only one printer.
- The urgency is assessed as low because the incident does not occur at the end of the month.
- The priority assigned to the incident is therefore low.
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.
- The server is stopped from 5.30 pm to 7 pm. Unavailability time will include the period between 5.30 pm and 6 pm ==> 30 minutes.
- The server is stopped from 11 pm to 12 midnight. As the service disruption did not occur during service hours, unavailability time ==> 0 minutes.
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.
example Away, Available, Unavailable
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.
example You want to display only CIs whose status is Active.
Employee Availability Statuses
This table contains the availability statuses for employees.
example Away, Available, Unavailable
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.
example Conception, Completed, Canceled
Release Project Statuses
Statuses indicate the different stages of release projects at a given time. These items of information are used to filter data.
example You want to display only release projects whose status is In Test.
Pipeline Statuses
This table contains different statuses that can be assigned to configuration items (CIs) in the Service Pipeline.
example Created, Analyzed, Validated
License Schemes
This table groups different methods for managing licenses.
example Number of records, by workstation, by server or by site
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.
example Vacation, meeting or labor compensation holiday
Agreement Types
This table contains the different agreements signed by the IT Support team.
Definition
- SLAs (Service Level Agreement): They are 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.
- OLAs (Operational Level Agreement): They are signed with service providers to calculate their target intervention date using the date on which the action was transferred to them. They are applied to workflow steps.
- UCs (Underpinning Contract): They are OLA agreements signed with external service providers.
- 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:
Acquisition Types
This table contains the different methods of equipment and license acquisition.
example Purchase, Rental, Leasing
Action Types
This table contains the different natures of actions used in a step of workflow, in a task or in a related action.
example Send Notification, Self Help Validation
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.
example The New Common Expenses Software Version project is made up of:
- A migration step.
- An acceptance step.
- A user training step.
- A go live step.
Supplier Types
This table groups the different categories of suppliers.
example Leaser, Software supplier, Hardware supplier
Warranty Types
This table contains the different warranties for equipment.
example On site, Return to workshop
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).
example Quarter-end closing, payroll at the end of each month
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).
example Accessible by, Installed on, Uses
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.