In NetHelpDesk, Services are a collection of business operations that can be used as a means to log tickets, and have them routed to a particular team with preset fields. They can also be used as a means of monitoring the status of particular business operations.
A Service can:
A) Be made available to End-Users via the Service Catalogue.
B) Can be requested from the “Service Catalogue” – this will create a Service Request using the configured Ticket Type or Ticket Template. End-Users can do this from the web portal, and Agents can do this on behalf of a user from the Windows application.
C) Subscribe End-Users who request the Service, to either the Service they requested, or to other Services, where they can log Incidents using the configured Ticket Type or Ticket Template from the “My Services” page. End-Users can do this from the web portal, and Agents can do this on behalf of a user from the Windows application.
D) Track the status of the Service, and display this to End-Users in “My Services”, and automatically create Service failure Tickets to alert an Agent to any issues with the Service.
E) Display Service Requests and Incidents that are linked to the Service.
F) Restricted, so that only particular users can have access to the Service in the Service Catalogue.
G) Linked to Assets.
The Services feature has had a major re-design in version 10.65 of NetHelpDesk. So in order to use this feature and for this guide to be relevant, the following criteria will need to be met:
1. Your NetHelpDesk instance will need to be on version 10.65 or later. In order to check this you can go to N > Help > About NetHelpDesk, and to upgrade you can go to N > Help > Show Release Details.
2. You will need to have the NetHelpDesk Web Portal configured for use (if you want End-Users to use the Service Catalogue). If you have not done this already, a guide to setting this up can be found at www.nethelpdesk.com/guides/installweb/.
3. You will need to have enabled the PHP features for the Web Portal (if you want End-Users to use the Service Catalogue). If you have not done this already, a guide to setting this up can be found at www.nethelpdesk.com/guides/php.
Here are a few terms which are commonly used in this guide, and in the application:
1) Service Category - These are effectively groupings for Services.
2) Service Catalogue – This is an interface that shows End-Users Services grouped by category, which allows them to Request a Service. Requesting a Service will log a Service Request.
3) Subscribe - When a user Requests a Service, they can be Subscribed to that Service. This sets up a link between that user and Service, and the Service will then appear in the Users My Services page.
4) My Services - This is an interface that shows End-Users all Services that they are subscribed to, along with the status of any monitored Service. They can select a Service and log an Incident.
5) Monitored Services - Monitored Services are Services which have their status tracked. The status of the Service will be shown to Users.
6) Unmonitored Services - Unmonitored Services are Services which do not have their status tracked.
7) Service Request - A Service request is a user request for information, advice, or a standard change. In NetHelpDesk, this will be a Request with an ITIL Ticket Type of Service Request.
8) Incident - An issue with a Service. In NetHelpDesk, this will be a Request with an ITIL Ticket Type of Incident.
Services are managed in the main Windows application. To enable Services, in main configuration, ensure that the Services slider is turned on. The settings for Services in main configuration contain a few options which will be covered later.
Visibility of the Services area of the application can also be restricted by Agent. In the Agent settings, please ensure that your Agent account has Services checked in Features Visible > Navigation Features.
On the main screen, you will now see a Navigation option on the bottom bar titled “Services”. This is where Services are set up and managed. You will also notice a new toolbar page at the top of the screen titled “Services”. This contains a few options relating to creating Services and logging Service Requests and Incidents.
Select the Services navigation button and you will see Options for “Category”, “End User” and “Operational Status”.
Each of these options lists Services in the main screen list view, but by different entities in the tree-view.
Category – Lists Services by Service Category. All Services come under a Service Category, and this serves as a way of grouping different Services. End-Users can be restricted so they can only view Services in a particular Category.
End User - Lists Services by the End User tree view. A Service will appear under a Client, Site or User, if the Client, Site or User is “Subscribed” to the Service.
Operational Status - This refers to the Status of “Monitored” Services, and will be covered in more detail later. This lists the Services by their current status (Unknown, OK, Fault, Requires Attention and Planned Maintenance).
Select one of these options and you will be taking to the corresponding view.
The treeview (highlighted green above) shows either Service Categories, Clients/Sites/Users or Operational Status’ depending on the view you are in. Selecting one of these changes the Services which are visible in the main list (highlighted in blue). The list shows all the Services linked to what is selected in the treeview (this list will be empty if using the feature for the first time), and will show key information such as the name of the Service, the Service category, the summary of the Service, operational status, last status ok, whether the Service is available in the catalogue, and the number of subscribed users and linked assets. Double clicking on a line in the list will open the Service Details screen for the corresponding Service. The highlighted red shows the Services toolbar, which contains available actions.
All Services come under a Category, and serve as a way of grouping Services. As this is effectively the top level of the tree in Services, we will start by configuring these (Note that these are not linked to the categories used in Requests in any way).
Select the “Category” view under Services in the Navigation area. The treeview will now show Service Categories. There should be some default categories already available, which can be used, edited or deleted.
To add a new Service Category, right-click on the first node that says “Service Catalogue” and choose “New Service Category”. To edit an existing one, right click on the category and select “Edit Service Category”.
You will then be shown the Service Category details screen. From here you can change the name of the Category, manage restrictions and delete the Category. Restrictions will be covered later.
Now that we have created the Service Categories, we will create the actual Services to go in the Categories.
This can be done by either selecting the “Create Service” button on the Services toolbar, by right clicking on a Service Category and selecting “Create a New Service” (this will put the new Service in the selected category), or in the End-User view by right clicking on a Client, Site or User and selecting “Create a new Service” (this will automatically subscribe the selected entity to the Service).
This will display the Service Details screen for your new Service.
Double-clicking on a Service in the list on the main screen will allow you to edit an existing Service. This will also take you to the Service Details screen.
The Service Details screen is where a Service is set up, and where it is managed. All settings regarding an individual Service are found here. We will now go through a high level overview of each tab (highlighted red above) on this screen.
General - This is where all the key settings to how the Service behaves are, and the name, picture and summary of the Service.
Service Details - This contains a rich field text field for the Service details, where specific information about the Service can be placed and will be visible to End-Users.
Ticket Details - This is where the requests which are logged when requesting a Service or logging an incident are set up.
User Restrictions - (only available if “Show in Service Catalogue” is enabled) - This shows the restrictions on the Service. These can be inherited from the Service Category, and set per Service. (This will be covered in more detail later in this guide).
Subscribers - This shows all the entities subscribed to the Service, settings to do with subscribing and related Services to subscribe users to.
Assets - Shows all assets linked to the Service.
Monitoring - (only available if the Service is Monitored) – This shows settings relating to the Service status. (This will be covered in more detail later in this guide).
Monitoring Email Rules - (only available if “Monitor using Emails” is enabled on the Monitoring tab) – This shows the configuration for using email alerts to update the Service Status. (This will be covered in more detail later in this guide).
Ticket History - Shows details of all requests linked to the Service.
Notes - Field for internal notes about the Service.
Advanced - Advanced settings which would rarely be used. Option to delete the Service.
We will now go over the key settings which dictate the behaviour of the Service on General, Service Details, Ticket Details and Subscribers tabs.
In the screenshots:
1. This is the name of the Service (mandatory).
2. This is the Service Category that the Service comes under (mandatory).
3. This dictates whether the Service is “Monitored” or “Unmonitored”. Monitored Services have their status tracked. Unmonitored do not. E.G A Service that monitors whether a scheduled task is working will be Monitored, and Service to request a Password Reset will not be. Checking this will open up access to the “Monitoring” tab.
4. This dictates whether the Service is available in the Service Catalogue, and whether Service Requests can be logged for it.
5. If this is checked then the Service will be “Subscribable”. Once a Service Request is logged for a User, the User will be subscribed to the Service. Then they will see the Service from the “My Services” page.
6. If enabled, Users who are subscribed to a Service will see an option to log an Incident when accessing this Service. This also governs whether Agents can log Incidents against this Service for a User.
7. By default, once a User has subscribed to a Service they will not be able to Request it (and log another Service Request). This setting changes that and allows them to continue logging Service Requests after they have subscribed.
8. Show a cost next to the Service in the Service Catalogue. If left as 0.00, no cost will be shown.
9. Show an Estimated availability time in the Service Catalogue. If left as 0, no time will be shown.
10. This is a short description about the Service. It will appear for End-Users.
11. This is a photo or a picture to represent the Service, and will appear for End-Users.
12. A long Rich-Text field for the details of the Service. This will appear for End-Users.
13. These are the settings for what happens when the Service is requested. Either a request type can be chosen, or a request template can be chosen if you wish to customise specific details within the request. If using a request template, options to create a new template and view the selected template will appear to allow for easy setup from one place. Only request types or templates with an ITIL request type of Service Request will be available. The default request type is set in Main Config > Services – Default Request Type for Service Requests.
14. By default, the new request screen is not shown for Service Requests. The new request is created behind the scenes without showing the new request screen to edit any fields. This can be particularly useful when used in combination with a template. Enabling this setting will prevent this behaviour, and always show the new request screen.
15. (Only appears if option 6 is enabled) These are the settings for what happens when an Incident is logged. Either a request type can be chosen, or a request template can be chosen if you wish to customise specific details within the request. If using a request template, options to create a new template and view the selected template will appear to allow for easy setup from one place. Only request types or templates with an ITIL request type of Incident will be available. The default request type is set in Main Config > Services – Default Request Type for Service Incidents.
16. This area allows you to manually subscribe users. You can subscribe a single User, or an entire Site, Client, Department, Organisation or Every User. From here you can also remove Subscribers and send a mass email to all subscribers.
17. This setting allows you to choose what entity is subscribed when a Service is requested for a Subscribable Service. Either no-one, Just the User who request the Service, the Site, or Client or the Department can be chosen.
18. This setting will give control to the User to unsubscribe from the Service from the Service screen on the web portal.
19. Add related Services to subscribe Users to other Services when requesting the Service. This will use the setting from option 17 on the target Service to decide what entity is subscribed to the related Service.
On the End User web portal, there are two main interfaces for Services. The “Service Catalogue” allows the User to browse all Services by Category which are configured to show in the Service Catalogue, and to request Services (and subscribe to them if this is configured). The “My Services” screen shows Users all the Services that they are subscribed with their current Status (if applicable), and allows them to log Incidents if this option is enabled.
Both of these screens can be accessed via the Dashboard screen, as long as the following settings are enabled in Main Config > Services.
The link to the Service Catalogue appears as a button titled Log a new Service Request.
The link to My Services only shows if the User is subscribed to a Service. It will display along with the status of any monitored Services if they have any, or a selection of their unmonitored Services. Any Services that appears here can be clicked on to see the Service Details screen, and log an Incident.
It is also possible to get the links to the Service Catalogue and My Services to appear on the Navigation bar at the top of the page. To do this, edit the loggedin.hml file and add $LINKTOSERVICECATALOG and $LINKTOMYSERVICES respectively.
Select the “Log a New Service Request” option, or the link on the navigation bar (if you created one) and the user will be taken to the Service Catalogue screen.
This screen shows all the Service Categories that we set up earlier that have Services in them and that are available to the user, on the left hand side of the page. Next to these are the Services that are available within the selected Service Category. The Services that will show here are any Service in the selected Category that has “Show in Service Catalogue” enabled and is available to the User (through restrictions).
Each Service, or “Catalogue Item” shows the following:
1. The picture of the Service.
2. The Service name.
3. The cost of the Service (if applicable)
4. Two lines of the Summary of the Service.
Clicking on a Catalogue Item will show a pop out Service Details window which we will cover next.
Selecting a Catalogue Item on the Service Catalogue, or selecting a Service on either the Dashboard or the My Services screen will show the Service Details screen (this is not to be confused with the Windows application Service Details screen which we covered earlier).
When accessing this screen from the Service Catalogue, Users will unlikely be already subscribed to the Service, so the options on the screen will be limited.
We are going to look at an example case where everything that can display on this screen is visible, and go through every option.
1. This is the picture for the Service. If no picture is added, a “No Photo” image will be displayed.
2. The close button. Clicking this will close the form. Clicking outside the window will also close the form.
3. The name of the Service.
4. The cost of the Service, if applicable.
5. The full summary of the Service.
6. The Estimated Delivery, if applicable.
7. The Request this Service button logs a Service Request using the request type or template defined in the settings. This will be covered in more detail later. This button will appear if:
a. “Show in Service Catalogue” is enabled and it is not a subscribable Service.
b. “Show in Service Catalogue” is enabled and the User is not subscribed to the Service.
c. “Show in Service Catalogue” is enabled and the User is subscribed to the Service and “Allow Users to request this Service again after Subscribing” is enabled.
8. The Log an Incident button logs an Incident using the request type or template defined in the settings. This will be covered in more detail later. This button will only appear if the User is subscribed to the Service and “Allow Subscribers to log Incidents” is enabled.
9. Unsubscribes the User from the Service. This button only appears if the User is subscribed to the Services and “Users can unsubscribe from this Service” is enabled.
10. The Service Status shows the current status of the Service. This only appears if the Service is a monitored Service, and the User is subscribed to the Service.
11. The current status of the monitored Service. This will be covered in more detail later in this guide.
12. The latest public message regarding the status of the monitored Service. This will be covered in more detail later in this guide.
13. The Open Tickets/Requests section will appear if there are open Incidents or Service Requests linked to the Service within the current users view scope. Clicking on a request in the grid will show that request.
14. This is the Rich Service Details. This will show if the Service Details field is not blank.
Selecting the Request this Service button on the Service Details screen will log a Service Request for the logged in User and link it to the Service.
If the “Show New Request screen when requesting this Service” setting is enabled for the Service, the User will then be taken to the New Request screen for the defined Request Type or with the chosen template already applied. There, they can fill out any relevant details in that request form before they log the request.
Upon completing this form, or if the show new request screen option is not enabled, the User will then be shown a screen with the ID of their new request. If the Service is configured to subscribe the user upon requesting the Service, or configured to subscribe them to another Service, they will then told that they have been subscribed to a new Service.
Links will be shown at the bottom of the page to go to the Service Catalogue, and to go to My Services (if the users has any).
The My Services screen shows the Services which the user is subscribed to. This can be access through the link on the dashboard, the link after requesting a Service or a link on the navigation bar (if one was created). Select one of these links to go to My Services.
1. Services are grouped using Service Categories. This is the start of the group. The groups are listed in alphabetical order.
2. Each row is a Service. Clicking on the Service will open the Service Details screen. The Services are listed in alphabetical order.
3. This is how an unmonitored Service is displayed. The name and summary of the Service will be shown.
4. This is a monitored Service with an issue. The status, the name, last update date, and latest public message will be shown.
5. This is a monitored Service without an issue. The status, the name and the summary will be shown.
Selecting a Service will open the Service Details pop-up screen (5.3) where users can view requests, log further Service Requests, and log Incidents.
Selecting the Log an Incident button on the Service Details screen will log an Incident for the logged in User and link it to the Service.
The User will be taken to the New Request screen for the defined Request Type or with the chosen template already applied. There they can fill out any relevant details in that request form before they log the request.
Upon completing this form, the User will then be shown a screen with the ID of their new request, with links to go to the Service Catalogue and the My Services page.
We have seen how to log Service Requests and Service Incidents from the End User web portal. But in some cases, Agents may wish to log a Service Request or an Incident against a Service on behalf of a User calling in, or a generic Incident for a Service which was not reported by a User.
The Windows application allows Agents to do this in a variety of ways.
The Service selection screen allows Agents to pick a Service, and choose to either log a Service Request or Incident. This screen can be accessed in three ways:
1. By clicking Log a Service Request from the Services toolbar. This will default the Service Selection screen to log a Service Request.
2. By clicking Log an Incident from the Services toolbar. This will default the Service Selection screen to log an Incident.
3. By clicking the Link to a Service button on the new request screen.
Using method 1 or 2 will show the Service Selection screen, and after selecting a Service will open the new request screen with the configured request type or template for the Service Request/Incident, unless a Service Request is logged for a Service which has “Show the New Request screen when requesting this Service” disabled in which case the request will be logged immediately and the new request ID shown.
Method 3 will apply the selected Service’s configured request type or template for the Service Request/Incident to the current new request screen window.
With each method the new request screen will show that the new request will be linked to a Service at the bottom of the screen. When adding a Service Request, if the Service is configured to subscribe Users to the Service or another Service, they will then be subscribed automatically.
Now we will look at how to use the Service Selection screen. This is a simple screen to allow Agents to pick a Service, based on whether they would like to log a Service Request or Incident, based on category and the User they are logging the Request for.
1. This allows the Agent to select whether they would like to log a Service Request or Incident. This filters the list of available Services based on whether they are available in the Service Catalogue, or whether they are able to have Incidents logged about them. By default this will be set to whatever was selected in methods 1 and 2, or the currently selected request type for method 3.
2. This allows the selection of a User. Selecting a User will only display Services available to that User. Selecting no User will display all Services. This will only be visible if using methods 1 and 2, for method 3 the User is inherited from the currently selected User on the new request screen. For methods 1 and 2, the selected User is carried over to the new request screen and the request which is logged. If no User is selected, the User will default to the General User of the Default Site.
3. This shows Service Categories. Selecting a node will filter the list of Services by the Service Category.
4. This is the Service list. Double clicking on a Service, or selecting it and pressing the Select button will select the Service. The columns are changed depending on whether a Service Request or Incident is selected in 1. Right-clicking on a Service will allow the Agent to open the Service Details screen.
5. The Select button will select the currently highlighted Service (alternative to double clicking on the list). The Close button will exit the screen without selecting a Service.
In the Services view, you can also log a Service Request or Incident by right-clicking on a Service and selecting the corresponding option.
This will also open the New Request screen with the corresponding Services request type or template already loaded, but without a User selected. If a Service Request is logged with “Show the New Request screen when requesting this Service” disabled, the select User screen will instead be shown, and the new request logged immediately after selecting a User.
You can also link a Service to a request which has already been created, or link more than one Service to the same request.
On the Request Details screen, on the Related Assets/Services tab, there is an area for Related Services. From here, you can view the Services linked to the Request, and add, remove or view the Services. If this tab is not visible, it can be made visible within the Agent settings under “Features Visible”.
There are a couple of $-variables which can be included in email templates to show the details of the Services which are linked to a request.
$ServiceLINKDETAILS – shows a list of all the Services which are linked to a request. It only returns the names of the Services (e.g used in templates to list the linked Services).
$ServiceLINKSTATUSDETAILS – shows the details of all monitored Services linked to the request, including the name, current status, number of subscribers and number of assets (e.g used in templates to for alerts to techs or approval emails).
Restrictions can be placed on Users, Service Categories and Services to restrict what Users can access Services in the Service Catalogue. Agents can also be stopped from administering Services.
The first restriction we will look at is the simplest. It is an option at User level which can be found in the Edit User screen on the Services tab, called “Can access the Service Catalogue”. Disabling this setting will prevent that User from accessing the Service Catalogue.
The next restriction we will look at is the Users “Service Access Level”. This is a setting at User level which can be found on the Edit User screen on the Services tab, called “Service Access Level”. There are three level - “Low”, “Medium” and “High”. All users have a default of “Medium”.
Each of these doesn’t do anything in particular, but links to a similar field at Service Category level which can be overridden at Service level. In the Service Category settings on the Restrictions tab, you will see the following similar setting.
Users will only be able to see Services in the Service Catalogue where their Service level is the same, or greater than the Service Category level. On top of this, the Category level restriction can be overridden at Service level on the Service Details screen on the User Restrictions tab.
By default, the Service Category will have a User a level of “Medium” and Services will have “Use Category Level Setting”. Using these levels can allow only certain users to access particular Services.
Restrictions can be added at Service Category level to only allow particular Clients, Sites, Departments or Organisations access to Services in that Category in the Service Catalogue.
This can be configured in the Service Category details, on the User Restrictions tab. By default, all Service Categories have “Everyone” already added to the list.
To restrict the Service Category to a particular entity, you will need to remove the “Everyone” permission. You can then use the buttons on the right hand side of the window to add the entity which you wish to be able to see the Service.
Restrictions can added at Service level to only allow particular Clients, Sites, Departments or Organisations access to the Service in the Service Catalogue. A Service will inherit all restrictions set at the Service Category level (7.4). A Service can be allowed access to more entities than just the ones added a Category level. To make use of these, the “Everyone” permission will need to be removed from the Category first.
This can be configured in the Service details, on the User Restrictions tab. By default, all Services have no restrictions.
You can then use the buttons on the right hand side of the window to add the entity which you wish to be able to see the Service. Note that removing a permission inherited from a Service Category will remove it from all Services in that Category.
Access to the Service Details screen where Services and be set up and managed can be prevented on an Agent by Agent basis or by Agent Template. You can prevent a particular Agent from creating and managing Services by disabling the following setting on the Agent details screen on the Permissions tab under Specific Permissions.
Monitored Services are Services which have their status tracked. They are Services which have “This Service is Monitored” enabled in Services Details. The status of a monitored Service can be one of the following:
Unknown – The current status of the Service is not known. When email monitoring is in use and the checking interval passes without an OK or FAULT email, the status will be set to Unknown and a request will be logged. This status will show as FAULT for End-Users. (This will be covered in more detail later in this guide.)
OK – The Service is functioning properly.
Fault – There is an issue with the Service.
Requires Attention - There is an issue with the Service and it requires attention from an Agent. This will show as OK for End-Users though, so is meant for minor issues or check-ups.
Planned Maintenance – Maintenance is due to be carried out on the Service. Details of when the maintenance is due to take place can be placed in the Public Update field when changing the status, so that Users can see how they will be affected.
Agents can see the status in Service view on the main screen (the status will be shown in the list, and have an image representing that status next to it), or on the Service Details screen in the top-right hand corner. Services can be viewed by Operational Status by choosing the Operational Status view on the main screen.
Subscribers to the Service can also view the status on the web portal. Only three different statuses will be shown for End-Users.
1. OK – if the status is OK or Requires Attention.
2. Fault – If the status is Fault or Unknown.
3. Planned Maintenance – If the status is Planned Maintenance.
We will now go through the settings for Monitored Services, how Agents can manage monitored Services and what End-Users can see.
The settings for Monitored Services are available on the Service Details screen > Monitoring tab.
1. Clicking this button will take you to the Service Status Details screen. This screen will allow the Status to be manually changed, an internal and public note to be added, show key stats and the status history. The bit highlighted in GREEN in the screenshot shows the current status of the Service, and clicking on it also takes you to the Service Status Details screen.
2. The checking interval is mainly used as part of email monitoring. If there is not a status update within the checking interval, the status will get set to Unknown automatically. -1 represents no checking interval, so the status will not ever get set to Unknown automatically.
3. These are the Working hours which the checking interval will apply.
4. This is a Service URL used to link to a page regarding the Service. It is for internal use.
5. Enable this setting to enable Email monitoring. This will open up the “Monitoring Email Rules” tab. This will be covered in more detail later in this guide.
The Service Status details screen is used to manage the current status of a monitored Service. The status can be changed, an internal note added, a public note added, and stats and history can be viewed.
This screen can be access from the “View Service Status and History” button on the Service Details screen Monitoring tab, by clicking on the current Status at the top of the Service Details screen, and by right-clicking on a monitored Service in the Service view on the main screen.
1. View the status history. Ordered by date descending.
2. The current status of the Service.
3. The latest internal note. This is not displayed to Users. This is Read-only.
4. The latest public message. This is displayed to Users. This is Read-only.
5. Manually adjust the status, and add a new internal and public note.
6. Go to the URL defined in 8.2 setting 5.
7. View the last email alert. This is for email monitoring.
8. Key stats regarding the Service Status.
To change the Services status, click on the Update Status button. This will allow the Agent to choose a new status, and enter a new internal note and a public message which the End-Users will see.
Click OK to update the status.
When logging a new Incident for a monitored Service, if the status for that Service is currently OK, it is possible to update the status to Fault. At the point of Adding the new Incident, the Agent will be asked whether they would like to update the Status.
Clicking “Yes” will set the status of that Service to Fault.
Similarly, when closing an incident which is linked to a monitored Service where the status is currently Fault, the Agent will be asked whether they would like to update the status to OK.
Selecting “Yes” will set the status for all linked Services to OK.
Only Users that are subscribed to a Service can see the status of a monitored Service. Each monitored Service has a symbol next to it which represents the current status;
· Green Tick – OK
· Red Exclamation Mark – FAULT
· Blue Cog – PLANNED MAINTENACNE
The User can see the status of a Service that they are subscribed to three places:
The Dashboard - This shows the first 3 Services which are not OK if there are any. If there aren’t any Services with a status of Fault or Planned Maintenance, but there are Services which the User is subscribed to that are OK, if will show a message saying that all monitored Services are OK. If the user is not subscribed to any monitored Services it will just show the first 3 unmonitored Services.
My Services – The status will be shown next to each monitored Service. Services which have a status of Fault or Planned Maintenance will also show the latest public message, and the date and time of the latest public update. Services which are OK will show the status, and a summary of the status.
Service Details – The status will show as the first thing beneath the main details of the Service. All monitored Services will show the current status, and the most recent public message, and the date and time of the most recent public message, as long as the user is subscribed to the Service.
When last public message is not set when updating the Service status, the text used for the “Latest Update” can be edited from Main Config > Services, under Service Status Settings.
Email Monitoring is the use of Emails to update the Service of a monitored Service. Email rules can be set up to identify an email as a Service Email. Further rules can then be set up to establish what Service the alert relates to, and whether the status is OK or Fault. This feature can be turned on for a Service by enabling the “Monitor this Service using Incoming Email Alerts” setting on the Monitoring tab of the Service Details screen.
A checking interval can also be set, as briefly covered in section 8.2. This means that if an email is not received for a Service within the interval then something is wrong with it, and the status will be set to Unknown until an OK or Fault email is received.
For NetHelpDesk to know that a particular email is a Service alert, we need to set up an email rule. This can be done in Main Config &> Services, under Email Monitoring.
Now you want to add a new rule, or edit an existing one if you have one.
Using a combination of Mailbox, Subject, Body, From Address and To Address, you can set up a rule where any email that matches the criteria will be treated as a Service alert.
In this example, all emails with ServiceSTATUS in the subject will be treated as a Service Alert.
Now that we have set up an email rule, we can configure a Service to recognise what alerts are related to a particular Service. This can be done on the Service Details screen, on the Monitoring Email Rules tab.
1. These settings are like another email rule to identify the alert as an alert for this Service. In this example all emails with ServiceSTATUS and emailService in the subject will be matched to this Service.
2. Enabling this setting means that any Service alerts that match the criteria in 1 will set the status of the Service to OK.
3. If not using 2 or 4, these settings are another rule to set the status to OK. In this example all emails with ServiceSTATUS and emailService in the subject, and status=OK in the body will set the status of that Service to OK.
4. Enabling this setting means that any Service alerts that match the criteria in 1 will set the status of the Service to Fault.
5. If not using 2 or 4, these settings are another rule to set the status to Fault. In this example all emails with ServiceSTATUS and emailService in the subject, and status=FAULT in the body will set the status of that Service to Fault.
6. Enabling this will create a Request when Emails update the Status to Fault. This is called a “Service Failure Request”.
The Checking Interval is set on the Monitoring tab of the Service Details screen, and is set in minutes. If the status is not updated for a Service before the last update time + checking interval, then the Service will be updated to the Unknown status. This will log a “Service Failure” request.
Service Failure Requests get logged when a Service received a Fault email alert and “Create a Request on Failure” is enabled, or when the status is set to Unknown through the Checking Interval. The Request Type used for Service Failure Requests is set up in Main Config > Services, under Email Monitoring, as shown below.
The Site used for Service Failure requests is the Default Site, but this can be overridden and set to a particular Site per Service on the Service Details screen, “Advanced” tab. This is useful for if a Service is for a single Site.
When a Service Failure Request is closed, as in section 8.4 the Service Status can be updated back to OK (as long as the ITIL request type of the request type is either an Incident or a Problem).
This section covers settings which are not covered in the rest of this guide, and are mainly advanced features.
The Advanced tab of the Service Details screen has a few settings which are legacy functionality or for advanced use.
1. This is used for linking a request to a Service via a Request Category. Category values can be added to a Service, and when that category is selected on the new request, request details or new action screen, it will link the request to the Service.
2. This is another working hours setting, used for calculating the time a Service is down. The time a Service is down is shown on the Service Status screen, and selecting Service Hours will exclude the time outside the working hours where it doesn’t matter if the Service is down.
3. This is a legacy setting, and can be used as another way to group Services. It is not used for anything other than display purposes.
4. Default Client/Site for Service Failure Requests. See section 9.4.
5. Delete the Service.
If you have any further question, please contact the NetHelpDesk support team at www.nethelpdesk.com/support.
NetHelpDesk is available on a range of devices with industry-leading functionality available throughout.