Ripe for the Picking: Maximize your Conference ROI

Welcome to No Stupid Questions

No Stupid Questions is a live HaloPSA AMA series that runs every other Wednesday at 8am ET, hosted by Rising Tide in partnership with Renada. Each episode brings together working consultants to answer questions pulled from Reddit, Discord, and the broader Halo community — in real time, with screen shares, and without a script.

The panel is Robbie Emerson, CTO at Renada and a deep HaloPSA practitioner based in the UK; Bree Jutson, who spent five-plus years running ops at an MSP and brings a process-first lens to everything she touches; and Jason Parsons, whose nearly two decades of consulting experience gives him an unusually broad view of how ITIL and service desk principles actually play out in the tools MSPs use every day.

Here's what we covered in Episode 2.

Invoice Review: Stop Printing Things Out

Via Discord

"We're creating invoices, printing them out to check them, and if we need to make corrections, we delete the invoices, go back to the tickets, make changes, and start over. Is there a better way to review billing before it goes out?"

If this workflow sounds familiar, HaloPSA has a feature built exactly for this moment: the awaiting review section, found under billing configuration in labor and travel. It's not on by default, and it's one of the things Jason recommends turning on during implementation.

The distinction Jason drew is worth holding onto: ready for invoicing only shows you what you're about to bill. Awaiting review shows you everything — including time logged as no charge, time that's gone to contract when it should have been invoiced, and anything else you might be leaving money on the table over. It's a catch before the catch, not a duplicate of the same step.

Robbie added that the filters in awaiting review are genuinely useful and underused. You can narrow the view to tickets with time logged over a certain threshold — useful if you only care about entries longer than, say, fifteen minutes, rather than reviewing every thirty-second log. That alone changes how manageable the process feels.

The practical caution from both Jason and Robbie: don't turn on every review layer HaloPSA offers. There's awaiting review, ready for invoicing, timesheet review, and recurring invoice line review. If you turn all of them on, you've created more work than the person printing invoices. Pick the layer that catches the problems you actually have, and use that one. For most MSPs, awaiting review with good filters is that layer.

Jason also flagged a culture point worth naming directly: the organization that came back and said they still wanted to keep printing things out probably has a trust problem somewhere further up the billing process — billing templates, billing rules, ticket processes. The tool isn't going to fix that.

Technician Utilization: Report Carefully

Via live chat — from Peter

"What's the right way to report on utilization? We have project resources whose primary role is billable time, and we expect them to be 80% billable each month. How should we be measuring this?"

Robbie's first move was to complicate the question, which is probably the right instinct. Utilization means different things depending on whether you're asking about a service desk tech, a project engineer, or someone wearing both hats. And "billable" means different things in HaloPSA than it does in ConnectWise — in Halo, billable is closer to invoiceable, whereas in ConnectWise it can mean something softer. Jason raised that distinction, and it matters when you're building reports.

The more pointed concern from Robbie: if you build KPIs purely around how much time someone logs in the system, you will get inflated timesheets. Technicians aim for targets. If the target is 90% time logged, they'll log 90% of their time whether or not that's an honest reflection of what happened. The problem isn't the people — it's that you've created an incentive that points in the wrong direction. Utilization data is only useful as part of a wider picture, not reviewed in isolation.

Jason's preferred approach: work from timesheets. Look at charge hours — time that went to a contract or to an invoiceable ticket, not counting rounding or minimums — and compare that against target hours. That gives you a cleaner view of what someone was actually doing for clients versus internal work, without overweighting the raw number of hours logged.

Robbie added a useful nuance for project-focused teams: if someone you expect to be 80% billable on projects is also spending ten hours a week doing help desk tickets, that's not their fault, and it will make their project utilization look worse than it should. You need the full picture of where their time is going, not just the project slice, before you draw conclusions.

Product Bundles: The Closest Thing to Auto-Adding Items

Via Discord

"Is it possible to automatically add a product to a quote when a specific product is added? For example, when we add a computer to a quote, it should automatically add the monthly service fee for that PC."

The direct answer is no — HaloPSA can't trigger a product addition automatically when another product is selected. But the practical solution is product bundles, which get you most of the way there.

Robbie walked through the setup live: go to config, quotations, general settings, and look for product bundles (called item bundles in some versions of HaloPSA). You create a bundle — say, "new desktop" — and add every item that should come with it: the hardware, the monthly service fee, whatever else. When you're building a quote, you add the bundle instead of the individual products, and everything comes in at once.

What's also useful: quantity multipliers. If you're quoting five desktops, you add five of the bundle, and Halo will automatically add ten monitors if the bundle says each desktop comes with two. That scales cleanly.

One caveat Robbie called out that's easy to miss: updating a product's price does not automatically update it inside a bundle. If your laptop price changes, you need to update the bundle separately. That's a maintenance task worth building into whatever process you use for price changes.

Bree's summary version: if you're adding the same two things together every single time, just make it a bundle. If the combinations are variable or conditional, a runbook can handle more complex logic — but for the straightforward cases, bundles are simpler and don't require automation configuration.

Inventory and Asset Management: Where to Start

Via Reddit

"We're trying to fix our inventory and asset system and integrate purchase orders. We're confused about item categories, subcategories, how stock works, and the relationship between inventory items and assets. Where do we even begin?"

This is one of those questions where the honest answer is that HaloPSA's inventory and asset management isn't the most intuitive system — but once the process is built, it works. The confusion usually comes from not knowing how the pieces relate to each other before trying to set things up.

Bree's starting point: item groups, or product groups. These define defaults that flow down to any item created within them — accounting settings, whether something is recurring, whether it's deliverable. Getting these right and naming them clearly means that when someone creates a new product later, it's obvious which group it belongs to and what settings it inherits.

Robbie added the asset layer: when a product is serialized — meaning it has a serial number and becomes a tracked asset — Halo links the item to an asset type. That link is what makes the whole process work. The practical setup flow is: create your product groups, create your item/asset types and align them to those groups, mark products as serialized where relevant, and then use purchase orders to bring stock in. When items arrive, you receive them against the PO, Halo creates the serialized assets, and they sit in your stock ready to be allocated and delivered to clients.

Robbie's add-on: buy a cheap barcode scanner. Clicking into the serial number field and scanning the barcode on a laptop is dramatically faster than typing it in and reduces fat-fingering. It's a small operational thing that makes a real difference when you're receiving a batch of hardware.

A few features that exist but aren't well known: stock locations and stock bins (bins require enabling a setting in configuration items and stock control — it's not on by default). These let you organize physical stock into labeled locations, which is useful if you have an actual warehouse or stockroom situation.

The limitation Robbie flagged that no one has a great answer for: there's no first-in-first-out system in HaloPSA. If you buy five laptops at £500 each and then five more at £600 each, the system doesn't track which ones you're selling when you sell them. It's reportable in a roundabout way, but it's not built into the workflow.

The more structural limitation Bree flagged — one she's raised with Halo directly — is that you can't pick stock before delivering it. In HaloPSA, selecting a specific serialized unit and consigning it to a ticket are the same step. What some MSPs want is to pick the unit first, assign it to the ticket, have it still show in the stock location until the engineer actually takes it, and then mark it delivered when the job is done. That workflow doesn't exist yet. The workaround some teams use is marking items as delivered before they've left the building, which is technically inaccurate but gets the ticket tracking right.

Jason's naming frustration: when you go to edit an item group, it says "asset group" in the edit view. It's the same thing. It trips up almost everyone the first time.

SLA Breach Auditing: Reports, Codes, and a New Setting

Via a live question

"I want to think of a workflow where if a ticket is closed with a breached SLA, we automatically get an email or Slack message with the ticket ID, summary, and reason for the breach. How would you approach this?"

Robbie's instinct: a weekly report is probably enough. Rather than firing a notification on every SLA breach, schedule a report to run once a week, and review it at the start of the week. That keeps the signal from getting lost in the noise of per-ticket notifications.

He also made a broader point about SLA statistics worth sitting with: they're not useless, but they're not a complete picture of service quality either. A ticket can breach SLA for reasons entirely outside the team's control — waiting on a vendor, waiting on the customer — while the client is completely satisfied. CSAT and client feedback often tell you more than the SLA number does. That said, the question of how to track breaches is still valid, and the tooling has gotten more capable recently.

Bree walked through a setting in the SLA configuration that's easy to discover and easy to misuse: the option to prompt for a reason when the response target is breached. On the surface it looks like what the question is asking for — it captures a justification at the time of closure. The problem: it nulls the breach in reporting. Once a reason is entered, the ticket shows as excluded from resolution SLA rather than breached. Bree's position is to not turn it on, and Robbie agreed. It's an excuse mechanism dressed up as an audit mechanism.

Bree also found breach codes in the latest version (2.244), which appear to do something similar but without the explicit documentation that they null the breach the same way. Worth testing before deploying.

The more useful discovery from this conversation came from Robbie. HaloPSA 2.244 added two things that are genuinely new and worth knowing:

First, new workflow actions triggered specifically when an SLA response or resolution target is breached. Unlike previous automation options, these appear to fire when the breach actually occurs — not just when the ticket is next updated by a technician. That's a meaningful distinction. A ticket could breach SLA and then sit untouched for four hours; under the old behavior, notifications wouldn't fire until someone touched the ticket. The new actions don't have that limitation, based on the documentation, though Robbie noted it's brand new and worth testing.

Second, a new per-ticket-type setting called "store the date when an SLA is breached." This one addresses a problem that's been quietly frustrating people for a while: in HaloPSA, the SLA breach date shown on a ticket isn't the actual moment the ticket crossed the line — it's calculated backwards from how far over SLA the ticket ended up, accounting for hold time. If a ticket goes on hold with the customer three times after it breaches, the date shown can land during one of those hold periods. The new setting stores the actual breach timestamp in the fault metrics table where it can be queried directly. It should probably be on by default for all ticket types. It isn't.

Jason's thread on SLA response definitions is worth a separate conversation, but the short version: for him, a response is when work actually starts — ticket moves to in progress — not an auto-acknowledgement. Robbie agrees. The ITIL view, which Mendy looked up in real time, technically requires an outbound communication to the end user, which HaloPSA doesn't automate at that moment. Most MSPs land somewhere in the middle and define it for their own team. The important part is that you define it consistently.

One related thing Robbie flagged: resetting the response SLA every time a customer replies is a feature that sounds like a good idea and doesn't work well in HaloPSA in practice. The data impact is significant — it moves the response tracking from the ticket level to the actions table, which changes your entire reporting approach. Jason's preferred alternative: make "customer updated tickets" its own tracked metric, as important as the SLA number. Don't try to stuff two problems into one setting.

See you Next time!

Episode 2 was tighter and more technical than the first — fewer big-picture debates, more time spent in the configuration. That's probably a good sign. The questions are getting more specific, which means the community is starting to use this as a place to bring the stuff that's actually tripping them up. That's exactly what it's for.

No Stupid Questions runs every other Wednesday at 8am ET. Bring your questions to the Rising Tide Discord, or drop them in the Halo community, Reddit, or MSP Geek — Robbie, Bree, and Jason are already watching.

‍

Welcome to No Stupid Questions

No Stupid Questions is a live HaloPSA AMA series that runs every other Wednesday at 8am ET, hosted by Rising Tide in partnership with our friends at Renada. Each episode brings together working consultants to answer questions pulled from Reddit, Discord, and live viewer questions in real time, with screen shares, and without a script.

The panel is Robbie Emerson, CTO at Renada and a deep HaloPSA practitioner based in the UK; Bree Jutson, who spent five-plus years running ops at an MSP and brings a process-first lens to everything she touches; and Jason Parsons, whose nearly two decades of consulting experience gives him an unusually broad view of how ITIL and service desk principles actually play out in the tools MSPs use every day.

The series is Bree's brainchild, and the problem she set out to solve is straightforward: too many HaloPSA questions get answered (or not!) once in a Discord thread and then disappear, if they're ever asked at all. Sometimes questions deserve conversation and follow-up that a single text reply can't capture. No Stupid Questions is an attempt to surface those answers in a format that's findable, watchable, and honest — including the parts where the answer is "it depends" and they have to explain why.

Here's what we talked about in Episode 1.

Getting Alerts to the Right People

Via Reddit | https://www.reddit.com/r/halopsa/comments/1u8hat0/set_client_default_mailto_addresses_when_creating/

"We have 2–3 guys per org for email. Is there an easy way to define the default recipients for a client in Halo so that whenever an agent selects 'email user,' we don't have to manually search the recipients every time? Tickets are usually logged by third-party apps — mostly security tickets — and we want to email multiple people."

One of the first questions came from Reddit: how do you automatically route alert-based tickets to the right contacts at a client without manually searching recipients every time?

The starting point, according to Robbie and Bree, is client and site-level notification settings — a place in HaloPSA where you can define who gets copied on emails for a given client or site. It's useful, but with a catch: it's not obvious to the engineer sending the email that those additional recipients are being included. It happens silently in the background, which can create confusion if nobody's thought through the implications.

The harder version of this problem is when alerts come in from a third-party system — a RMM, a security tool, Microsoft — and are assigned to a generic user rather than a real contact. In that case, the "email user" field is blank, and the notification settings alone don't solve it. Robbie's recommendation there was a runbook: define at the customer level who should receive emails for that ticket type, and use automation to populate the recipients when the ticket is created. Not simple, but probably the most reliable path.

Jason made a point worth holding onto: the right answer here depends heavily on what's actually happening upstream. Is this an IT department logging tickets on behalf of end users? Is it automated alerts? Are they trying to keep the original user on the ticket or replace them entirely? The question sounds specific but often isn't, and the configuration choices branch pretty quickly depending on the answer.

One practical side note: clients who ask to be copied on every single email from HaloPSA almost always regret it. The advice from all three — steer them toward the portal instead, and show them exactly where the setting lives so they can turn it off themselves when the inbox flood hits.

Duplicate Alerts and the Merging Question

Via Reddit | https://www.reddit.com/r/halopsa/comments/1szwdq3/question_on_how_you_handle_multiple_alerts_of_the

"We get alerts from WatchGuard and other systems. When a device comes back online you can see it in the portal in a couple minutes, but we have to claim each alert individually. We also get a bunch of alerts from Avanade. We've been given/taken away the ability to merge — what's the best way to handle this?"

The second question was about handling floods of duplicate alert tickets — multiple systems firing on the same underlying event, like a broadband outage that triggers alerts from the firewall, the server, and the monitoring tool all at once.

Bree noted the question came with a complication: the person asking didn't have control over HaloPSA configuration. That matters, because without configuration access, any solution is just housekeeping. You're closing and merging tickets every day without touching the root cause.

Jason's take was direct: merging is a workaround, not a fix. If you're doing it daily, you're hiding a problem that needs to be addressed at the configuration level — email rules, ticket rules, runbooks that prevent duplicate tickets from being created in the first place.

Robbie agreed but acknowledged that HaloPSA doesn't have a great native answer for intelligently correlating alerts from multiple sources. It's a genuinely hard problem. His suggestion for cases where some merging is legitimately appropriate — like alerts from different systems that clearly describe the same incident — was the problem ticket approach: create a parent problem ticket, link the alert tickets as children, and resolve all of them together by closing the parent. It requires setup, and it requires someone to decide when to create the problem ticket, but it's a cleaner structure than merging.

Escalation: Who Owns the Ticket?

Via the Halo community (with a live follow-up)

"Based on the capability of Halo, is it better to escalate a ticket by reassigning it, or to ask for help on the issue while keeping the original owner? And can you intelligently load balance for escalation only?"

A live question came in about escalation — specifically, whether to escalate a ticket formally or just ask for help informally and keep the original owner on it.

Robbie's position was clear: whoever is assigned to the ticket owns the problem. If it's been escalated to a second-line engineer, that engineer should own it. The first-line technician might want to follow the ticket to learn from the resolution, but ownership should move. Keeping a first-line tech on a ticket while someone else does the actual work creates ambiguity and doesn't serve anyone.

Jason added that the answer shifts a bit depending on MSP size. In smaller shops where everyone wears multiple hats, "escalation" can mean something more informal — you're just handing it to the person next to you. The structure matters less when the team is small enough that everyone has visibility. He also flagged a scenario that's easy to overlook: when a ticket requires an on-site visit as part of the resolution, that's often better handled as a child ticket rather than a reassignment, so the on-site work can be tracked and closed separately without muddying the original incident.

Robbie then showed how HaloPSA's escalation actions can be configured to use load balancing or intelligent routing — so when a tech hits the escalate button, the ticket automatically routes to whoever's best positioned to take it, without the tech having to make that choice manually.

On the routing options themselves: round robin cycles through agents in order; load balancing distributes based on ticket count or estimated time remaining (and gets surprisingly configurable); intelligent routing tries to assign to the agent who has worked with that user most recently. Robbie was candid that he doesn't find intelligent routing particularly useful in practice. Your mileage will vary.

First-Time Fix and the Reclose Action

Via the Halo community

"Be interested to know how everyone else records first-time closure stats — especially as we get users reopening tickets completely unrelated to the issue they logged it for originally. Is there a way to set it up so that if a ticket is reopened after a certain amount of time, a new ticket is created instead?"

Someone asked about tracking first-time fix (FTF) stats, especially when users reply to a closed ticket with something unrelated and inadvertently reopen it weeks later.

Bree's go-to recommendation: in ticket type settings, under closure settings, you can configure HaloPSA to create a new ticket — rather than reopen the original — when a user emails in after a set number of hours. Two weeks is a reasonable threshold. After that long, the odds that a reply is actually about the same issue drop significantly, and your FTF stats stop getting skewed by someone replying "thanks" on a closed ticket three weeks later.

Robbie then surfaced something most technicians don't know exists: the reclose action. If a ticket has been previously closed and a user replies, you can use the reclose action to send the original closure email again and close the ticket without counting it as a new resolution. Critically, it preserves your first-time fix stats — because you're not resolving the ticket a second time, you're just closing it back down. The action only appears dynamically when the ticket has been previously closed, so you can safely add it to your ticket layout without it cluttering every ticket.

It's been available for a while, but buried in the three-dot overflow menu. Adding it as an explicit action on your ticket type makes it visible to technicians who would never have found it otherwise.

Robbie also noted that HaloPSA's built-in definition of first-time fix — based on whether the ticket was reassigned from the original agent — isn't quite what most people mean when they say FTF. It's more accurately "first-agent fix." Defining what FTF actually means for your team and building reporting around that definition is probably more useful than leaning on the native field.

Asset Dates: Purchase vs. Delivery

Via the Halo community

"How can I get the purchase date field on an asset to be updated when I sell it to a client? I would think using the consign item or invoice creation as a trigger to grab the date and update the asset would be ideal."

A question about assets: how do you capture the sale date when an item is sold to a client, distinct from the purchase date when you bought it?

The answer is the consignment/delivery date. When you consign an asset to a ticket — which is the step many MSPs skip, or don't realize exists — HaloPSA stamps a delivery date on that asset. That's the date the item went to the client, not the date you received it into stock. The received date is also tracked separately and visible on the asset under supplier/stock information.

Jason pointed out that the confusion here is often less about where the setting is and more about the workflow itself — a lot of MSPs aren't running assets through the full receive-to-deliver process in HaloPSA. Once you do, the dates are there. The terminology doesn't help: "consignment" isn't a word that obviously signals "this is when you hand it to the client."

Robbie added one practical caveat: consignment dates currently store in UTC regardless of your local time zone, which caused some internal confusion that he declined to elaborate on, but flagged as something to be aware of.

Expenses in HaloPSA

Via Reddit | https://www.reddit.com/r/halopsa/comments/1rfwny7/halo_expenses_question/

"Our expenses are non-billable to clients but get paid back to staff on payday. The expenses area in tickets feels weird. Is there a better way to track and manage this, or should we be using an HR platform instead?"

The last Reddit question was about expenses — specifically, managing internal reimbursements for things that aren't tied to a client bill.

The known friction point: HaloPSA expenses must be linked to a ticket. Robbie doesn't think that's inherently a problem — most expenses realistically are connected to a piece of work — but he acknowledged that some people want to log expenses without that overhead, and today you can't, at least not natively. (A feature request for ticketless expense logging is apparently in progress.)

Jason described a workaround that worked well for one of his clients: scheduled recurring tickets, created monthly per agent, that serve as expense submission forms. The agent fills out their expenses against that ticket and closes it to "submit." Reports pull the data out for the accounts team. Not elegant, but it works.

Bree walked through a feature worth knowing: HaloPSA now includes a travel expense calculator. Rather than entering a cost manually, you enter the distance traveled and it applies a configured rate automatically. It's a small thing, but it saves technicians from doing mental math on every on-site visit.

Load Balancing: More Complicated Than It Looks

Via the Halo community

"Load balancing assigns tickets to the next available agent. But with three engineers and nine unassigned tickets, how does Halo decide which ticket goes next? Is it always based on priority? What if a brand new P3 comes in but a P4 has been sitting there for a day?"

A community question about load balancing led to one of the more opinionated conversations of the episode.

Robbie's honest take: he doesn't use it, and doesn't generally recommend it. His preference is to let technicians work from a visible unassigned queue and pull tickets themselves. The reason is partly philosophical — he thinks automatic assignment creates a false sense of coverage, where managers see no unassigned tickets and assume everything is being handled, when in reality engineers are drowning in tickets they haven't even opened yet. He'd rather see the backlog surface visibly than get distributed and hidden.

Jason agreed directionally but framed the problem technically: HaloPSA's load balancing settings are spread across agents, teams, and ticket configuration in ways that are easy to misconfigure. He had a client where all load-balanced tickets were going to one technician because he was the only one online when the morning alert batch came in. The fix was a runbook that redistributed tickets later in the day — which then created a different problem when tickets in progress got reassigned mid-work.

Both Jason and Robbie were skeptical of qualification matching — the feature that routes tickets to agents based on declared skills. Jason knows of one MSP using it specifically to route Apple-related tickets to the two engineers who handle Apple. That's a reasonable use case. Beyond that, it tends to create knowledge silos and leaves teams exposed when the "qualified" person is out.

Bree made a fair counter-point: not every team has a dedicated dispatcher, and when the dispatcher is out, something has to fill the gap. HaloPSA does have the capability to handle routing automatically — the question is whether the configuration investment is worth it for the team's size and maturity. For some shops, probably yes.

Plus Addressing: A Hidden Setting Worth Knowing

Via Discord

"We're trying to use plus addresses to route alerts from various sources to the right client team — something like support+clientname@ourdomain.com. It seems to work in some cases but not others. Emails from Microsoft especially seem to end up in our own MSP's queue instead."

The final question was about plus addressing — using email addresses like support+clientname@yourdomain.com to route inbound alerts to the right client automatically.

Robbie's assumption going in was that HaloPSA doesn't support plus addressing, and that teams have had to resort to runbooks with SQL queries to extract the client reference and do the matching manually. That's been the workaround.

Bree — with a tip from Mendy in the internal chat — found that plus addressing actually does work when configured in the "To address matching" field within site settings. It's not documented prominently, and it doesn't work in email rules (which use the mailbox address rather than the full To field), but in that specific spot, it works. Robbie's reaction: genuinely useful, genuinely surprising, and a good reminder that HaloPSA often has a setting for the thing you thought it couldn't do — it's just not where you'd expect it to be.

Out of Office and Teams Presence

Via Discord — from James

"We use load balancing for escalations, but how do we make sure agents on leave aren't getting tickets routed to them? We use a separate HR app, so Halo doesn't know when someone's out."

One last question before the episode wrapped: how do you make sure agents on leave don't get tickets routed to them, especially when your HR system is separate from HaloPSA?

The cleanest solution Robbie showed is the Microsoft Teams presence integration. Each agent authenticates through My Account > Integrations, connects to Teams, and maps their Teams presence status to their HaloPSA agent status. When they're marked out of office in Outlook or Teams, HaloPSA picks it up automatically and excludes them from routing.

The setup requires each agent to do it themselves, and it does need Entra/Active Directory. But for teams already living in the Microsoft ecosystem, it means agents don't have to remember to update HaloPSA separately when they go on leave — which, in practice, nobody does.

For teams using a third-party HR platform, Robbie mentioned that Renada built a custom sync with Breathe HR that pushes approved leave into HaloPSA as calendar appointments and sets the agent status accordingly. Not an out-of-the-box solution, but a template worth knowing exists.

See you next time!

Episode 1 covered a lot of ground — from settings most people don't know exist to honest debates about whether certain features are worth the configuration overhead at all. That's kind of the point. The questions that came in weren't softballs, and the answers weren't always clean. If you've been running HaloPSA for a while and found yourself nodding along or scribbling notes, that's exactly what this is for. Bring your questions to the next one.

No Stupid Questions runs every other Wednesday at 8am ET. Bring your questions to the Rising Tide Discord, or drop them in the Halo community, Reddit, or MSP Geek — Robbie, Bree, and Jason are already watching.

‍

In Episode 25 of By the [run]Book, Mendy Green and El Copeland continue reviewing HaloPSA version 2.218 and begin with two important CSP integration warnings. They explain why Pax8 users may need to move back to the standard HaloPSA authentication method and why Ingram Micro or CloudBlue users should inspect duplicate client mappings and recurring invoice subscription links.

The feature review covers rule-triggered ticket lookups, descriptive ticket-rule action notes, the new ticket Notification Log, configurable quotation buttons, improved incoming-email matching, email template groups, Office document knowledge base articles, SQL-powered distribution lists, and major service catalogue improvements. This episode is especially useful for HaloPSA administrators, MSP operations teams, billing teams, and consultants responsible for maintaining integrations, ticket automation, portal services, and user-facing workflows.

Watch Now: By the [run]Book: Episode 25
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.‍

Important Mentions

Integration Issues and Administrative Warnings

Pax8 integration authentication change | 1:44

Organizations that moved their Pax8 integration to a custom developer application should consider changing the authentication type back to “Use the HaloPSA app.” Halo and Pax8 have arranged for the standard Halo application to bypass some of the rate-limiting restrictions affecting custom applications.

Changing the authentication method should not remove existing mappings, but the administrator will need to authenticate with Pax8 again.

• Enable notifications for Halo Integrator and backend service failures.
• Check failed Pax8 synchronization jobs promptly.
• Manually import subscriptions when a scheduled synchronization fails.
• Coordinate notification settings between Halo administrators because enabling the notification for one administrator may stop the general notification from being sent to the others.

Ingram Micro / CloudBlue CSP subscription warning | 5:38

Some legacy subscriptions could not be updated normally by Ingram Micro. In certain cases, the workaround created a new subscription under a duplicate client record, particularly for some Adobe subscriptions.

This can leave the correct subscription unmapped or disconnected from the recurring invoice line that is supposed to bill it.

• Review the client and tenant mappings in the CSP integration.
• Look for multiple tenants representing the same customer.
• Map all applicable tenant records.
• Confirm that recurring invoice lines are linked to the current subscriptions rather than the original legacy records.

Full Feature List

Added the setting 'Allow partial matching on the email address, network login and User matching fields' to the Virima integration | v2.218 #1063759 | 8:04

Organizations using the Virima integration can now permit partial matching across email addresses, network logins, and other user-matching fields.

Mendy and El noted that this is primarily relevant to organizations already using Virima for asset-management purposes.

Added a new Agent permission, "Can edit action visibility for users", which is now separate from "Can use the Treat as Spam button" | v2.218 #1058093 | 8:28

Halo now separates the ability to change whether an action is visible to the user from the permission to treat a ticket as spam.

This is an important permissions improvement because the Treat as Spam button can create an email rule that blocks the sender. Administrators can now allow agents to correct note visibility without also allowing them to block incoming senders.

Additional bulk update options have been added to Prospects | v2.218 #1053444 | 9:41

Additional editing options are now available when multiple prospect records are selected.

This should be useful for organizations managing prospects in Halo as part of their sales or CRM processes.

Added the tickets setting "Do not copy the ticket history when cloning a ticket" | v2.218 #1050305 | 10:20

Administrators can now prevent the original ticket history from being copied when a ticket is cloned.

This allows agents to reproduce the ticket’s structure without carrying over all previous actions and communications.

Lookups that are triggered by ticket rules can now run on the new ticket screen | v2.218 #1042248 | 10:47

Rule-triggered lookups can now execute while an agent is creating a ticket rather than waiting until the ticket has been submitted.

Lookups can run SQL and populate ticket fields dynamically. Allowing that process to occur on the new-ticket screen can improve automation and give the agent immediate visibility into the resulting field values.

• Useful for automatically populating resolution notes, classifications, or contextual information.
• Can reduce repetitive ticket-entry work.
• Allows agents to confirm the lookup results before saving the ticket.

Added multi-select filtering for Statuses to Ticket Lists | v2.218 #1042200 | 12:30

Ticket lists can now be filtered by selecting multiple statuses.

Mendy noted that Groups and Filtering may provide a more modern way to organize ticket data, but multi-select filtering remains a useful option and can also apply to agent and team filters.

Added Reference field to Recurring Invoice column profiles | v2.218 #1039805 | 13:45

The Reference field can now be included in recurring invoice column profiles, giving billing teams another useful value for identifying and reviewing recurring invoices.

Added new Ticket > General Setting to enable descriptive 'Rule Applied' action notes | v2.218 #1033522 | 13:56

Halo can now create more descriptive action notes when a ticket rule is applied.

Mendy and El recommended enabling this setting because it provides better visibility into what the rule actually did instead of simply recording that a rule fired.

• Helps troubleshoot layered ticket rules.
• Makes the ticket history more useful to administrators.
• Can clarify where an automation succeeded or stopped behaving as expected.

Added the ability to set column profiles on Prospects and Accounts | v2.218 #1030392 | 14:34

Prospect and account screens can now use configurable column profiles.

This is particularly useful for organizations using Halo more extensively as a CRM because the sales team can tailor the displayed information to its workflow.

Added new settings to limit the fields available as Ticket search filters | v2.218 #1029462 | 15:05

Administrators can now limit which ticket fields are available for searching.

Mendy emphasized that broader searches do not always produce better results. Restricting search to relevant fields can improve both performance and result quality, especially in larger Halo databases.

Custom fields may have their own search configuration, although the exact option appeared to have changed or moved in the version demonstrated.

Added a ticket tab for related/impacted CIs | v2.218 #1023752 | 17:49

Tickets can now include a tab that displays related or impacted configuration items.

This is primarily aimed at organizations using Halo’s more advanced ITSM, asset-relationship, and service-dependency capabilities.

You can now change the primary asset on a ticket from its asset dependency diagram by right-clicking on an asset | v2.218 #1023727 | 19:36

Agents working with asset dependency diagrams can now right-click an asset and make it the primary asset on the ticket.

This extends existing primary-asset functionality into the dependency diagram interface.

Stock received' webhook event now includes purchase order information | v2.218 #1018647 | 20:05

The Stock Received webhook now includes information about the associated purchase order.

This provides automation platforms with better context when stock is received and can support downstream purchasing, inventory, or notification workflows.

Added className tags to the cost and delivery elements on the service details screen | v2.218 #1016832 | 20:27

The cost and delivery elements on portal service-detail pages now have class names that can be targeted through custom styling.

Mendy demonstrated that the cost element uses a class such as service-cost, which allows administrators to visually distinguish pricing or delivery information on the portal.

Added the option to colour code single select ticket custom fields in column profiles | v2.218 #1011769 | 23:28

Values from single-select ticket custom fields can now be color-coded when displayed in a column profile.

This may help teams quickly scan different request types, classifications, or operational states. Mendy and El cautioned against using color as a substitute for thoughtful list design.

• Reserve colors for information that genuinely needs attention.
• Avoid overcrowding ticket lists with unnecessary fields.
• Consider grouping data when grouping communicates the distinction more clearly than color alone.

Added the ability to translate language packs using Azure AI Translator for the portal only | v2.218 #1010531 | 26:41

Portal language packs can now be translated using Azure AI Translator.

This provides another option for organizations maintaining a multilingual self-service portal, although Azure Translator usage and cost should be evaluated before enabling it.

Added a Notification Log tab to tickets | v2.218 #1009704 | 27:16

A dedicated Notification Log can now be displayed on tickets.

Mendy recommended enabling it. The existing Event Log is valuable but highly technical, while the Notification Log offers a more user-friendly way to see what notifications were generated.

• Helps investigate whether a ticket notification was created.
• Reduces the need to inspect detailed event records.
• Can simplify troubleshooting during implementations and ongoing support.

Added ServiceNow supplier action webhooks | v2.218 #1009500 | 28:02

Halo can now send supplier action webhooks to ServiceNow using a process similar to customer-facing ServiceNow webhooks.

Supplier webhooks can update an existing Halo ticket through actions, but they cannot create a new ticket. The Halo ticket must already exist under a customer before supplier information can be associated with it.

KB Article negative feedback tickets can now use article-related dollar variables in the summary and details | v2.218 #1008109 | 29:13

Tickets created from negative knowledge base feedback can now include article-related dollar variables in their summary and details.

This should make those tickets easier to identify and give the reviewing team more useful article context.

The button visibility on quotations is now configurable | v2.218 #1004111 | 29:28

Administrators can now control the visibility of many system buttons on quotation screens.

This can significantly reduce clutter and prevent users from seeing actions that are not relevant to their role or process. Custom buttons will continue to appear, and some system buttons cannot be configured.

• Review the default quotation buttons before changing the setting.
• Keep buttons required later in the quotation lifecycle enabled.
• Test each quotation stage because some actions only appear in specific states.

You can now create Email Template Groups | v2.218 #996572 | 32:59

Email templates can now be organized into groups.

This can make a large template library easier to navigate by separating templates into categories such as ticketing, invoicing, portal communication, security, or custom templates.

Mendy noted that the feature currently focuses on organization rather than inheriting settings or CSS at the group level.

The options in Email Configuration for matching incoming emails on From/Subject and In-Reply-To header have been moved into a list to allow more granular control | v2.218 #991820 | 35:47

Incoming email-matching methods are now presented as a list, allowing administrators to control how the From address, subject, and In-Reply-To header are evaluated.

Mendy recommends using Subject and From Address OR In-Reply-To Email Header for most organizations. This helps replies remain attached to the correct ticket even when recipients or the subject line change.

Previously, enabling multiple checkboxes could require all selected conditions to match. The new configuration supports more practical either/or behavior.

Added new group PDF print options for purchase orders | v2.218 #982257 | 37:21

Purchase order PDFs now include additional group-printing options, including ways to display grouped quantities and prices.

This brings purchase order output closer to options already available for quotations and invoices.

If a Ticket Area has Team Permissions, Agents not in the allowed Teams will now be hidden in the tree view regardless of Ticket Area filters | v2.218 #971300 | 38:03

The ticket tree will now respect a ticket area’s team permissions when displaying agents, even when the ticket-area filter includes broader teams.

Mendy and El were unable to fully validate the exact behavior during the live demonstration, so organizations that depend on this permission structure should test it with representative agents and areas.

You can now set Agent idle timeout warnings in Config > Advanced Settings | v2.218 #963458 | 41:17

Agent idle timeout warnings can now be configured under Advanced Settings.

This may be helpful for organizations that want to warn users before Halo ends an inactive session, although external identity and conditional-access policies may already enforce shorter session limits.

Various improvements to the service catalogue | v2.218 #936692 | 41:53

Halo’s service catalogue now supports a more store-like request experience. Optional services can be presented alongside a primary request, and users can select items or bundles, choose quantities, and add notes.

This can support workflows where the request includes both a service and one or more physical or billable items.

• New-user or new-computer requests can include the related equipment.
• Clients can select optional add-ons while completing the main request.
• Item and bundle selection can support more polished self-service purchasing workflows.
• The configuration may require additional refinement to limit which specific items are presented.

Added the ability to consign existing unlinked assets | v2.218 #855129 | 46:46

Existing unlinked assets can now be selected during consignment when the purchase order is set to deliver to a user.

Mendy suggested that a likely use case is backfilling purchasing and ownership information after migrating existing stock into Halo. Assets that did not originate from a Halo purchase order can be linked and assigned to the correct user.

Introduced a document knowledge base article type that will display Office documents on the knowledgebase article | v2.218 #808224 | 50:01

A new knowledge base article type can display an uploaded Office document directly within the article.

Word document text can be extracted and scanned, which should allow the content to participate in Halo’s knowledge base search and AI functionality. The Halo Integrator and file-scanning functionality must be enabled.

Added a setting to use only the project’s own budgets when the parent is an opportunity ticket | v2.218 #775722 | 50:57

Projects created beneath opportunity tickets can now be configured to use only the project’s own budgets rather than inheriting budget information from the opportunity.

This keeps budget tracking focused on the actual project when the opportunity is only acting as the parent record.

Added an option to dynamic Distribution lists to use a SQL query instead of a pre defined filters | v2.218 #744258 | 52:24

Dynamic distribution lists can now be populated through a SQL query instead of relying only on predefined filters.

This gives administrators significantly more flexibility when the required membership logic cannot be represented through the standard filter options.

Added the ability to use tabs for dashboards | v2.218 #718178 | 52:35

Multiple dashboards can now be presented as tabs within a shared dashboard view.

Mendy found the current implementation difficult to configure and use, so teams should test it before replacing their existing dashboard navigation.

An option has been added to the Tenant mappings in the Microsoft CSP integration to exclude the mapped Client from Intune imports | v2.218 #571515 | 53:26

Microsoft CSP tenant mappings can now exclude a mapped client from Intune imports.

This provides more granular synchronization control for former clients or other tenants that may still exist in the Microsoft partner relationship but should no longer import Intune assets into Halo.

A setting has been added to Ticket Rules to show the resulting pop-up as a modal pop-up | v2.218 #424689 | 54:23

Ticket-rule pop-ups can now appear as modal windows instead of the default flyout notification.

A modal is harder for an agent to overlook, making it appropriate for critical instructions or warnings. It should be used selectively because repeated modal interruptions can quickly become disruptive.

‍