HaloITSM

HaloITSM Guides

Documentation to assist with the setup and configuration of the HaloITSM platform

Guides > The Service Catalogue

The Service Catalogue

Topics Covered In This Lesson

  1. The Service Catalogue
  2. Service Access
  3. Service Details
  4. Field List
  5. Monitored Services(Service Status Monitoring)
  6. Maintaining your Service Catalogue


Associated Admin Guides:

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.

You can access the service catalogue by clicking on the menu option and a full list of services that are available for you will be shown:

Fig 1. The Service Catalogue on the Self-Service Portal


At the heart of the Service Catalogue are 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. The Service Catalogue within the agent application


Lets go ahead and create a new Service Category - Hardware - and associated Service 'Desktop Request'.

The 1st thing we will do is create our Service Category, which can be achieved via hovering over the list on the left hand side & right clicking over this list:

Fig 3. Creating a new Service Category, this is acheived by right clicking on the list of categories (view is set to "Service Catalogue By Category")


Were then presented with a window where we can input a Service Category name & set User access restrictions:

Fig 4. Service Category user access options


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 & including the Service Access Level they are given, if inherited from a role and then overridden for the user whichever permissio is higher (role or manual override) will take precedence. Options are 1-3, where 2 is the default set for new users & 3 is the highest level of access a user can have. The "Inherit from Service Category" option is set by editing the service categories "User Access" as shown in Fig 3:

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 your Service details, including name, category & 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 section option in Fig 7. as this determines whether or not this service will be visible in the Service Catalogue. Beneath these options is our Service Request Details Table:

Fig 8. Service Request Details options


You'll see in Fig 8. that 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 betaken to the specified URL.

  

As I want to provide a form specific to requesting a desktop (Found in the HaloPSA Trial instances) that would include fields such as desktop type, peripherals and associated software, I have created a new 'Desktop Request' ticket type and associated field list:

Fig 9. Desktop Request field list


After creating this new ticket type, I have specified that this is the ticket type to raise when the 'Desktop Request' service is requested (Fig 8.). As I want the end-user to input details relevant to this request (via the form outlined in Fig 9.), 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.

Great - so we have now created a new 'Hardware' Service category with no access restrictions (Fig 10.) & an associated 'Desktop Request' service that sits under this category (Fig 11.), and raises a 'Desktop Request' ticket type upon this service being requested (Fig 11.).

Fig 10. Our Service Catalogue, including our new Hardware category


Fig 11. Desktop Request form


Monitored Services

Services in HaloPSA 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 part 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:

  1. Generic Email Rule (Type: Service Status, match on i.e. Subject: "Service Update"), this can be acheived within Configuration > email > "Click the Email Rules Button" > *Create an email rule of type "Service Status" and then match on a criteria*.
  2. 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.
  3. Filtering on Statuses: From Here the body of the email should contain the Status "OK" or "Fault" this can again be matched on to change the status of the service in Halo, as explained in detail below.

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.

As explained in the break down above, the first step to acheiving status monitoring is configuring the generic email rule. Next, to set services up in this way, first navigate to the configuration tab of a Service, you can enable the setting "Is a Monitored Service":

Fig 12. Marking a Service as Monitored


This will provide you with some additional options regarding status configuration of the Service, including:

  • Show on the Service Status page - In Configuration>Self-Service Portal, there is a 'Service Status' menu option (Fig 13). With this checkbox checked, the status of the service will be returned in the list when an end-user clicks on the 'Service Status' menu button (NB: the end users must be subscribed to the service to see its status here). You can also display the information of services by ticking on the below option:

Fig 13. Display Type for The Service Status


Fig 14. The Service Status menu option and other menu buttons that can be configured


  • Show Service Status History in Portal - When "Show Status History in Portal" is checked on (found in the configuration tab of a monitored service), the full history of status changes are returned when viewing a service in the Self-Service Portal. When unchecked, the current status is returned.

To set up service status monitoring you will edit the "Monitoring Configuration" tab of the service.

Fig 15. Default monitoring options


The status checking interval is how often the check is expected to send an 'all is OK' message. If the message doesn't arrive, it indicates that the status of the service is unknown at that time.

Ticking on the option for incoming email alerts allows you to configure the email rules associated to this service, such as the from address that correlates to the service the status updates are coming in from.


You can set which mailbox you are ingesting the emails into and then you can string match in the subject and body of the email, so that if the email contains the matching string set on the body or subject, it will link to this monitored service. All of the criteria set on the email rule must be met for the rule to apply and then link to the service. As explained in the breakdown, the second step is to match onto a specific service. The body may contain the id for the status as shown in Fig 16. or it may contain the type of service i.e. "Azure", meaning you could set it to match if the body contains the string "Azure".

Fig 16. Configuring Email Rules for the Monitored Service


After the service has been matched from the rule configured above, you can then say that i.e. if the body contains "status=OK" then make the status of the service ok.

Fig 17. Email Rules for Marking the Status as "Okay"


The rules can be configured for different statuses, so that the updates are status OK or status Fault. Alerting you that there is something wrong. A ticket can also be logged for failure statuses and this will create an incident ticket to alert agents that the service has failed.


If a service is a monitored service and you are not using ticket-driven service statuses, then any statuses that are set to start in the future can be edited or deleted in the status history tab.

Fig 18. The Status History Tab on a  Monitored Service


You can edit the status, start date, internal message, and public messages of the status.


Live chat configuration has the option to configure an action type that will show the user any services they are subscribed to that currently have issues (Configuration > Chat > Chat profiles). Additionally, there is a chat flow condition that checks if any of the user's subscribed services have issues.

Fig 19. Action Type: Service Issues on a chat profile


The condition is 'User is subscribed to a service impacted by an issue'

Fig 20. Condition for the users subscribed service having an issue


You can also see the status of monitored services linked to a ticket on the ticket details screen.

Fig 21. Service Status on the Ticket Details Screen


A setting has been added at ticket type-level "Allow Service Status to be set from the Ticket details screen". Enable this setting for problem tickets and you'll be able to edit the status of the service from the ticket details screen. This links the status update with the problem ticket.


Another setting that has been added at service level for monitored services - "Allow users to follow the problem Ticket when there is a fault".

Fig 22. Following the Problem Ticket as a User


This will show a new option on the portal service details screen for the user to subscribe to updates about a service issue. This shows as long as the service status was set via a ticket.

Fig 23. The button to stay updated (located on the Self Service Portal)


When users select "Keep me updated", they will be added as a follower to the problem ticket. Using the follower email functionality, they can be then kept up to date.


A setting has been added to action configuration to allow follower bcc's to be disabled per action. When the service status is updated via the problem ticket, if there are any user followers on the ticket, they will be sent an email with the latest status and public update. A new email template called "Service Status Update" has been added to customise the content of this email.


NHServer v13.21 + required for the service status email feature.


Maintaining your Service Catalogue


Editing and creating services for your end users is simple. 


  1. Click on an existing service or press new in the top right.
  2. If editing an existing service, click edit in the top left
  3. Name and assign the category to the service
  4. Assign a cost and delivery time if necessary, add a description and summarise the service 
  5. Head to the configuration page
  6. Adjust the settings as necessary
    • Of importance is how the ticket is logged to reference the service request
  7. 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)*
  8. Fill in the remaining tabs including User Access and add any subscribers from here
  9. Add any related services and assets
  10. Click Save

*note that 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 who has 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.

Popular Guides

Pin It on Pinterest