In this lesson we will cover:

– Monitored Services

– Setting up a Monitored Service (Email Alerts)

– Ticket Driven Service Monitoring

– Service Monitoring in the Portal

– Service Monitoring and Live Chat

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.

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.

To determine the type of service status monitoring you are using head to Configuration > Service Catalogue, see the setting 'Enable Ticket driven statuses'. This is a global setting so if this is enabled the status of services can be determined by tickets, if disabled it can be determined using email alerts. We will cover how to set up both in this guide. 

Setting up a Monitored Service (Email Alerts)

Email alert service status monitoring is used when you receive email alerts regarding a service from the service provider and would like to automate updates to this service. 

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:

1. Generic Email Rule – An email rule with type 'Service Status' is matched, so the email can attempt to be matched to a monitored service.
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 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.

Note: You must be on NHServer v13.21 + or the incoming/outgoing services to use service status monitoring via emails.

Create Email Rule

As explained in the break down above, the first step to achieving status monitoring is configuring the generic email rule.

Head to Configuration > Email > Rules > New. Here name the rule something like 'name of service-monitoring', then set the 'Email Rule Type' to 'Service Status'. Now you will need to set the criteria for an email to have in order to match this rule.

The criteria can relate to the from address, email subject or email body, if alerts regarding this service always come from the same email address, and this email address is not used for anything else (e.g. to log tickets), it is best to set this email address as the criteria.

This means every time an email comes in from this address it will match this rule. See Fig 1 for an example on how you may set up this rule. 

Fig 1. Example email rule – matched if from address equals 'alerts@3CX.com'

Configure Service to be matched on

Next, you will need to configure the service so that it can be matched on from an email. Head to Services > select the service you want to monitor. Enable the setting "Is a Monitored Service", in order to allow service status monitoring for this service.

Fig 2. Marking a Service as Monitored

Now head to the "Monitoring Configuration" tab of the service. Here, enable the option 'Monitor this Service using Incoming Email Alerts', this will allow the service to be matched on alert emails, and allow you to configure the matching criteria for the service. 

You can also set a 'Status checking interval', this is how often the alerting service is expected to send an 'all is OK' message. If the interval is set to be 5 and over 5 minutes has passed since the last message, it indicates that the status of the service is unknown at that time. Setting this to -1 will result in the service status remaining the same as the last update, until a new alert email comes in. Setting an interval allows you to identify if there is an issue with the alert emails, by changing the service status to 'unknown' if an email alerts has not come in within the expected interval. 

You can also choose the working hours in which the mailbox is checked for alerts, allowing you to limit updates to working days/out of hours. 

Fig 3. Monitoring options

Now you will need to set the criteria the email needs to meet in order to match this service, this is done under the 'Service Email Rules' section. 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".

It is best to keep the criteria as simple as possible to reduce the likelihood of alert emails being missed, but ensure it is still unique to each service. 

Fig 4. Configuring Email Rules for the Monitored Service

After the service has been matched from the rule configured above, you can then set criteria needed for an 'OK' or 'Fault' status to be reported. For example, if the body contains 'Fault' then make the status of the service Fault.

Fig 5. Email Rules for Marking the Status as "Fault"

Here, you also have the option 'Receiving any message means it is OK/Fault', this means any email that comes in and matches this service will update the status of the service to be ok/fault. This is used when emails indicating an ok status do not always have the same subjects/body, but emails indicating a fault do have consistent criteria. In figure 6 any alert emails will log a status of 'ok' unless the email body contains the string 'FAULT'.

Fig 6. Using 'Receiving any message means…' setting

A ticket can also be logged for failure statuses to alert agents that the service has failed. To do this, enable the 'Create a ticket on failure' setting under the 'Status is Fault' configuration. When enabled an incident ticket will be logged for the service.

You can choose the customer/site for the ticket to be logged under, it is recommended to log this under your company's customer or a generic customer. You can also choose how many tickets are logged using the setting 'Create a new Ticket each time a failure message is received'. When enabled a ticket will be logged for every email that meets the service is at fault criteria. When disabled a ticket will only be logged each time the service status changes from ok to fault. 

Once you have the email alert service status monitoring set up, if the status changes i.e. there is a fault/issue you can send an email out to all subscribers of this service to alert them to this issue. This can be used to alerts certain users, such as managers, to issues with the service.

Fig 7. Send email to all subscribers

Ticket Driven Service monitoring

Ticket driven service monitoring allows you to monitor the status of services using tickets. When there is an issue with the service a ticket is raised which updates the service status, you can then link any further tickets that user may raise in regards to this to this ticket. Then when the issue is resolved you can close the ticket and the service status will be updated. The status that the service is updated to is determined by the ticket's ITIL type, type 'problem' will update the status to be 'Fault'. Type change request will update the status to be 'Ok'. 

This is used when you do not receive email alerts in regards to services or you have lots of planned maintenance. As soon as a user reports an issue with the service you can update the service status and limit communication to only users who have been affected. This can be more useful for localised issues. 

Note: If you are using ticket driven status monitoring you cannot change the status of a service manually (against the service), this can only be changed by logging/closing a ticket related to the service. 

How to use and set up ticket driven service monitoring

First, you will need to enable the setting 'Enable ticket driven Service statuses' under Configuration > Service Catalogue.

Now, you will need to create or modify two existing ticket types, one that is used when there is a fault with the service, one that is used when there is maintenance on the service. The ticket types can be called something like 'name of service-Problem', 'name of service-Maintenance'. The fault ticket type will need to have ITL type 'Problem' and the maintenance ticket type will need to have the ITIL type 'change request'. Then under the defaults tab of the ticket type set which service the ticket types to relate to, the setting is called 'Related Service Catalogue'. This is the service that will have it's status updated. 

Fig 8. Related service catalogue

Now under the Field List tab you will need to add the field 'Update related service status', this field is a checkbox that, when checked, will update the status of the related service. Having this a field allows you to log/use this ticket type without updating the related service. This setting can be defaulted under the defaults tab using 'Default for Update service status field' (seen in Fig 8). When enabled the field will be checked by default, an agent will need to de-select it if they do not want the ticket to update the service status. 

You can also add the field 'Service Status Note', this is a text field that allows you to type out the public note that appears against the service status on the portal. Allowing you to disclose specific information about the fault/maintenance. Finish setting up your ticket type as desired.

Fig 9. Fields on service ticket type 

Now when a user logs a ticket reporting there are service issues you can raise this ticket type to update the service. It is best practise to then link the users' ticket to this ticket, and link any further tickets raised related to the issue as well. To link user's tickets to the parent ticket select the tickets to link in the list, how over the 'edit' button select 'link' and enter the ID of the ticket you would like to link this to.

Fig 10. Linking tickets

Now you can record progress on the issue, update users on the progress on the ticket and when the issue is resolved, close the ticket. Users can be updated by completing a public/email action on the parent ticket and having this action send to all child tickets too. To do this head to the ticket type configuration, settings tab and set the setting shown in Fig 11  to 'Always' or 'ask each time' .

Closing the ticket will update the status of the service back to 'ok' and can update/close any linked child tickets. 

Fig 11. When Actions are added to a Parent Ticket by an Agent, also add to all Child Tickets

If you are logging a ticket to schedule planned maintenance you may benefit from using the start/target date and time fields on the ticket type. If using these fields the service status will change based on these fields rather than based on the logging/closing of the ticket. This means that if service maintenance is planned in advance, you can log a ticket but set the start date for the future so the service status will not change until this date. Similarly if there is a fault with the service but you have been advised this will be fixed at a particular time, you can set the end date of the ticket to be this time so the service status will change at this time, but the ticket remains open to prompt agents to check for any further issues. 

Status history

When using ticket driven status monitoring the service history will have a linked ticket each to next record, allowing you to open up the ticket that prompted the status change. This is useful for reviewing previous issues as you can see how long the issue took to resolve and how many users it affected. Note that if you have previously been using service status monitoring and have switched over to ticket driven monitoring you will not be able to see the previous status history. The histories for the types of monitoring are stored separately which means you cannot see both versions of the history at the same time but if you switch back, the history from the previous type of monitoring will show. 

Freeze periods

If there is some scheduled maintenance on a service you may like to prevent customers from raising change request tickets in this period. This can be done by creating a 'freeze period'.

To do this head to Configuration > Tickets > Change Management, here you can enable the setting 'Prevent logging of change requests that clash with change freeze periods' and then set the periods in the table below. In Fig 12 I have created a change freeze period so that customers will not be able to log change request ticket type within the dates 04/11/24 to 05/11/24

Fig 12. Creating freeze periods

Service Monitoring in the Portal

End users can see the status of monitored services in the portal, you can configure how these appear/are viewed. 

To enable the service status to be visible in the portal enable the setting shown in Fig 13. 

Fig 13. Show on the Service Status page

Then head to Configuration > Self Service Portal > Menu Buttons area, add the button 'Service Status'. This will allow users to select the service status button in the portal. When this button is selected users will see a list of monitored services and their current statuses Note, the end user must be subscribed to the service to see its status here. 

You can also configure monitored services to show on the home screen of the portal. Under Configuration > Service Catalogue, enable 'Show Service Status Information on the End-User portal home screen', when enabled services will appear on the portal home page under the menu buttons. You will also have a dropdown to set how the services display.

Fig 14. Show Service Status Information Setting

Note: This setting is also found under Configuration > Self Service Portal, if the setting is changed in this area it will automatically change the setting in the other area too. 

• Show a limited number of services – Any with an issue will display first. This will show monitored services in a list, those with an issue will be at the top of the list.
• Show all services – Will show all services in a row format.
• Show all services with an issue at the top of the page – Will only show services with an issue (fault/planned maintenance status). These will appear at the top of the homepage rather than the bottom. 
• Only show services with ongoing issues – Will only show services with an issue, at the bottom of the homepage.
• Only show services with a status issue and show the status details – Services with an issue will be visible at the bottom of the homepage, but there will be more detail on the issue dates/times/notes.

When you click on a service status in the portal this will bring up a page with more information on the service status. If you would like the service status history to display here, enable the setting shown on Fig 15, this setting is found against the service itself.

Fig 15. Show status history in portal

Subscribing to a service

Under the setup for the monitored service, you will see a tab titled 'Subscribers', here you can configure who is/can subscribe to the service. Subscribing to a service allows an end user to see the status of this service in the portal.

Fig 16. Service subscribers page 

You can set which users are subscribed to a service in the 'Service Subscribers' table. Users can be subscribed based on the entities shown in Fig 16.

Fig 17. Entities to subscribe users to a service 

As of v2.178 you will have the additional option to set the 'subscriber type' of these users. 

Fig 18. Set type of subscriber

All subscribers will be able to see/monitor the service in the portal, the subscriber type will determine the notifications these users receive. 

Stakeholder Subscriber – Users with this subscriber type will receive email/SMS updates when a bulk email is sent to all subscribers (using the 'send email to all subscribers' action against the service). 

Standard Subscriber –  Users with this subscriber type will NOT receive email/SMS updates when a bulk email is sent to all subscribers (using the 'send email to all subscribers' action against the service). 

Stakeholder subscriber is the standard subscriber type, this is how bulk emails will function for service subscribers prior to v2.176 and the subscriber type users will be assigned following the version update. 

Automatic subscribing

Services can also be configured to automatically subscribe certain users when there is a fault/maintenance with the service. This is useful when a service affects a particular site/group of users so when there is a fault you would like everyone at this site/in this group to be subscribed and kept updated. 

Note: Ticket driven Service monitoring must be enabled to use this functionality.

To do this enable the setting 'Users can subscribe to this service' under the setup page for that service. You will also need to ensure that the setting 'Unsubscribe all Services when this Service is logged' (under subscriber tab) is turned off.

To determine who will be subscribed to the service when an issue is reported with it adjust the setting 'When a Service Request is logged, subscribe', the group you select here will be the users that subscribed. For example if 'The users default site' is selected any users that are under the same site as the user who logged the ticket will be subscribed. Also ensure that any users you would like to be automatically subscribed are not subscribed to the service already (check subscribers table). 

Now when a user logs a ticket to indicate an issue with the service (and the service status is changed from ok to fault) they (and other users) will automatically be subscribed to the service. They will receive a pop-up after the ticket is logged to indicate this. 

Fig 19. Subscribed to service notification

Any users who have been automatically subscribed will appear in the service subscribers table. 

If you would like users to be able to unsubscribe themselves from the service you will need to enable the setting 'users can unsubscribe to this service' shown under the subscribers tab. You will also need to enable the setting 'Users can subscribe to this Service' found under the 'Configuration' tab. This will allow users to unsubscribe in the portal.

Service Monitoring and Live Chat

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 20. Action Type: Service Issues on a chat profile

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

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

For more information on creating new and configuring (non-monitored) services see our advanced services lesson here.