Feature Ideas

A full functioning mobile app that doesn't require you to go to the browser version on your phone for 90% of your needs.

When entering time at present It must be one contiguous block that is either all billed or all not billed. Depending upon global settings it can be defined by a duration and end time, or by start and end time. But there is no way to account for other overlapping time entries. A time-tracking field that lets you enter an amount of time to deduct from a time entry without changing the start and end times would allow for this and avoid a lot of tedious small time entries. For instance, a servicedesk tech working on one matter (ticket A) gets interrupted by a call (ticket B). They handle the call, make a time entry for that, and return to the first task. In the current system, they will end up billing the duration of the call to both tickets A and B unless they make separate time entries for ticket A before and after the call (ticket B). Importantly, this gets a lot worse when that agent is interrupted more than once. With a deduction field, the tech makes their time entry for ticket B when they take the call. Then when they make their entry for ticket A, they enter the correct start and end times and then take the duration of ticket B and enter it in the deduction field. The number of time entries required to bill (or not bill) all time correctly reduces a lot and ticket notes are simpler and more readable. On top of that, an option to automatically deduct the duration of overlapping time entries would make this super simple. This could be a button or checkbox next to the deduction field that automatically calculates the deduction upon request.

Currently an action only allows the ability to make the agent a follower of the parent ticket. We would like for this to be an option for the child ticket created from an action button so that agents are able to follow a child ticket in teams they don't have access to. Currently agents have to manually add themselves as a follower on a child ticket and if they forget they lose the ability to add themselves later resulting in them having to contact the team to do this manually.

Current state The Self Service portal currently supports CSS overrides via the configuration settings. While this is useful for basic brand alignment (colors, fonts), it is limited to style adjustments on top of the existing portal structure. The underlying HTML cannot be modified, which means the layout, component hierarchy, and DOM structure are fixed. Requested improvement We would like the ability to fully customize the Self Service portal at the HTML level — either by editing the underlying templates directly, or by providing a way to inject custom HTML blocks alongside the existing CSS override functionality. Ideally, this would allow us to rebuild the portal layout entirely from scratch while still leveraging HaloPSA data (logged-in user context, ticket lists, asset data, etc.) through available template variables or data bindings. Specific capabilities requested Edit or replace portal HTML templates directly, not just overlay CSS on top of the existing structureControl over the layout structure, header, navigation, content areas, footer. Without depending on the default component hierarchyAccess to Halo template variables in custom HTML (e.g. current user name, company, ticket count) to enable dynamic, data-driven layouts Business case MSPs operate across multiple customers with different branding requirements. As it stands, all customers share the same portal structure, only colors and fonts can be differentiated. Full HTML/CSS control would allow us to deliver a genuinely white-labeled experience per customer, improving portal adoption and customer satisfaction. It would also allow the portal to be redesigned to match modern UX standards rather than being constrained by the default layout.

My first EOFY with Halo, and I wasn't able to run a stocktake. I can belive how they dont have this built in. No way to go and count all your in stock hardware and make sure its all accounted for. Im sure I cant be the only shop that uses halo and has stock that needs to be chaecked each year (or should be more frequently). Im not even in retail and this is a need. Anyway, support said just run a report and check it off. It would take far too long to count everything and manually match it off against a list. Instead, I knocked up this stocktake app that pulls in all the stock and allows me to just scan everything with a barcode scanner to count it. Spent a couple hours making it and then only an hour or two stocktaking. Much quicker and a far better result, as I am able to get reports out of it and reasons for missing stock. It counts serial numbers too, not just item quantities, so I can verify that everything I think should be here is actually here. Syncro had something like this built in, which is where my inspiration for how this operates came from. I would love it if Halo could implement this as a module, but in the meanwhile, maybe this can help others. https://github.com/ElliottsTech/Halo_Stocktaker

Some clients have multiple sites, and each site may normally receive its own invoices. However, there are situations where a different site needs to be responsible for paying a specific invoice. It would be helpful to have the ability to select or override the billing site at the invoice level. This would allow a one-off invoice to be assigned to a different site without changing the client’s normal billing setup or site-level invoice configuration.

Create an Agent permission option to allow re-enrolling users MFA. Currently this can only be done by Sysadmins

Allow more depth knowledge base settings, Allowing sub categories within an existing parent category Linking articles to customers, one or multiple without having to grant a customer a whole category in Halo article template types - templates for agents to select from when adding articles

Exposing an audit api or some form of exporting audit logs to a SIEM platform would allow us to monitor the instance and have a separate record of accountability. If there was an API to poll, we could develop a job to poll the latest auditing data of the instance, or if there was a streaming capability of the instance to syslog or to a webhook would also work to capture the instance activities of users and agents. We currently capture data from our WAF/ZT service as well as IIS logs, but from the application itself would provide context from the system point of view.

Please add feature to self-service portal to print tickets to PDF. Same feature as in agent portal.

The stock history tab doesn't show a full accounting (at least not clearly) of which location and bin and item has been move from and then which location and bin it has been moved to. It's largely text based which makes it unfriendly for reporting.

Language support for date variables should absolutely be a standard feature in Halo — but it isn’t. Surprisingly, there’s no support for it at all, which is especially strange since we can translate month names in the language file/pack (!!). Hence this feature request. If Halo supported language-based date variables, it would allow displaying month names in plain text on recurring invoice headers, recurring invoice items, and many other places throughout the system. Right now, we can use MMMM to spell out the month name, but it only outputs the name in English. I see two straightforward ways to fix this: The SQL way: {MMMM, 'sv-SE'} → Oktober {MMMM, 'es-ES'} → octubre {MMMM, 'zh-CN'} → 十月 The Halo language file ID way (likely better): {MMMM, 'langID=8'} → Oktober (languages?id=8) {MMMM, 'langID=11'} → octubre. (languages?id=11) {MMMM, 'langID=18'} → 十月 (languages?id=18) Really hoping this gets some positive attention — it would make a big difference! 😊

Techs use a templated ticket with To List Items. Each to Do List item is also a hyperlink that can be linked via hyperlink to either an internal knowledge base article / process, or externally to an SOP (in our case Hudu).

It would be helpful to be able to create pages on dashboards to allow a separate set of widgets for each page

When load balancing tickets, if there's a queue of tickets, it would make sense for it to pick the "next" ticket with priority and SLA time remaining as part of the weighting. For instance a higher priority ticket should be chosen before lower priority, but if a low priority ticket is about to breach SLA, it should probably choose that one first.