Documentation

{{docApp.title}}

{{docApp.description}}

How can we help?

{{docApp.searchError}}
{{product.name}}

Searching in {{docApp.searchFilterBySpecificBookTitle}}

{{docApp.searchResultFilteredItems.length}} results for: {{docApp.currentResultsSearchText}} in {{docApp.searchFilterBySpecificBookTitle}}
Search results have been limited. There are a total of {{docApp.searchResponse.totalResultsAvailable}} matches.

You have an odd number of " characters in your search terms - each one needs closing with a matching " character!

{{docApp.libraryHomeViewProduct.title || docApp.libraryHomeViewProduct.id}}

{{docApp.libraryHomeViewProduct.description}}

  1. {{book.title}}

{{group.title || group.id}}

{{group.description}}

  1. {{book.title}}

{{group.title}}

Request Types

The Request Types make up the key aspect of Service Manager, providing the raising and tracking of different request types to facilitate the management and delivery of your services. Access to the different request types is controlled through each user’s rights and roles within Service Manager.

Incidents

Incidents are used to manage unplanned interruptions or reductions in the quality of an IT service. Hornbill Service Manager allows users with the appropriate roles and rights, to log, view, progress, escalate and resolve Incidents. The Hornbill platform provides a workflow engine that can be configured to support your Incident processes and can automate events such as tasks, timers, notifications, and escalations.

Service Requests

Request fulfillment (or request management) focuses on fulfilling Service Requests, which are often minor (standard) changes (e.g., requests to change a password) or requests for information. The term “standard change” means pre-approved, repeatable, pre-defined, low-risk changes. If the change does not meet these criteria then it is not a standard change and should be defined as a request for change.

Problems

Problems are used to manage the investigation of an issue where the root cause is unknown. Problem records are typically not customer centric, but they can be used to capture the users that are impacted by the problem. Problems can optionally be publish and made available as known issues articles that are available for users. Temporary workarounds can be provided to help users continue with their work.

Known Errors

Known Errors (KEs) are often created from a problem record once the root cause has been found, but a permanent fix is not available. An example of a KE may be to record an error with an existing software package that is waiting for a permanent fix to be released. In some cases, where the software package is no longer being developed, the KE may remain in place until the software is replaced with

Change Requests

Change management aims to ensure that standardized methods and procedures are used for the efficient handling of all changes to your services and environment. Change requests are a way to manage the continual improvement of the services that you provide to users and customers. Change management lets you plan and eliminate risk while providing an audit trail of the changes you make.

Logging a Change

Changes can be raised in a number of different ways. An analyst with a minimum of the Change Management User role can raise a new Change record from the following places:

  • The Request List > Using the Raise Change drop down option next to the Raise New icon
  • Existing Incidents records > Using the Raise Change from the Raise New Linked Request option under the Link Action Bar or Using the Raise Change drop down option next to the Raise New icon
  • Existing Problem records > Using the Raise Change from the Raise New Linked Request option under the Link Action Bar or Using the Raise Change drop down option next to the Raise New icon

Releases

Release Management allows for the planning and release several related changes under a single release record.

In This Document