In this guide we will cover:
– Service Catalogue
– Service Access
– Service Details
– Field List
– Monitored Services (Service Status Monitoring)
– Maintaining your Service Catalogue
– Checking User Access
Admin Guides:
Service Catalogue
The Service Catalogue is a means of providing your end-users with a pre-defined list of more commonly raised services. Services can be grouped by category to keep things tidy and can have access restrictions set as to ensure right users have access to the relevant options.
Users can access the service catalogue by clicking on the "Request something" menu option and a list of services that are available to them will be shown.
Fig 1. Service Catalogue on the Self-Service Portal.
The Service Catalogue works off of a collection of ticket types/templates, as requesting a service is simply a case of raising a ticket of a given type/template.
You can customise your Service Catalogue by heading to the Service Catalogue module within the agent application:
Fig 2. Service Catalogue within the agent application.
The first thing we will do is create a new service category, which can be achieved via hovering over the list on the left hand side and right clicking. The options to "View/Edit this Service Category" and "Create a new Service Category" will then show.
Fig 3. Creating a new Service Category, this is achieved by right clicking on the list of categories (view is set to "Service Catalogue By Category")
We are then presented with a window where we can input a Service Category name, summary, description and set User access restrictions. The "Summary" is the summary text that will appear under the category name in the portal before the category is selected. The "Description" will appear under the category name after this category is selected.
Fig 4. Creating a new service category.
Service Access
User access restrictions for the category can be set under the "User Access" tab when creating/editing the category. User access can also be restricted per service under the "User Access" tab within the service setup.
The "User Access" defines the entity that can access Services within this Category (site, client, organisation etc..). You may well find that you are looking to provide client-specific services – if so, you would want to create a client-specific service category and restrict access here to the client in question.
The "Service Access Level", similar to the "Web Access Level", is an option found on the "Permissions" tab for a user and defines the level of access they have to the Service Catalogue. A user has access to services up to and including the Service Access Level they are given. If inherited from a role and then overridden for the user whichever permission is higher (role or manual override) will take precedence. Options are 1-3, where 2 is the default set for new users and 3 is the highest level of access a user can have.
Fig 5. Service Access Level for a user.
Now we have created our Service Category and set the relevant access restrictions, lets go ahead and create a service to request.
Upon creating a new Service (via the usual method of clicking "New" in the top right) you're first prompted to specify the Service details, including name, category and summary.
Fig 6. Service Details tab.
The next tab along – Configuration – is where we specify the core information around requesting this service. The first section of this tab is your basic settings:
Fig 7. Basic Service Request configuration options
For our example, we are concerned with the second option, "Show in Service Catalogue for End-Users", as this determines whether or not this service will be visible in the Service Catalogue.
Service Details
Beneath these options is our Service Request Details Table.
We have an option to set a ticket type or ticket template to be raised upon requesting this service. There is also the option to have the button go to a URL, so when clicked you will be taken to the specified URL.
Fig 8. Service Request Details options.
Scrolling down here, you can also add "Optional Services". These are additional service tickets that can be logged as child tickets at the same time upon selection, which can be helpful to fulfil related requests together.
Fig 9. Adding optional service items.
You can set these as mandatory, or set rules upon their selection.
Fig 10. Optional Service Items table.
Field List
As I want to provide a form specific to requesting a laptop, the "Laptop Request" ticket type shown and its associated fields will be used to gather all the relevant information from the user.
Fig 11. Laptop Request field list.
After creating this new ticket type, I have specified that this is the ticket type to raise when the "Laptop Request" service is requested. As I want the end-user to input details relevant to this request, I have also enabled the "Show new ticket screen when requesting this service" option.
You'll also find a "User Access" tab on a service, where you can override the access permissions set for the Service Category.
This laptop request will then show in the "Hardware" section of the service catalogue in the end-user portal.
Fig 12. Hardware category in the end-user portal.
Fig 13. Laptop Request form.
The optional services will then show in the next screen, where they can be selected and filled in via the dropdown.
Fig 14. Optional service ticket.
Monitored Services
We have a dedicated guide on monitored services here. But see below for a brief overview.
Services can also be configured as "monitored" services, which will allow for their status to be tracked. This can be a useful way to allow end-users to check in on any planned maintenance or faults regarding a given service you manage. Service Status Monitoring is a full monitoring service within Halo, and allows tracking of full history from your chosen monitoring software.
This works by receiving e-mails from your third party systems, processing those emails to update the Halo service status database, whatever the status of the notification, and track the history of the status of this service.
New requests can be raised when a service fails, where you can track the actions taken to restore the service to operational status. Halo can even generate a ticket if a Service Status email is not received.
The Breakdown of How Halo Processes Service Updates:
- Generic Email Rule – An email rule with type 'Service Status' is matched, so the email can attempt to be matched to a monitored service.
- Match on a Service: Within the Monitoring Configuration tab of the service, you can set the email rule for this service, i.e. match on the Azure service when the body contains the string "Azure". Now at this point Halo has matched to a service.
- Filtering on Statuses: From here the email should contain the a sting to indicate the status is "OK" or "Fault" when matched on the status of the service in Halo is updated.
The definition of a service is quite broad. Examples of Monitored Services:
- A nightly batch job, such as a backup, virus scans, or disc space check.
- A frequently recurring check, such as a check of the status of a network link, or a check that a URL is operational.
- A manual task such as changing of the backup tapes in a server or periodically reviewing the list of valid users.
- Monitoring for warning messages from a third party utility or monitoring system and tracking that actions are taken to respond to the warning.
- Any task or job that you wish to report the success or failure of, and which may form part of your SLA.
Note: You must be on NHServer v13.21 + or the incoming/outgoing services to use service status monitoring via emails.
Maintaining your Service Catalogue
Editing and creating services for your end users is simple.
- Click on an existing service or press new in the top right.
- If editing an existing service, click edit in the top left
- Name and assign the category to the service
- Assign a cost and delivery time if necessary, add a description and summarise the service
- Head to the configuration page
- Adjust the settings as necessary
- Of importance is how the ticket is logged to reference the service request
- You can pick a ticket type to log the service request as or, (if ticket type defaults don't provide enough flexibility) then you can pick a ticket template to use (which includes a ticket type setting)*
- Fill in the remaining tabs including User Access and add any subscribers from here
- Add any related services and assets
- Click Save
Note: Only templates with an ITIL type of "Service Request" will be selectable in the Service Request Details section, and only ITIL types of "Incident" will be selectable in the Incident Details section.
When logging a Service Request with a Ticket Type that includes the cost field, it will default the value of the Cost field to the service cost. Quantity can also be added to the Ticket Type fields to request more than one of the same service at once.
Checking User Access
You can check which users can see what by clicking "View as User" and selecting the relevant user. This enables you to see which services are available to groups of users. Customising the catalogue by client, site or user.
Fig 15. View as User button
