Reference Tables

Last modified on 2023/05/22 16:41

From : Service Manager versions Oxygen and later

     Open url.png See the reference tables in versions 2016 and earlier

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

Menu access

References > Other references

Characteristics specific to 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.

Best Practice icon.png  To define the share of each cost center, we recommend that you enter a sharing value instead of a percentage. In the event of modifications, such as the deletion of a cost center, you will not be required to recalculate the percentages of all cost centers to ensure that the total is 100%.

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.

     Open url.png  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.

     Open url.png  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.
 Open url.png 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.

Caution: The SLA applicable to a ticket is always the most restrictive one, i.e. the one with the shortest resolution time, of the two SLAs defined respectively for the catalog category and for the SLA by priority.

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.

Caution: In the standard Service Manager configuration, the Main Usages field is not displayed in the Equipment form.

States

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

Caution: In the standard Service Manager configuration, the States field is not displayed in the Location form.

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.

Caution: In the standard Service Manager configuration, the Severity Levels field is not displayed in the ticket.

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. Open url.png See the example.
    • Calculated priority of an incident/request = Impact + Urgency - 1

Best Practice icon.png  To enforce the overloading of the impact at a requalification of an incident/request (via an action transfer), select Administration > Other Parameters in the menu and enable the {SM} Automatically override the urgency and impact at a requalification parameter.

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.

Best Practice icon.png  If several countries / regions / states have the same public holidays, you can create a common list for these item.

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.
     

Best Practice icon.png  The PUE field enables you to quickly identify the most eco-responsible suppliers (Green IT).

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 Red star.png, 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

Best Practice icon.png  

  • To define a continuous working day, you should define only one period.

    example  Mondays to Fridays, 9 am to 6 pm

  • To integrate a lunch break, you should define two periods.

    example  Mondays to Fridays, 9 am to 12 pm and 2 pm to 6 pm

  • For a three 8-hour shift day, you should define three periods.
  • If no IT support is available during one whole day of the week, do not enter any period.

    example  No support on Sundays

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.

Knowledge prerequisites associated with employees and groups.

1. Associate prerequisites with knowledge base entries in the Knowledge Prerequisites tab in the Knowledge form.
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
2. Associate prerequisites with employees in the Knowledge Prerequisites tab in the Employee form.
User Prerequisite
Andrew Smith Payroll
Emily Jones Payroll, Equipment
Lucas Taylor Equipment, Video
Sarah Davis -
3. Associate prerequisites with groups in the Knowledge Prerequisites tab in the Group form.
Group Prerequisite
Oracle DBA Database
Maintenance Equipment, Software, Video
4. When you run a full text search using the keyword, display, in the knowledge base, the results will be as follows:
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.

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.

     Open url.png  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.

     Open url.png  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. Open url.png 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.

Calculation of CI unavailability time.

The IT Department undertakes to ensure an SLA availability target of 95% for the Oracle server during normal service hours from 9 am to 6 pm. The availability of the CI is not ensured after service hours.
  • 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).
         Employee Availability Status - via an action.png

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).
         Employee Availability Status - via an action.png

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.
     

     Open url.png 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

          Open url.png  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. Open url.png 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 Red star.png in forms), the urgency level will automatically be decremented by one. This means that the urgency and the priority level increase by one.

Best Practice icon.png  To enforce the overloading of the urgency at a requalification of an incident/request (via an action transfer), select Administration > Other Parameters in the menu and enable the {SM} Automatically override the urgency and impact at a requalification parameter.

Workflows

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

     Open url.png  See the description.

Tags:
Powered by XWiki © EasyVista 2022