When a user spots a fault with a specific device, they know exactly which asset is affected. Getting that information into a ticket has always required them to navigate away from the asset record, open a fresh form, and re-enter the asset details from scratch. The result is tickets that arrive at the service desk with blank CI fields or the wrong asset attached, because users skip the step or guess.
Version 2.236 of HaloITSM introduces a ticket-logging option directly on asset records inside the Self-Service Portal. Administrators assign a default ticket type to a Configuration Item type or Asset Type. Once that setting is in place, users browsing asset records on the portal see the option and can raise a ticket in a few clicks, with the asset already attached. The ticket arrives at the service desk pre-linked to the correct CI from the moment it is created. The full release detail is in the Halo release note.
The change is not cosmetic. Before this, asset-to-ticket linkage depended on users filling in optional fields correctly under time pressure, and that rarely happened consistently. Now the link is made at submission, not during triage. Agents spend less time chasing down which device a ticket relates to. Team leaders get incident counts per asset that are accurate from day one, not after a clean-up run.
For management, that means asset lifecycle reporting starts reflecting reality rather than partial data. Incident volumes per device become trustworthy enough to act on, whether that is identifying repeat offenders, justifying a refresh cycle, or challenging a supplier on a model that keeps failing.
End users Raise a ticket against a specific asset in fewer steps, with no need to remember or re-enter the CI name or serial number.
Service desk agents Tickets arrive pre-linked to the correct asset, reducing the triage time spent identifying the affected CI.
Team leaders Asset-to-ticket traceability is consistent from creation, improving accuracy on per-asset incident reporting.
Management: Incident and request data is mapped to the asset register from the moment a ticket is raised, supporting accurate per asset volumes and lifecycle decisions.
Enabling this is low effort. An administrator assigns a default ticket type to a CI type or Asset Type. It is a settings change on existing records, with no schema migration and no development work required. Four things need to be in order first:
The heavier work is not in the feature itself. It is in CMDB accuracy. A half-populated asset register means the option appears for some assets but not others, producing an inconsistent experience. Teams that have not maintained their CMDB will need to address that before this feature delivers consistent value.
On licensing: Halo's published model includes asset management in every agent licence at no additional cost, and no edition restriction on this specific feature has been documented publicly.
A few practical points worth knowing before you configure this.
The feature is portal-only. Users reaching the service desk by email, phone, or Microsoft Teams still need the asset association added manually. This does not close that gap.
One default ticket type is assigned per CI or Asset Type. If you want users to choose between logging an incident and raising a service request for the same asset category, the current design does not obviously support that without a workaround such as a single umbrella ticket type with branching logic.
CMDB accuracy is a hard dependency in both directions. Accurate records produce accurate ticket linkage. Stale or duplicate records produce noise, and this feature will amplify whatever data quality currently exists in your asset register.
Agents logging tickets on behalf of users do not appear to have the same one-click path from an asset record. The feature is targeted at end users on the portal.
Many Halo customers have assets in the system but have not configured portal-facing asset views, which means this feature sits unused until a setup step most teams will not know to take. As a Halo partner with coverage across the UK and Israel, Hikon can review your current asset register state, configure CI types with appropriate default ticket types, and check portal asset visibility as part of a post-go-live optimisation engagement. If your CMDB needs attention first, that is a workstream Hikon handles as standard: asset data design is part of how Hikon structures Halo implementations, not an optional extra.
The full release detail is in the Halo release note. If you want to talk through what this means for your setup, get in touch with Hikon.
Talk it through with the people who wrote it — a free 20-minute call, no pitch.
Let's talk →Book a free 20-minute call about your platform and your plans — no pitch, no obligation.
Start the conversation