Feature Ideas

You can't easily move around the email addresses when emailing from a ticket. It would be great if you could drag someone from CC and drop into the To section without having to search for that user and delete the other one.

Could you please build a Microsoft Copilot Connector that allows interaction with all the data in Halo?

Ticket notes & draft emails, etc. should autosave to the tickets in case of a browser refresh or crash. If you had started writing notes and then refresh the ticket page then you should have a button or option to reload what you had last typed in there instead of needing to start over. I'm a new Halo user coming over from Syncro and this is the most basic feature that Syncro has and Halo is missing. I've lost a few draft ticket notes already but I'm sure many of you have lost many more. Ideally this would work in forms outside of the service desk as well, in the knowledge base, in the self-service portals, etc. All of those rich text and really any field should be autosaving while you type so if you refresh then you can click a button to get back what you had.

In HaloPSA Timesheets, we should be able to enter the Start time and End times via keystrokes on the keyboard and without having to click scroll through the time scroller for both the hour field and minutes fields to add in our times. We should also be given a field to deduct time when staff need to enter a block time in with other tickets \ tasks completed during this block time in a working day. This archaic front end is a relic of the 1980's, is inefficient + cumbersome, and cost us time.

When a ticket is in scheduled status, do not change status of ticket to updated when client responds with a "thank you," "ok," or similar response in acknowledgement to their scheduled appointment (in the same way which closed tickets remain closed after receiving these kinds of responses).

As an MSP, we want our service catalogue to show only the services a customer or user is entitled to. Services like 3CX, Adobe or Jira should appear only for customers or users who have that software, because that's what they pay us to support. If a customer doesn't have 3CX, they shouldn't be able to request 3CX support, and a ticket shouldn't be linked to the 3CX service. Currently, a service's User Access can only be restricted by Everyone, Site, Customer, Department, Organisation, Role, Top Level or certain user fields. None of these options can use assets, software or licences, even though Halo already holds that data. The other service settings don't cover this either. The Assets tab (Associated Asset Type and Linked Assets) only links assets to service failure tickets for monitored services, Subscribers is for status updates, and Optional Services adds extras to a request. None of them control who can see or use a service. The same entitlement logic should apply when reclassifying a ticket. When an agent changes the service on an existing ticket, the available services should be filtered by the ticket user's access, just like when creating a new ticket, or at least show a warning when the selected service falls outside it. It would be great if a service's User Access could use asset, software and licence based criteria alongside the existing options. For example, a service could be shown when the customer has at least one asset of a given asset type, or when the user has an assigned asset of that type. It could also be shown when the customer or user has a specific software or licence record, including licences synced through integrations such as Microsoft CSP or Entra. The same entitlement logic should apply in the agent application. Ideally, the service selection on a ticket, including the Related Service Catalogue field, would be filtered by the ticket user's access, or at least show a warning when the selected service falls outside it. Together, these changes would mean that only services a customer or user is entitled to can be requested or linked to their tickets, which cuts down on invalid requests and incorrect service links. Catalogue visibility would stay in sync with what customers pay for without any manual upkeep. Because Halo already stores this asset and licence data, it would also keep billing, reporting and support entitlement aligned, and it would remove the need for custom scripts and API workarounds for something that feels like it should be native.

Just like using the @ in a ticket will bring up the ability to reference a user I would like to see similar ability to reference another ticket ie.. @ticket# or something like this which will make it a hyper link.

Timesheets in bulk are difficult to manage, and the views over a month are too much, even weekly having a team of 15 and a single timesheet manager, it becomes chaos and borderline pointless, often just hitting the final 'approval' button that does all at once for that date period. Not show weekends when viewing a month/only show working hours/days as a viewFilter by approved/unapprovedNotifications when timesheets submittedMultiple timesheet managersRejection comes from the timesheet manager, not the Helpdesk email addressTrigger warning when 'approving all' to warn that all items are about to be approvedFreeze the name and date column/row so the engineer's name and date always stay visible.Billing is typically done monthly, so the option to just view that month/week would be amazing, not having to select start and end date, and then re-select the date range because clicking 'next' retains the days selected, ( for example 28 days selected, clicking next will select the next 28, not the entire month if there are 31 days)

A team can only have one registered Timesheet Approver, which makes absence approval a single point of failure. We'd like to be able to assign more than one approver per team. Current behaviour A team can have only one registered Timesheet Approver. The role cannot be shared across two or more people.If that approver is unavailable (for example on leave), no one else can approve the team's absence requests. Swapping in a different approver does not help either: because a request is tied to the approver at the time of submission, pending requests stay locked to the original approver and the employee has to submit a new request. Requested improvement Allow multiple Timesheet Approvers per team (or an approver group / role-based approval), where any of the assigned approvers can action the team's absence requests, including requests that are already pending. Why it matters With a single approver per team, approval stops the moment that person is away, and there is no clean way to hand requests over. For organisations managing many teams, including MSPs managing multiple customer tenants, being able to assign more than one approver keeps absence approval running without manual workarounds. This would also resolve a related auto-approval problem. Today, when a team has no approver, absence requests are auto-approved with no review, and removing a team's only approver silently auto-approves any pending requests. With two or more approvers assigned, removing one would leave the others in place rather than dropping the team to zero approvers, so requests would no longer be auto-approved unintentionally.

Upon returning from a recent trip, I designated another team member as ‘team leader’ and ensured they had full permission to manage timesheets. However, I discovered that while they could make changes to timesheets, they were unable to approve or reject them. This limitation led me to consider the implications of having only one person authorized to approve timesheets. In scenarios where the designated approver is unavailable due to leave, illness, or unforeseen circumstances, our ability to process invoices is significantly hindered. The current process of changing the approver can be cumbersome and time-consuming, which can delay critical operations. To address this, I propose the introduction of an ‘Additional Approvers’ feature, similar to the existing ‘Additional Agents’ option. This feature would allow multiple individuals to have the authority to approve or reject timesheets, ensuring continuity and efficiency in timesheet management, regardless of individual availability. Benefits of this feature include: Increased Flexibility: Multiple approvers can ensure that timesheets are processed promptly, even if the primary approver is unavailable. Operational Continuity: Reduces the risk of delays in invoice processing and other dependent operations. Improved Efficiency: Streamlines the approval process, minimizing the need for last-minute changes and reducing administrative overhead. I believe this enhancement would greatly benefit teams by providing a more robust and resilient timesheet management system.

Currently, Linked Users can be used to share Ticket Access between Sites and Clients based on the permission of each User profile made and linked to the 'Primary' User. In some cases, these Users also need access to the Documents for the Sites they are members of and would prefer doing so using only a single account to log in with. Sharing Document Access Permissions similar to Ticket Access with User Roles and Linked Users would allow these users to utilize a single login in order to access these instead of being required to manage a different user account for each Site/Client they are part of solely for Document Access.

What is the ETA for Project task date dependencies to be cleaned up? Date dependencies are behaving inconsistently, with tasks sometimes moving to unexpected dates or not moving at all. • Tasks are being pushed into weekends rather than the next available working day. • There is no ability to apply lag time between dependent tasks. • Once a dependency is established, dates cannot be manually adjusted without first removing the dependency, making schedule management inflexible and time-consuming.

I would like to change the favicon that is shown on the customer portal – right now it’s the red haloPSA favicon which doesn’t match our color scheme at all. Replacing it with our own custom icon preferred, alternatively the ability to set a HEX color code for the existing icon would be a 2nd option Also when going to our portal the loading circle is blue at first, and then changes to our green, is there any way to fix that? Right now the favicon is red, the initial loading circle is blue, and then finally things change to green, which is a pretty bad mis-match of colors Additionally, it would be great to have the option to repeat a background image vertically, right now we had to make a fairly large image in height to have it work on every possible screen/mobile device, but the caveat is that the background image takes a second or two to load in. If we could just have it repeating on the Y axis that would solve the problem, but I was told that it's not possible, even by custom CSS at this time.

Would be great if we could alert on M365 service health - https://learn.microsoft.com/en-us/graph/api/resources/service-communications-api-overview?view=graph-rest-1.0&preserve-view=true

Email alerts are noisy and out of hours they are simply not seen or when human error applies we fail. When a Notification is not attended to over a period of time, its becomes more important and the Escalation process should kick in (not by repeating the same method but rather by changing it) so we introduce two levels of Advanced Notification / Escalation System Noise Microsoft Teams phone call This way we can get the right level of attention to a situation BEFORE its too late