Feature Ideas

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.

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.

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.

Currently when there is a gross margin added on a product and I lower the cost, the price goes down proportionally as well. I don't want our customers by default to get a lower price on something. Please make a way for the gross margin to only increase price based on cost, and not decrease price.

Currently, the editing of timesheet entries is hard linked with the rights to edit actions. We'd like to petition for a split in access rights for this. As part of our ISO27001 policies and requirements, we cannot allow the editing of actions. We came from Xurrent, where the time entries were a completely separate object from the actions. There, we could allow the changing of time entries after the fact, while making sure the agents could not edit the notes. In HaloPSA, in the timesheet sidebar, agents still get the UI option to drag and extend/contract time entries, but without the right to edit actions this just reverts back and doesn't save. For project engineers, not being able to edit time entries on actions results in them having to make quick time entry actions in tickets for every individual block of time they worked on a project in a day, polluting the progress feed. For our support engineers, they cannot edit the charge type if the ticket changes status from non billable to billable over the course of the ticket, or if they made a mistake in their action. This adds a lot of overhead for our SDMs to review and correct all those entries after the fact. When viewing an action, it would seem logical for me to split the rights to edit the "Action Details" tab from the rights to edit the "Time tracking" tab.

Problem When an agent signs in with SAML SSO, Halo issues the .Halo.Identity.Application cookie as a persistent cookie with a 14-day expiry. When the same agent signs in with a local account without ticking "Remember me", the same cookie is issued as a session cookie. As a result, for SAML agents: closing the browser does not end the Halo session;when the browser is reopened, Halo signs the agent straight back in from that cookie: no login page is shown and the identity provider is never contacted;the Agent idle timeout only applies while Halo is open in the browser, so it has no effect once the browser has been closed. For up to 14 days, the session and re-authentication policies configured on the identity provider cannot take effect, and a device where the browser was simply closed still has access to Halo. Steps to reproduce Sign in as an agent via SAML SSO and check the .Halo.Identity.Application cookie: it expires 14 days after login.Close the browser completely, reopen it and go to Halo: the agent lands on the homepage with no login prompt.Repeat with a local login without "Remember me": the cookie is a session cookie, and after reopening the browser the login page is shown as expected. Requested change (any of these would solve it) Issue .Halo.Identity.Application as a session cookie for SAML logins, consistent with local logins without "Remember me".Add a setting to control whether the authentication cookie for SSO logins is persistent, and its lifetime.Enforce the Agent idle timeout server-side, so the session also expires when the browser is closed. Why it matters Organisations that use SSO rely on their identity provider for authentication policy. With a 14-day persistent cookie those policies are bypassed. The only workaround today is changing cookie settings in every agent's browser, which is not manageable at scale. Thank you very much

we use the Unifi Hardware stack for most of our networking as the controller for this is free and doesnt require a subscription. this controller uses standard Rest api to collect information. (www.ui.com) I have currently created a powershell based integration that collects all sites and hardware from the unifi controller and updates them via api in Halo. However, due to api throtteling this process is quite prone to error. It would be realy nice to have this as a proper integration. This api is Documented here: https://ubntwiki.com/products/software/unifi-controller/api

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

wouldn´t it be great, to have the same login for the https://support.haloservicedesk.com/portal/ and https://ideas.halopsa.com/ and to be able to create an Idea from a ticket, so that dev could not only read the idea, but also the support case which lead to the feature request?

It would be really useful to be able to write an email in Outlook and pick the correct ticket number from a list or search, add time in and then send to Halo through the normal copy in the mail delivery email address as usual. The reason this works much better is: a) People don't ignore direct emails from people in the same way as they ignore automated emails from a PSA system b) The formatting used is much better and doesnt break as with the current output from Halo(and you can paste in other items without the formatting getting screwed too) You could use the same mechanism to book in ticket updates, appointments from tickets and tasks/notes from tickets to work from.

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.