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
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.
Additional Field Restrictions on Assets
Introducing the ability to granularly restrict access to system fields in the Asset Management module - this includes fields such as Site, Status, Criticality, Type, Priority, etc.
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.
Ticket Creation on Mobile App
Ability to display new ticket forms on mobile app.
Search for Settings in Configuration
Allow for individual settings to be searchable in the Configuration module.
Searching for multi-select fields
Ability to search for individual values in multi select Drop-Down field.
AWS OpenSearch (AI Search Index for Hosted Customers)
Introducing a Vector database for AI Search and Virtual Agent to be hosted within Halo AWS infrastructure.
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
Various improvements to configuration items
To improve the functionality and ease of use of configuration items in Halo various improvements have been made. To enable this new functionality the setting "Allow automatic linking of Assets and Services" in Configuration > Services must be enabled.
This allows configuration items to be managed as one single entity whilst functioning as both an asset and a service.
NOTE: If using access control for either assets or services, access control will be enabled for the other entity upon enabling this setting.
Asset Type
Asset types now have 2 settings for "Is Service" or "Is Business application". They can only be one of these at a time. These settings can only be set for new asset types and cannot be changed once set.
When enabled, the asset type can then be linked to a service category that the services linked to assets of this type will be part of.
Additionally, asset types can now have related services. These will be inherited by any assets of that type. This can be used for any asset type, not just the ones linked to services.
Assets
When creating an asset of one of these types, a service will be created that is linked to this asset. The following fields will be inherited from the asset to the service:
- Asset Tag to Service Name
- Business owner
- Technical owner
- Criticality
- Notes
- Related Articles
- Related Assets
Additionally, if an asset "Is a business application" then the related service will have the following setting on:
- Is a Monitored Service (Track Service Status)
- Show in Service Catalogue for End-Users
- Allow Subscribers to log Incidents
Whereas, if an asset "Is a Service" these settings will be off.
All other fields, including custom fields, will be shown in tabs against the asset, so the service and asset can be managed from one screen. These tabs will only show against assets that are linked to a service and can be reordered using tab layouts.
All the same options that are available on a service, such as logging a ticket or emailing all subscribers, are available on the asset as well.
Once an asset has been created with one of these types, the type cannot be change to one that is not either a service or a business application.
Service
If creating a service from the services area of Halo, it will not have the option to be linked to an asset. Additonally, if you click on the record for a service linked to an asset it will take you to the asset screen to manage the details.
Tickets
With this functionality enabled, the related services field on tickets will be restricted to only ones linked to assets.
If an asset is related to a ticket and it is linked to a service, the corresponding service will be related to the ticket.
Similarly, if a service is related to a ticket or set as the primary service and it is linked to an asset, then the asset will be related to the ticket.
Any child assets of a related asset that are marked as a service or a business application, will also be related to the ticket along with their services.
The primary service, related assets, and related services fields can also be renamed per ticket type.
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.
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.
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.
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.
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:
AT&T integration is now available
AT&T integration has been added to the 'Product Catalogs' integration group:
API credentials are required to set this up and are sourced from AT&T directly. A default vendor and product group must be selected to create new products under when adding AT&T products to quotations.
With the module enabled a new button to "Add AT&T product" will appear on the quote details screen. This opens a search screen so that you can see what services AT&T can offer at your customers specific site address. All segments of the address must be populated before searching; this is filled out automatically if the address is already set on the quote.
Using the "compare" filter option applies visuals to results returned from AT&T to be able to quickly compare key characteristics as well as display pricing differences:
Once an AT&T product has been selected, this will be added as a line to the quote and created in Halo as a monthly recurring product.
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.
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.