HaloITSM Roadmap

Report "Query Builder" added

Basic ticket and action reports can now be created without using SQL by using the "Query Builder" Datasource option.

Selecting this option will prompt you to choose an entity to report on, currently either Tickets or Actions.

Ticket fields and fields for linked entities (e.g Client, Agent, TIcket Type) will then be available in the Field list. Add the fields you want to see in the report. Fields can also be renamed by editing them.

Conditions will show underneath the Fields. These work like report Filters except the field does not have to be in the Field list to filter on it.

A query is built from the chosen entity, fields and conditions, and all report features are supported with the Query Builder method. The query which is built can be seen by changing the datasource to "Write a custom query" after the report has been run.

Scheduled Reports using the Query builder require NHServer version 13.53+ to run.

Available fields and entities will be added to over time.

Redesigned the Twitter integration

Each Twitter account that you connect to Halo can now turn direct messages and mentions into tickets.

Direct Messages:

By enabling the creation of tickets via direct messages, your Twitter account will be automatically subscribed to webhooks that will be sent to your Halo instance.

An action can be created with a system use of Reply to Twitter Message/Mention. This action can be used to send a reply via Twitter on tickets created from both direct messages and also mentions.

An option has been added for each connected Twitter account to decide whether or not a ticket should be reopened if the same user sends another direct message to your account. 

Mentions:

Similarly to direct messages, by enabling the creation of tickets for mentions, your Twitter account will be automatically subscribed to webhooks that will be sent to your Halo instance.

Whenever your account is initially mentioned by a user, a new ticket will be created. Any replies to this mention will then be converted to actions and added to the ticket. 

You can set a limit on the number of days after a mention is created for replies to continue to be threaded to the ticket. You can also choose to include/exclude certain mentions by adding to a list of words/phrases.

If a reply has been added to a reply, the action will show a thread for the reply chain. You can reply to individual replies by selecting the Reply to Tweet option on the action:

This option doesn't show for the initial message - to reply to the initial message, you must use an action with a system use of Reply to Twitter Message/Mention.

You can also move a reply to a separate ticket. Any future replies in the chain for that reply will then be added to your new ticket.

All existing functionality for the Twitter integration has now been removed.

Added support for SMS inbound via Twilio

The Twilio integration screen has been overhauled so you can now configure the SMS outbound settings from this screen, rather than clicking a button and going to a separate screen.

 Options have then been added to enable inbound SMS via Twilio. This requires the configuration of Twilio webhooks.

When the first SMS message from a phone number is received, a new ticket will be created. Any subsequent messages from the same number will be threaded to the same ticket and added as an action.

The new ticket form can now be embedded on external web pages

If anonymous usage on the self-service portal is enabled or anonymous usage is enabled for a particular ticket type, on the ticket type details screen, information will be shown regarding how to embed the form on an external web page.

The embedded form will log a new anonymous ticket. The majority of system fields and all custom fields except from tables are supported.

Properties that can be specified in haloFormConfig are listed below. Only haloApiUrl, ticketTypeId and ticketTypeKey are required.

Added the option to create recurring appointments in Halo and sync them to Exchange

You can now find an option to mark any appointment as recurring whilst creating if you have Exchange Calendars enabled. This will then show a Create Schedule button, allowing you to create a schedule for the recurring appointment.

These master appointments only appear in the calendar if you have the following setting enabled:

Once this recurring master appointment has been created, when the next Exchange Calendar sync is performed, all the child appointments will be synced into your calendar.

Recurring appointment creation is currently only possible when integrating with Exchange Calendars.

Nagios XI integration is now available

New tickets can be created from Nagios XI alerts. Warning and Critical alerts from Nagios XI will create new tickets. These raised tickets can be set to a specific ticket type and user. The priority can be configured depending on which alert severity is received.

Alert updates will be put as actions on the raised tickets. Once an alert has returned to the OK status the ticket will be closed and a detailed action will be added.

Asset matching can also be applied to these created tickets. If the corresponding returned field matches the chosen field in Halo it will relate that asset to the ticket.

The password field is to be used within the 'Command Line' field that will need to be populated in Nagios XI. The Host-Alert and Service-Alert buttons detail what exactly is needed when creating the webhooks in Nagios XI.

Improvements to the SAML integration

The setup screen for the SAML integration has changed to accommodate many new features.

1. It is now possible to upload the metadata XML file from your identity provider which will automatically configure the login URL, logout URL and certificate thumbprint fields.

2. It is now possible to download metadata for Halo's SAML implementation so that it can be automatically uploaded into your identity provider if your identity provider supports this. 

3. The IdP Configuration button opens a popout window showing the values that are required to manually configure your SAML implementation in your identity provider if you cannot upload a metadata file.

4. A new endpoint has been added to the Halo authentication server which should be used for all new SAML implementations. The old existing endpoints remain available for anyone currently using them. This endpoint does not yet support encrypted assertions - this will be coming soon.

5. You can now choose the colour of the login button, as well as a logo that should display on the button should you wish.

6. You can now sign all requests that are sent from Halo to your identity provider.

7. Support has been added for click-to-access logins from the identity provider i.e. the SAML login flow does not get started from Halo, and instead, requests are sent straight from the identity provider to Halo with no InResponseTo value in the request.

Improved Config change tracking and Transfer of Configuration from UAT to Production environments has been added (Hosted Only)

Enable "Enable config change tracking" in Config > Advanced Settings.

With this setting enabled, for supported entities a snapshot of each config change that is made is captured, along with a roll-back script (where possible). These config changes can be viewed in the app from Config > Advanced Settings.

This new change tracking applies to the following entities;

• Global settings
• Enabled modules
• Ticket Types
• Statuses
• Action config
• Workflows
• Templates
• Service Catagories
• Services
• Custom Fields
• Custom Tabs
• Custom Tables
• Field Groups

This list will be expanded upon in future.

This icon will display in the top right of details screens where change tracking is active;

The Config Changes list serves as a way of auditing config. Config changes are listed from newest to oldest.

From the list, you can bulk-select commits and export them to a JSON file. Commits can be imported from this screen as well, serving as an easy way to move config into another instance of Halo.

The supported entities now have their own unique IDs, allowing relationships to be maintained between entities when importing changes to different instances. In other words, the usual integer primary key is not used to link the entities together, it is instead using a new unique GUID for each row.

Commit details can be viewed by clicking on the list. This shows details of the API request that was made and the rollback API call. DELETE's cannot be rolled back.

Config changes involving password fields and sensitive information will be encrypted and details will not show.

On this screen, you can "Rollback before this change". This will revert each change made after the selected change sequentially, along with the change you have selected, restoring the config to the point it was at before the change was made.

Expanding upon this, hosted customers with both UAT and Production Halo environments will now see a new Config option for "Instances". Config > Instances will list each of your linked Halo instances, along with config differences between the current instance.

An instance will be classified as in-sync once it matches the version of the current instance, and a UAT restore has been performed from the production environment for the first time after the production environment is on v2.104.

For instances that are in sync, you can view the config differences between the current instance and the selected instance from the instance details screen. Changes can be Pushed to the selected instance, or Pulled onto the current instance from the "Changes Behind" and "Changes Ahead" tabs. This replicates the same API request that was made for the changes in the other instance for each commit sequentially from the oldest first.

For non-production instances, a "Restore from Production" button will also show on this screen. Use this button to log a request with Halo Support to update the UAT instance with the latest production data.

Added roles for users

Similar to agents, users can now be given roles. The user roles are separate from agent roles and can be used to set permissions such as: web access level, service access level, can partake in approvals, etc. A user can have multiple roles.

For each of these, the user's permissions will take the highest value from their roles and user permissions. 

The Azure Active Directory and Active Directory integrations now allow you to map roles to users on import.

Approval process approvers, service restrictions and subscribers, user action restrictions, and portal button restrictions can all be set based on user roles.

Added the ability to make dashboards available to users in the self-service portal

When configuring an in-app dashboard, you can now allow access for users. This can be allowed based on the user or their site, customer, department, or organisation.

You can then add the 'My Dashboards' section to the portal to allow users to view a list of all their dashboards.

Alternatively, you can publish the dashboard with a specific link, so that users can go directly to the dashboard, regardless of the user access permissions. If anonymous portal access is allowed, this link will allow them to view the dashboard without logging in.

When viewing a dashboard as a user, the 'ticket List' and 'Ticket List Counter' widget types will not be displayed.