HaloITSM Roadmap

Azure Monitor Integration is now available

Halo can now accept webhooks from Azure monitor and create Tickets from them. Field mappings can be configured and if the alert is Resolved it will automatically close the ticket in Halo.

The Azure Sentinel Integration is now available

The Azure Sentinel integration is now available in Configuration > Integrations. 

Syncing Incidents from Halo to Sentinel

When you navigate to the page you should be able to authorize in the same manner as Azure Active Directory and other Microsoft Integrations. You'll need to create a partner application in your Azure Portal with the following permissions:

You can then use the details from this application and your Azure tenant id to authorize. After authorizing you should be shown Ticket field mappings where there are 4 mandatory fields to be set for importing and exporting to Azure Sentinel:

After Setting these, navigate to the bottom of the page regarding enabling the integrator, once enabled this will then import the last 7 days of Sentinel Incidents if never run before. If it's previously run, it'll import all incidents modified between now and the previous update time. This import will also pull any new comments adding in Sentinel but not in Halo yet:

The integrator is now set up to sync Sentinel Incidents to Halo. Note that when importing incidents from Sentinel it will attempt to match priority, status, and agent to halo by names. Note that it'll use the SLA present on the default ticket type for priority matching.

Syncing comments and closure actions from Halo to Sentinel

Before setting up actions to sync, any agent that has an account with contributor permissions to Azure Sentinel will need to individually log in to their Microsoft account under the integrations tab in the My Account section:

This will redirect them to log in such that any comments they add are directly linked to their account rather than the admin account.

With regards to actions syncing to Sentinel, there are several key action level fields to be aware of:

Sync to Sentinel - will sync the current action to Sentinel, either as a comment or as a closing action if the Halo status is set to closed/resolved.

Azure Sentinel Classification - The classification to be set in Sentinel if the incident is being closed, if not set when closing a ticket in Halo, it'll fall back to the default set above.

Azure Sentinel Classification Reason - The Classification reason to be set in Sentinel if the incident is being closed, works the same as above for the default.

Please note the two above fields must work as a matching pair in Sentinel. E.g. Classification Undetermined should only be used with Reason N/A.

Note - This will be used for the comment text or the classification comment depending on whether the ticket is being closed in halo or not.

Status - Setting this to Closed/Resolved in Halo will attempt to close the incident in Halo.

Priority - Note that when syncing a closure action, the priority name from halo must match a priority name in Sentinel (High, Medium, Low, Informational)

The recommended way to set up an azure sentinel closure action would be something like the below:

Whereas a comment action could remove the classification and classification reason. 

Agents can now individually connect to their Exchange calendars rather than using one account with delegate access

You can now choose between two connection methods when the Graph API connection method is selected:

When connecting to each account individually, an option will be shown on the calendar screen for each agent where syncing is enabled in their preferences to connect to their Exchange calendar: 

Agents can sign out at any time from the same location:

Improvements to the CSP integration

It is now possible to connect to multiple instances of CSP.

Once connected, you can now map multiple Azure tenants from CSP to a customer in Halo. This can be done on the Managed Tenants tab of the integration, or on the settings tab of each individual customer:

Each managed tenant can only be assigned to one customer in Halo.

If you are mapping multiple Azure tenants to one customer in Halo, you can modify site mappings per tenant. This allows you to map each linked tenant to a different site against the customer should you wish to.

Knowledge base article draft functionality added

Enable "Use article drafts" in Config > Knowledge Base. This will make it so agents can no longer directly add a new knowledge base article or edit the details of existing articles and instead need to create a draft version of the article and publish it.

Draft articles use ticketing functionality. In order to utilise this, a ticket type should be created for Draft Articles and set as the "Ticket Type for Article drafts" in Config > Knowledge Base.

Knowledge Base article fields have been added to the Ticket Type and Action field lists. These should be included in your draft ticket type. The new fields are as follows;

• Article type (for when also using the news articles functionality)
• Article description
• Article resolution
• Article notes
• Tags
• FAQ lists
• Related Articles

The Ticket level summary field, public attachments, and custom fields will also link to the relevant article level fields.

When a new article is raised the agent will be shown the new ticket screen for the Draft article ticket type. On the Ticket details screen, these fields will show on a new Article Draft tab.

Configure an action with the system use "Publish Article" as part of the workflow for this Ticket Type. When used, a new article will be created from the ticket using the content in the Ticket level article fields.

When using drafts, agents will no longer be able to edit the details of existing articles and will instead need to use the "Draft Amendment" button.

This will open the New Ticket screen with the Draft article ticket type with all the article fields populated with the data from the existing article. When using the Publish article action for Drafts on existing articles, the article will be updated, or if you are also using the article versioning functionality a new version of the article will be created.

This functionality allows you to have a more comprehensive process for new articles or updates to existing articles, including approval processes. A new approval type for Linked Article Owner has also been added to allow approvals on amendments to existing articles to be approved by the owner of the article, as well as an approval rule criteria option for Linked Article ID.

Various minor improvements to articles and versioning have been made.

Satisfaction Surveys are now available for the new Self Service Portal

Satisfaction Surveys allow you to capture more information from your users regarding their experience compared to One Click Feedback.

These Surveys can be configured in Tickets > Surveys towards the bottom of the page:

The $ SATISFACTION variables have been modified and will now take your users to the Survey page. You can still use user closure confirmation with these Surveys. The percentage chance of a user being surveyed is configured at the top of the page.

By default, the survey will contain a satisfaction level with the lookup mappings which you can configure by clicking the "Survey Satisfaction level mappings" button. It will also contain a general comments field, similar to how One Click Feedback allows you to collect comments. These two fields will be saved to the feedback table in the same format to how One Click Feedback is saved.

You now have the ability to add custom survey fields by clicking on the "Add Survey Custom Fields" button. Once you have created the field, you must remember to add it to the Ticket Type you wish to collect the data on. When a user submits the Survey, the data collected will be saved against the ticket in the faults table - ready for you to report on.

A simple survey with two custom survey fields could look something like this:

Dynamic visibility will work for survey custom fields.

Optional Services functionality has been added.

Optional Services provide a new way of logging child Service Requests from a Service. Using this functionality you can show the new ticket forms of other child service requests from the parent and log requests for service items at the same time as the parent service request.

In the Service Config, if the Service is set to show the new ticket form when logging the Service Request there is now a table for Optional Service Items. Here you can specify all the Service Items that you wish to be possible child requests of the Service Request. They can be set to be included by default and made mandatory.

When logging a Service Request on the portal for a service with optional Services the New Ticket form will now have a Choose Options tab. Once you complete the details form for the Service Request the user will be taken to the Choose Options tab. There they can choose which optional Services they would like and if there is a form for the service the form can be completed there.

Enabled optional Services will submit a new Service Request as a child of the original Service Request. These will obey copy to child field functionality and be for the same user as the parent.

A good use case is logging a New Starter service request, and being able to choose the equipment they require. This method provides a simpler way to using child creation rules and having all the fields on the parent Service Request.

Asset Resource Booking module added

Activate the Resource Booking module from Config > Asset Management.

This will open up a new tab on the Asset Type details screen for resource booking, which will allow you to activate resource booking for an Asset type and contains all settings relevant to resource booking.

Resource booking hours will allow you to choose a workday set for which booking is allowed based on working days, hours and holidays. Booking types define the duration of a booking and are used to determine the available timeslots within the working hours. These can be set as follows;

• A fixed number of minutes (e.g 60 minutes). This will make the timeslots available every hour within the working hours.
• A fixed number of days (e.g 1 day). This will make it so you only select a start date of the booking instead of a particular time slot.
• Custom timeslots. These allow you to specify the slots you want to be available within the working hours and these can be spaced however and at different intervals.

There are also settings that determine which assets will be available based on client and site, whether to auto-allocate an asset or allow selection, and the minimum hours in advance to allow booking and maximum days in advance to allow booking.

Resource booking itself is done via the new ticket screen on the end-user portal or agent application. In order to use this a "Resource Type" must first be chosen. This links to the Asset types for which resource booking is enabled. A default can be picked at either Template or Ticket Type level, or you can add the Resource Type field to the Ticket type field list in order to select it on the new ticket form.

Add the "Resource Booking" field to your ticket type in order to show the booking fields on the new ticket screen.

The booking fields show as follows;

• Booking duration - selection of a booking type in order to determine the timeslots to choose from
• Booking date/Booking start date - a calendar that shows which days have available timeslots based on the chosen booking type. Selecting a date will show the available Booking timeslots
• Booking timeslot - lists all timeslots which are available on the chosen day.
• Resource - if the selection of an asset is enabled this will show after choosing a timeslot, and allow you to pick from the available resources in that timeslot.

The Resource Booking field determines the value of the Start Date/Time, Target Date/Time, and Asset fields. These fields should not be used on the same New ticket form as the Resource Booking field.

Availability of a date/timeslot/asset is determined by if it's within the specified working hours, minimum and maximum hours/days in advance, and tickets for the Asset with a Start Date/Time and Target Date/Time that overlaps with the timeslot.

You can now also toggle Calendar view when viewing Assets tickets so you can easily see the bookings for a particular asset on a Calendar. A few other minor improvements have been made involving being able to see start/target date/times on the end-user portal, calendar view, and resolving a few related issues.

Assets added to the mobile applications.

The assets area has been added to the navigation bar on the mobile apps. Here you can list assets by type, all assets or your bookmarked assets. Asset details, tickets and attachments can also be viewed.

Options to Move and Bookmark assets are available on the asset details screen and by bulk-selecting on asset lists.

A barcode scanner has been added to be able to find existing assets.

Jamf Integration has been added

The Jamf Integration is now available in Configuration > Integrations > Jamf as of version 2.66.1 and above:

The Integration is able to import Mobile Devices and Computers over from Jamf into Halo. First you'll need to input your Jamf Url, followed by a jamf account username and password alongside setting asset types to import and default asset types for each type of asset type being imported:

The account will need at minimum read permissions for mobile devices and computers endpoints.

You can then set up asset fields mapping from Jamf to Halo and import assets manually as well as enabling halo integrator syncing, please note you'll need version 2.66.1 or above of the halo integrator for Jamf to be visible on the integrator:

Please Note that when Jamf does matching to which site to place the asset under it only checks the username of the device and tries to match this to a user in the system based on their username and will assign it to that user at their site. It does not currently match against a building.