HaloITSM Roadmap
Find out about all the exciting, up and coming developments in HaloITSM
In Progress
Slack User Bot
Slack Integration on End User Chat Bot
Ticket Creation on Mobile App
Ability to display new ticket forms on mobile app.
WorkDay Integration
Integration with Workday.
AWS Bedrock (AI Search Index for Hosted Customers)
Introducing a Vector database for AI Search and Virtual Agent to be hosted within Halo AWS infrastructure.
Config Tracking & UAT Syncing Improvements
Introducing UAT mailboxes and automating restore of production database to maintain regular flow of configuration from staging environments to production.
Search for Settings in Configuration
Allow for individual settings to be searchable in the Configuration module.
SaaS Management
Management of SaaS accounts and usage.
Email Encryption at Source
New method to allow for outgoing emails to be encrypted and require authentication to be accessed by end-users.
Searching for multi-select fields
Ability to search for individual values in multi select Drop-Down field.
Up Next
Halo Tabs for Tickets
Ability to have multiple tickets open in one single browser tab.
Linking of tickets across Halo instances
Improvements on linking tickets between Halo instances.
Tickets to open in mobile app on mobiles
Introduction of opening tickets on the Halo mobile app from the received notificaiton.
Change Sets for Configuration
Introduction of "Change Set" concept to only partially transfer configuration between enviornments based on the entities changes relate to.
AI for Change Optimisation
Leverage Halo AI to optimise the Change Management process by assessing risk.
Future
Escalation Enhancements
Ability to auto-escalate tickets if agents do not acknowledge ticket notifications.
Ticket Status Dependency
Introduction of ticket dependencies on different workflow steps.
Recently Completed
Halo Push Notifications can now be sent to Agents Web Browsers
Within a Notification, you can now choose to send browser push notifications by enabling the "Send a browser push notification" setting.
When one or more notifications have this set, Agents using a browser that supports Firebase Messaging will be prompted to grant permission for Halo to send them notifications once they log into Halo.
The notification will be delivered to the browser and how it shows will depend on the browser. For example, Chromium browsers can display a notification in the Windows notification centre.
Clicking on the notification will open the relevant link in a new Halo tab, and mark the notification as read.
A few other changes have been made to notifications to support this;
- The delivery method option "Popup in notification pane" has been renamed to "Show in Halo only" as all notifications show in the Halo notification pane.
- A new checkbox setting has been added labelled "Popup in notification pane" which is active by default. This determines whether a notification pops up within Halo when it is delivered.
When using browser notifications, to avoid duplication of popups it's recommended to disable the popup within Halo and allow the browser to display the notification only, although both can be used at once.
Event Management module is now available
Event management is now available as a module in Halo. This allows data to be posted to an endpoint in Halo to create/update tickets based on rules, allowing for more customisable alerting.
The post must be made to https://{yoururl}/api/incomingevent/process.
You must post this with valid API credentials that have permission to edit events and tickets.
Event Rules
Event rules must be configured to create tickets from the posted data. These map values from the data using the same variable format as custom integrations.
You can configure multiple mapping variables and a variable to identify the ID of the alert. This is used later on to match update events to the existing ticket.
These mapped values can be used for the rule criteria. All criteria must match for a rule to be applied. Only one rule can be matched by an event and if an event fails to match any rules it will be ignored. Ignored rules can be re-processed as detailed later on.
Each rule has a set of outcomes to determine the content of the ticket that is created. This includes either a ticket type or template, whether actions added by updates are hidden from the end-user and mappings from the variables to ticket fields.
The following fields are currently supported:
- Custom Fields
- Summary
- Details (New Alerts only)
- Status
- Action Note (Updates only)
- Start Date
- Target Date
- Priority
- Urgency
- Categories 1 to 4
Event Management Area
If an agent has permission to view them, event management will show as an area in the Halo navigation bar. From here you can see logs for all events, including the date created, the matched rule, the ticket ID, and the status.
When clicking into an event you can see additional details, such as the body of the posted data.
If an event has not matched a rule, an agent with event edit permissions will have 3 options:
Re-evaluate
This will run the rule matching for that event again. This allows events to be processed if the rules have been updated since the time the event was received.
Create Ticket
This lets you select a rule, and the outcomes of this rule will be used to create a ticket, regardless of if the event matches the criteria
Link to Ticket
This allows you to choose a ticket to manually link the event to a ticket. None of the values will be applied from the event to the ticket, but the event will show in the ticket's event management tab.
These actions can be performed in bulk from the event management list.
Event Management Tab
This ticket tab will show all events linked to the ticket, with the same details as when viewing from the event management area.
Permissions
A new "Event Management Level" permission has been added. This determines if an agent can see the event management area and ticket tab and whether they can re-process/link events.
Additional Settings
There are 2 general settings "Number of days to retain matched event logs for" and "Number of days to retain unmatched event logs for" to determine when incoming event logs should be deleted. (Default 30 days)
Event rules are also config tracked, so can be exported and imported between instances of Halo.
Added service availability tracking
To enable this functionality the setting "Track service availability to monitor performance" in Configuration > Services must be enabled.
This adds the option to enable availability tracking per service.
Service Configuration
Once the setting "" is enabled, you can configure various options for the tracking. A "Target Period" can be specified as weekly, monthly, quarterly, or yearly. The "Target Uptime %" allows you to a target for each period. The percentage is based on the number of downtime hours vs the working hours for the period, which are based on the "Working hours to check" against the service. you can also specify "Days after period end to calculate period availability" to delay the calculation slightly to allow records to be amended.
Ticket Configuration
There are several ways to mark a ticket as downtime. The "Is Downtime" field can be added to the field list at ticket type level, to manually update the field. It can also be defaulted at ticket type level.
Rules can be used to set "Is Downtime" as an outcome. Rules and notifications can also be triggered from the "Is Downtime".
Downtime
When the field is set and the primary service of the ticket is set to a service that tracks donwitme, a downtime record will be created, with the start date using the date occurred of the ticket, unless a start date is specified. If the ticket is no longer marked as downtime, or the service changes, the downtime record will be removed.
Once the ticket is closed, the downtime will be marked as ended and a record will be created for every working day between the start and end dates of the ticket, with the end date being the date cleared of the ticket, unless a target date is specified.
Completed downtime will be visible on a timeline in the "Downtime Timeline" tab of the service.
Service Availability
Each day a scan runs to check if a service availability record needs to be created. If the end of the period plus the days to delay have passed, a service availability record will be created for that period. This will have the start and end dates for the period, the total hours in the period, the total downtime hours, the percentage uptime, and whether or not the target was met.
The availability records can be viewed in the "Availability history" tab of the service.
If a new downtime record is added for this period after the calculation, the availability will be recalculated.
Mailchimp Integration is now available
This integration will allow you to import the following data from Mailchimp:
- Audiences as Distribution Lists
- Audience Members as Users, and add the Users to the relevant Distribution List(s)
- Segments as Distribution Lists
- Segment Members as Users, and add the Users to the relevant Distribution List(s)
- Mail Campaigns, including open rates, click rates, unsubscribe rate and other statistics
You can also start the creation of a Mailchimp Mail Campaign from Halo, finishing off details in Mailchimp before sending.
To get started with this integration, you should enable the new Mail Campaign module by clicking the plus icon on the Module in the configuration area, along with checking the Distribution Lists module is also enabled:
Once enabled, ensure your Role/Agent has the required permissions for Mail Campaigns and Distribution Lists, under "Feature Access":
Next, navigate to Configurations > Integrations > Mailchimp
Click the "Login with Mailchimp" button and follow through the Authentication popup.
Once Authorised, you should see Authorised "Yes" at the top of the page.
Now you can begin to import data.
It is recommended to import data in the following order, so Users can be matched to the correct Distribution Lists, among other reasons.
Audiences > Audience Members > Segments > Segment Members > Mail Campaigns.
After a Campaign has been imported, some statistical data will automatically update within the Halo interface:
Other data such as seeing the specific Users which have opened a Campaign, will need to be imported. This is done with the "Mail Campaign" import you will have done previously. It is recommended to run the Halo Integrator application to keep the History of the Mail Campaign up to date. The history of a Campaign shows when a User was sent the Campaign, if they have opened it and if they have unsubscribed. This data can be reported on in the MailCampaignLog table.
A Mailchimp Mail Campaign can be created from within Halo by clicking "New" on the Mail Campaign List in Halo, giving a name and selecting Create in Mailchimp, and finally selecting the Audience:
After clicking Save, you will be taken to Mailchimp to continue configuration of the Campaign, before being able to send.
Additionally, a setting in the Mail Campaigns module can be enabled to show a Users Mail Campaign activity within their Activity feed, otherwise, the Users activity relating to Mailchimp Campaigns can be found on the "Mailchimp Campaigns" tab of their User record.
The ability to create Mail Campaigns within Halo is coming soon.
Virima integration is now available
A Virima integration is now available, allowing for the import of assets.
To use this integration you must generate an API key and know your Virima tenant id. You then need to enter the URL for your Virima instance, as well as the key and tenant ID to connect the integration.
Site Mappings
Virima does not have a concept of sites or customers, so to determine which site an asset should be created against you can use site rules. These rules are based on field values, and if matched will assign an asset to the site of the mapping.
The user of an imported asset will be matched to a user based on their email address. This matching will be done on the username, email, and network login fields, and you can specify an additional field to try matching on as well.
The matched user can be used to override the site mapping.
There is also a setting to not change an existing asset's site.
Asset Imports
All types of assets will be imported from Virima. All fields can be mapped from Virima to Halo, with the option to manually specify a field name if required. Software is also imported for each asset, with an option to match these to customer licences.
The asset types of the assets can either use a fixed type for all assets, be determined from one of the fields, or use asset type mappings that are determined using rules based on the values of the mapped asset fields. The mappings can either use a specific type or use a field to determine the asset type.
If none of the rules are matched, a default asset type will be used, which can be configured to not allow the import of any assets that don't match any of the rules, allowing for certain assets to be excluded from the import.
Asset relationships can also be imported from Virima, with a future update also allowing the Vivid relationship diagram from Virima to be displayed as a tab on the asset in Halo
Additionally, there are settings to: deactivate assets deleted from Virima and what status to set them to when doing this, not create new assets, not update existing asset types, and the status for new assets.
Assets can be imported manually or on a recurring schedule using the Halo integrator. When using the integrator, only assets updated or created since the last sync date will be imported. You can clear the last sync date if required.
Improvements to the Exchange Calendars integration
The new functionality is only available when using the Graph API connection method, combined with an Azure application that uses application permissions.
Immutable IDs
Immutable IDs can now be activated for this integration. This prevents issues caused by the ID of an Exchange appointment changing when certain properties on the appointment are changed.
Additional permissions must be granted to your Azure application to use this functionality.
Webhooks
Webhooks can now be configured to receive instant updates for Created, Updated, and Deleted events from Exchange.
As highlighted on the setup screen, subscriptions for an agent will be created/deleted automatically when toggling the integration on/off in their preferences. Any active subscriptions will be renewed either when a webhook is received for an event for that agent, or daily via the task scheduler.
You can manually manage the subscription for each agent in the table provided. The Add button also contains an "All" option to create a subscription for all outstanding agents.
Note: Immutable IDs must be enabled to use the webhook functionality.
General Improvements
The integration setup screen has now been split into tabs to more easily manage the configuration.
An inbound and outbound request tab has also been added for better visibility of the webhooks received and the requests made by the integration.
Improvements to integration Runbooks
New features have been added and improvements have been made to Integration runbooks. These improvements are aimed at making runbooks better suited to bulk imports and longer syncs, improving their performance and making them easier to configure for this purpose.
1. Runbook-Level Variables
A new entity has been added to Runbooks called Runbook-Level Variables, which behave similarly to Input Variables and Output Variables, but offer new options and are better optimised for long-running tasks.
These variables are available for all types of Runbook.
You can define a new variable from the Runbook configuration screen. The initial value of a variable can be;
- Empty
- A constant object, array, string, integer, float, boolean or datetime.
- Calculated from the initial payload that started the runbook (for runbooks launched via a public endpoint)
- Calculated from ticket/action/asset/user values (for runbooks launched from the relevant entity)
Instructions detailing what can be used are shown on the Runbook-Variable input screen.
The value of these variables is calculated when the runbook begins and persists across the lifetime of the runbook run, rather than being calculated whenever it is used like Input and Output variables.
The value of these variables can be changed based on the result of an integration method or Halo API action by adding "Runbook-level variable mappings". These can fulfil the same functions as Output variables except they are declared on the runbook itself.
All Input variables have been migrated to runbook-level variables as part of the upgrade and input variables have been removed.
2. Constants and using other Variables in Runbook-Level Variables
Runbook-level variables accept the input of constants opening up new use cases.
For example you can declare a pageSize and pageNo variable at runbook level and set the values to an integer, and use them in integration methods, rather than hardcoding the values inside the method itself.
These variables can also be set to other variables, or used to join multiple variables.
E.g Set the value to <<response^string1>> <<response^string2>>
3. Calculations in Variables
Furthering the use-case of runbook-level variables, you can now perform basic arithmetic in variable values using the ##calc## operator.
Open a calculation using ##calc## and end it using ##/calc##.
An example use case would be to increment a <<pageNo>> variable in a while loop. E.g ##calc##<<pageNo>> + 1 ##/calc##
4. Object Mapping Profiles
You can now easily map an object or array of objects to a different format. This allows you to convert a response from one API into the format required by another API all in one step.
Inside a Runbook-level variable mapping for an Object or an Array variable, set Extra Value Processing to "Cast to an object of another type". You can then build the mapping using the <<obj>> variable to refer to the original object.
When the variable value is calculated the mapping profile is applied meaning the variable is in the new format ready to be used in the next method.
Datetime runbook-level variables can now be set to either the current time in local time or the current time in UTC.
This can be used to pass deltas to APIs.
6. Persistant variables
Building upon the new date variables, a runbook-level variable value can be persistent between runs of the runbook.
This allows you to hold a delta / last-sync-time in a variable that remains set on each run of the runbook.
For example, declare a variable <<lastUpdate>> which is empty by default and make it Persistent. Use it in a method to send a "last_modified" parameter to the API. After the result of a method, set it to $-utcnow. Now when the runbook next runs last_modified will be the date the runbook previously ran.
To be even more precise in the above scenario, declare a second date variable <<nextUpdate>> and set this before the method runs. Then set <<lastUpdate>> = <<nextUpdate>> once the runbook finishes running.
7. Not equal to Array operator
Similar to the response[field=123] operator, you can now use response[field!=123] to find an element where "field" is not equal to 123.
You can use this with the new Batch Response in point 10 to detect if any items in the batch failed.
8. String Variable Escaping
Improvements to string variables in JSON payloads so they are escaped when appropriate
9. Iteration in Batches
Iteration steps now allow you to iterate multiple elements of an array at once. The iteration variables are an array instead of an object when doing this.
This allows you to more easily batch post responses from APIs into Halo API actions, making the runbook more performant.
This is configurable on the Array Iteration Start step.
10. Bulk Response for Halo API Actions
When bulk posting into Halo API Actions you can now return the response as an array containing the status code of each operation and the response.
Enable this from the Halo API Action Step - Return batch response
11. Runbook Performance Improvements
Variable caching for Runbook-level variables, Iteration variables and Output variables have been implemented, reducing the amount of time it takes to calculate variable values use them in methods, particularly for bulk operations. Various other minor performance improvements have been also made to variable population in Runbooks.
12. Easier third-party-id matching in Halo Entities
Halo entities that support third party id matching now accept a "_match_thirdparty_id" and "_match_integration_name" property.
Set "_match_thirdparty_id" to the id in the third party system and "_match_integration_name" to the name of your integration.
This will be used to perform a match when posting and update the existing record in Halo if the third-party-id already exists for the integration.
These are included in the sample Halo API Method payload for supported entities.
13. Max While Loop Iterations
A setting has been added at Runbook level for "Infinite loop detection threshold".
This allows you to lift the safety net for loops (repeat operations on the same step) in runbooks once you are confident that your runbook cannot cause issues. This defaults to 5.
This also allows you to test integrations that may do a lot of loops to fetch pages of data in a safe way.
14. Stop button
A stop button has been added to the Automation Runbook Log screen. This terminates the Run at the next possible opportunity.
15. Calculate Variables Step Type
A new runbook step type of "Calculate Variables" has been added.
This allows you to recalculate a Runbook-level variable without using a method response.
Various bug fixes and minor improvements have also been made to Runbooks. Improved trace logging for Runbook runs.
Added Contract Signing
You can now allow customers to sign Contracts using the new $-CONTRACTAPPROVAL variable. Adding this variable to the 'Contract Email Subject' template will generate a secure link to the Contract, where it can be signed:
You can add the $-CONTRACTAPPROVERNAME, $-CONTRACTAPPROVEREMAIL, and $-CONTRACTSIGNATURE variables to your Contract PDF to display the field values entered above. The Contract PDF will be regenerated after the Contract is signed.
You can also use the 'Enable secure Contract signing' option in Configuration > Contracts to only allow the Contract Contact of the Contract the ability to sign:
Added the ability to manage Microsoft Teams chats from within a Ticket
The functionality can be turned on within the Microsoft Teams integration setup screen on the Chat Management tab.
Once enabled, you will need to create a new Azure application and authorize it within the setup screen. It is recommended that you create a specific user in Azure for this purpose, as the user will be added to all chats created from Halo, and any messages sent from Halo will also be sent from this user.
The application requires a mixture of delegate and application permissions. The application type permissions are required to create subscriptions via the Microsoft Graph API for chats that are created.
The option to enable the ability to see and create new chats is then turned on at Ticket Type level. There is also an option to specify a default name for new chats that will auto-populate on the creation screen, which overrides the global setting found in the integration setup screen.
There are two ways of managing Microsoft Teams chats from within a Ticket.
Ticket Tabs
To enable this functionality, you must enable the following setting at Ticket Type level. Whenever a chat is created, a new individual tab will display on the Ticket for each chat.
To create the chat from within a Ticket, hover over the quick action menu and select the Create Microsoft Teams Chat option. Note that this option will be available on the Ticket regardless of whether the above setting is enabled.
This will display an input screen where you can configure your new chat.
The user who authorized the integration will be automatically added as an owner of the chat during the creation. Only user(s) imported via the Azure Active Directory integration can be added as a member.
Once the chat is created, a new tab will display on the Ticket. As part of the chat creation, a subscription to the chat will be created so that any new messages added to the chat from within Microsoft Teams will be automatically imported.
Using the plus icon in the top right hand corner, new messages can be sent to the chat from Halo. Any message sent from Halo will show in the message list as being sent by the user who authorized the integration, but a sub header showing the agent who performed the action is also shown for auditability.
Custom Dashboards
A new widget type called Microsoft Teams Chats can be added to a custom Ticket dashboard.
The widget will display all chats created from the Ticket in separate tabs, but all within the widget. A new chat can be created when viewing the widget by clicking the plus tab option. The functionality within the widget is identical to the Ticket Tabs method.
A background service will renew any chat subscriptions that are close to expiry on open Tickets. Once a Ticket is closed, the subscription will no longer be renewed and new messages will no longer be imported from Microsoft Teams.
Various improvements to OLAs
OLAs can now be linked to rules. This can either be configured from the OLA or from the ticket rule.
If one of the linked rules is matched, and the workflow is on one of the start steps/stages for the OLA, the OLA will be started against the ticket.
If the rules stop being matched before the OLA is completed, it will be paused. OLAs can be resumed if any of the rules are matched again. All in-progress or paused OLAs will be completed when the ticket closes.
A tab will now show on tickets with OLAs against them, showing their target date, status, and if they were met or not.
