Feature Ideas

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.

Hudu has this feature so it must be possible to achieve. If Client's website is mentioned under client, it should reach out to the website, get the logo and add it to the client in Halo.

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.

We heavily use to-do's as a way of creating checklists on common steps. However, a lot of our clients require unique custom checklists. We use IT Glue currently for this and it allows not only a to-do, but it allows that to-do to be expanded detailed steps (written in HTML). What I would like to see is the following To-dos have their own tab in tickets and not just a sidebar. To-do's can be expanded to show links or steps (See screenshot of Glue) To-dos once completed hide from the list To-do's that can be associated with a client site and be templated To-Do templates can be grouped

We would like to have the option to disable Agent creation/editing of Column Profiles. Agents currently have the ability to choose which Column Profile to use when viewing ticket lists in Table View (such as 'Default', and any made accessible using Access Control) but they also have the ability to make changes and save those changes as a new Column Profile for their own use. This means that there is no check in place to prevent Agents from creating their own personal variations of an established Column Profile (such as 'Default'), not changing the name when they save it, and resulting in Admin lists of (in our case) 100+ Column Profiles with the same name. It is very difficult to tell Column Profiles apart when we receive change requests (as the Column Profile ID is not displayed when Agents make their selection), and we would like to have the option to disable the creation of new personal Column Profiles so that we can ask Agents to request them instead. (We are aware that we can enforce a Column Profile per Team/Ticket View, but this is not always suitable for teams with mixed remits whose Agents may need to see different Profiles.)

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

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.

It would be good if the "Holiday" event types synced to Exchange calendars with Microsoft 365. As it stands the "Appointment" event type synchronises to calendars, but holidays do not.

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.

Not sure if anyone has posted before, I couldn't see anything from a quick search. Currently the customisation options for ticket layout are minimal. This results in a lot of 'out of site, out of mind' issues for techs. The end-user details section is wildly verbose in its current state, listing out the site + site address is redundant, if you need the address you simply click the site name and see the details. Listing out the phone number, site phone number, work telephone number, mobile number, is also too much. Listing 'primary phone number' would be sufficient, as clicking the user's name would provide further information in the case that it's required. Sometimes 'less is more' goes a long way in terms of visibility. Giving us the option on where fields end up and what order they're displayed in would massively help alleviate issues in instances where a particular ticket type requires a different layout. An example of this is an 'alert' from a device; in this instance the Asset field is more important to us than the end-user and ensuring this is up the top, front and centre in the ticket details pane, would be preferred. From what I can tell, enabling new fields places them in a predefined order, such as 'Other Open Tickets' is above 'Related Assets'. This would suggest that allowing us access to the field priority values could go a long way to solving this.

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

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?

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.

Here's all the things that need to be included in the next iteration of Time Sheets in Halo: Time sheet periods - The ability to establish timesheet periods to tie billing, payroll, workflows, approvals to. I expect my team to update their timesheet daily with a minimum of all hours work entered onto them. I expect the team to submit them to me every week so I can review and approve them to move over to billing to be invoiced.Time Summary View - The ability to slice & dice data on a time sheet to speed up time sheet reviews for approvals. Need to see Time by Ticket, Time by Day, Time by Charge Type, Time by Agreement Type, time by billable status, time by appointment etc. There's no point in having an approvals process without being able to see what we're approving without opening each ticket one by one... I need to make sure that every time entry is compliant. Travel time is set to travel time, communications is set to no charge, notes are clean & professional, AM/PM mistakes are caught, super long time entries are caught etc.. A single tech could have 50+ time entries per day that I have to open each one - one by one - to review. multiply that by the number of techs I supervise... there goes my day.Flagging items for rejections with a reason/explanation. As a timesheet approver, I need to redirect corrections back to the agent with context so they can correct it next time.Time Sheet notifications - Notifications should have multiple variables to notify on. Right now, timesheet notifications are based on whether they meet or exceed hours logged, but I want it to be notified on hours worked. No option for that.Lock timesheets once submitted WITHOUT affecting future actions on a ticket.Ability to enter blocks of time to non-billable/non-production activities. For example: meetings, team events, internal stuff, administrative "things"... Sure I could tell the team to create a ticket for those things, but that's time consuming and too much overhead to make it work. And I refuse to enable quick time because Quick time doesn't allow me to restrict how it's used. (I have issues with folks entering quick time against clients and that's a no no...) time against clients are only for tickets & projects. So, quick time is not allowed here. I hate to say it, but this is one area ConnectWise had right. @Halo - we are MSP's - time is money, and without a method for governing and auditing that time - Halo is nothing more than an ITSM.

For us, being new to HaloPSA, one of the things that frustrated us the most was the lack of good documentation when it comes to integrating with the system. It would be nice if this could be improved a ton, as we now have to try and reverse engineer how the system is set up to do.