Critical Thinking in 5

Episode 26 closes out the first season of By the [run]Book with Mendy and El working through the first half of HaloPSA v2.22. The episode focuses heavily on integration reliability, billing automation, API improvements, portal updates, and several quality-of-life changes for Halo administrators.

The team will take a short break before returning with Season 2, where they will continue reviewing the remaining v2.22 release notes.

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

Changed the way incoming webhooks are processed in the Exchange calendars integration | v2.22 #1100829 | 3:04

Exchange calendar updates from Outlook to Halo are now processed through Halo’s incoming webhook service.

Previously, real-time appointment updates could send a large number of requests into Halo and affect performance. The updates are now queued and processed in a more controlled way.

• Appointment synchronization remains automatic but may no longer appear instantaneous.
• The change is intended to improve platform stability and performance.
• Webhook logs remain available for troubleshooting.

The incoming webhook service has now been enabled for all instances | v2.22 #1141063 | 5:27

The incoming webhook service is no longer a beta feature and has been enabled across Halo instances. Halo is moving more high-volume integrations through this service to reduce the risk of large numbers of inbound requests affecting platform performance.

A setting has been added to control how the default Mailbox of a Ticket is updated | v2.22 #1114701 | 6:01

A new setting under Configuration > Tickets > General Settings controls whether a ticket’s default mailbox is updated after an email is sent.

This can help when a mailbox assigned to existing tickets has been deleted. However, Mendy recommended leaving the global setting unchanged unless there is a specific reason to use it.

• Deleting a mailbox can leave existing tickets associated with an invalid mailbox.
• Sending from another address does not necessarily change the mailbox stored against the ticket.
• RTG’s preferred approach is to repair the affected tickets rather than apply an unpredictable global change.

Payment Reference will now be included in the data pushed to Xero Payments | v2.22 #1113822 | 8:28

Payments entered directly against a Halo invoice can now include the payment reference when synchronized to Xero.

This is especially helpful for check payments or other manually recorded payments because the reference can be used to match the payment to the corresponding bank transaction during reconciliation.

An additional check will now be made when creating Invoices for Sales Orders to stop duplicate Invoices being created | v2.22 #1113807 | 9:56

Halo now performs an additional validation check when generating an invoice from a sales order to help prevent duplicate invoices from being created.

Various improvements to searching services in the self-service portal | v2.22 #1113142 | 10:23

Service searches in the self-service portal now search both the service name and its details. Previously, the search could be configured to search one or the other, which made relevant services easier to miss.

When using the Pax8 integration, customers can now be excluded from automatic recurring invoice line creation. | v2.22 #1113072 | 11:18

Individual customers can now be excluded from Halo’s automatic creation of recurring invoice lines from Pax8 subscriptions.

The customer record includes a Pax8 option that prevents recurring invoice lines from being created automatically. The Pax8 product cost can also be used when Halo creates related items and recurring invoice lines.

Mendy recommended testing this carefully:

• It may save significant setup time for new Halo implementations.
• Existing customers with established recurring invoices should be cautious when moving to the automated process.
• Switching an existing billing structure without testing could create duplicate or inconsistent recurring invoice lines.

Added fields to the LiveChatHeader table to store the date the First Agent joined a live chat and the time in minutes the User spent queueing for an Agent | v2.22 #1112870 | 15:15

New database fields make it possible to report on when the first agent joined a live chat and how long the user waited in the queue.

These fields provide call-center-style performance measurements for organizations using Halo’s live-chat support functionality.

Mendy noted that Halo chat remains relatively limited compared with platforms such as Microsoft Teams, Slack, or Discord. Organizations should carefully consider whether splitting internal communication between Halo chat and another collaboration platform will create unnecessary complexity.

When using the “automatically invoice for pro-rata” option, the pro-rata will now be added to the related invoice line for reference purposes | v2.22 #1112796 | 17:14

When Halo creates an immediate invoice for a prorated recurring-invoice adjustment, the prorated amount will now also be recorded against the related invoice line.

This gives administrators a clearer history of where the prorated charge came from and why it was generated.

Mendy also reviewed the available proration options:

• For monthly recurring invoices, adding the adjustment to the next invoice is often the simplest option.
• For annual or longer billing schedules, placing the adjustment in Ready for Invoicing provides better oversight.
• Immediate invoicing can be used when the adjustment needs to be billed as soon as it occurs.

Invoices lines that are manually linked to Prepay records will now be used as part of deferred revenue recognition calculations which allows invoices created from Sales Orders to be used in this process | v2.22 #1112036 | 21:33

Invoice lines can now be manually linked to prepay records and included in deferred-revenue recognition.

This allows an invoice generated from a sales order to fund a prepay balance while still being recognized correctly during the deferred-revenue process.

Previously, the missing connection could cause Halo to generate the deferred-revenue invoice without applying the appropriate credit for the revenue that had already been billed.

A Ticket property has been added so that when creating a Ticket via the API the “reportedby” (email address) can be used to find the User | v2.22 #1110919 | 22:50

API integrations can now instruct Halo to find the ticket user from the email address supplied in the reportedby property.

This can remove the need to make a separate API request to find the user ID before creating the ticket.

• The integration supplies the reported-by email address.
• Halo locates the matching user.
• The ticket can then be associated with the correct user, site, and client.

Mendy described this as valuable for nearly every vendor building a Halo integration.

Runbooks that retrieve attachments will attempt to create a filename that includes the content using the Content-Type header that is returned | v2.22 #1110012 | 24:07

Runbooks that retrieve an attachment will now use the returned Content-Type header to help construct a more appropriate filename.

Recurring Invoice lines that use Users and Devices for quantity will no longer include inactive Sites Users and Devices | v2.22 #1109965 | 24:38

Automatic recurring-invoice quantities will now exclude users and devices connected to inactive sites.

Previously, a user or device could remain individually active while belonging to an inactive site and still be included in the calculated invoice quantity. Halo will now exclude the record when any relevant part of that relationship is inactive.

Added an option to Distribution Lists to determine which User email field to send emails to | v2.22 #1108508 | 25:40

Distribution Lists can now be configured to use a specific email field from the associated user records when sending messages.

Added link to Halo University within the Help menu | v2.22 #1108328 | 25:46

Halo University can now be opened directly from Halo’s Help menu.

Additional logging has been added for Addigy webhooks | v2.22 #1107424 | 25:52

Additional webhook logging is available for the Addigy integration, providing more information when diagnosing synchronization or webhook-processing issues.

The Tax Rate and Tax Code import will now log results into the Outgoing tab for debugging purposes | v2.22 #1107092 | 26:00

Tax-rate and tax-code import activity will now appear in the Outgoing tab. This gives administrators more information when troubleshooting tax data imported from an accounting integration.

Ingram Micro/Cloud Blue and Pax8 integrations can now be configured to make removed licences/subscriptions inactive in Halo during the Integrator import | v2.22 #1106756 | 26:36

A new integration option allows Halo to mark previously synchronized licences or subscriptions inactive when they disappear from Pax8, Ingram Micro, or CloudBlue.

This closes an important gap in the synchronization process. If the distributor simply removed a subscription instead of returning it with an inactive status, Halo previously had no way to know that the subscription was gone.

Mendy recommended enabling this setting for all affected integrations.

• Keeps Halo subscription records aligned with distributor data.
• Prevents removed subscriptions from remaining active indefinitely.
• Helps reduce incorrect recurring billing.

Variables can now be used on Invoice lines to populate a list of Devices/Users that relate to the line for automatic quantity calculation | v2.22 #1106755 | 28:15

Invoice-line variables can now display the devices or users included in an automatically calculated quantity.

Mendy and El cautioned that providing more information does not always make an invoice more useful. The information should be presented in a format the customer can understand rather than included simply for the sake of transparency.

During the end-of-episode follow-up, Brie confirmed that the variable currently produces a comma-separated list with limited formatting. Mendy’s preference remains to provide the details in a separate, well-formatted report rather than overcrowding the invoice line.

Deleting an Invoice that contains pro-rata created from the Ready For Invoice list will now mark the pro-rata line as ready to be invoiced | v2.22 #1105381 | 31:10

When an invoice containing a prorated charge from the Ready for Invoice list is deleted, Halo will return the prorated line to a ready-to-invoice state.

This makes it possible to correct and reissue the invoice without losing the original prorated charge.

Added the option to remove the ticket summary from “linked to ticket” records in an asset’s change history | v2.22 #1105329 | 31:39

Administrators can now prevent the ticket summary from being stored in an asset’s change history when the asset is linked to a ticket.

Mendy suggested this may also help reduce the amount of change-history data stored against heavily used assets, which can contribute to slow loading or display problems.

Tickets, Opportunites and Projects will now show when configuring PDF templates | v2.22 #1104876 | 32:30

When using the Generate PDF functionality, administrators can now select tickets, opportunities, and projects as the source entity.

El described the ability to select the entity used for PDF generation as a significant quality-of-life improvement.

Resolved an issue causing Expense lists to not be able to be ordered by Agent Name | v2.22 #1104868 | 34:35

Expense lists can once again be sorted by the Agent Name column.

Added various SLA related fields to Column Profiles | v2.22 #1104799 | 34:47

Additional SLA fields are now available in ticket-list column profiles, including:

• Respond By Date
• Response Date
• First Responded By Date
• First Response Date

These fields make it easier to review whether tickets met their first-response targets and whether the current response target remains within SLA.

They can also be useful when building operational reports or ticket-list views for SLA monitoring.

Added _match_additional_id property to entities that support _match_thirdparty_id | v2.22 #1104757 | 36:11

Entities that support Halo’s third-party matching properties can now also use _match_additional_id.

Mendy used this release note to explain one of Halo’s strengths as an integration-first platform. Third-party systems can store their own integration name and record identifier against a Halo entity. Future API requests can then update that entity using the third-party identifier instead of first retrieving the Halo ID.

This can simplify integrations with external accounting, documentation, RMM, and custom application platforms.

Various improvements to meter reading functionality | v2.22 #1104012 | 39:36

Meter-reading improvements include changes to rollback behavior and recurring-invoice quantity recalculation.

• Rolling back meter readings will use readings from the previous period.
• Recurring-invoice quantities will be recalculated after the recurring invoice is created.

Mendy recommended retesting existing meter-reading workflows after upgrading because this area has received several functional changes.

Selecting approver users will now be paginated in the API for improved performance | v2.22 #1103213 | 40:23

Approver-user selections are now paginated in the API, improving performance for Halo instances with large numbers of users.

Properties have been added to the ExternalLink entity so that buttons to a specified URL can be shown on the related entity | v2.22 #1101214 | 40:32

ExternalLink records can now create visible buttons on related Halo entities.

Third-party integrations can provide a caption, icon, and URL so an agent can open the corresponding record in the external platform directly from Halo.

This is especially useful for vendors that want to provide a deep link from a Halo ticket, user, invoice, quote, or other supported entity into their own application.

Improvements to FAQ List access control | v2.22 #1096100 | 41:11

Halo has expanded access controls for FAQ Lists, which function as the folder structure for the Halo knowledge base.

Knowledge-base articles continue to inherit access from their FAQ List, but edit permissions can now be more tightly controlled. An agent must have owner access to modify the FAQ List itself.

Mendy warned administrators to distinguish between agent access and user access:

• “All agents” refers to internal Halo agents.
• “All users” may expose content to the wider customer portal audience.
• “Everyone” can create much broader access than intended.

Changes to knowledge-base permissions should therefore be tested carefully and applied intentionally.

Amended wording for dropdown options for “Followers Field and Delegate Approvers Scope” and “Email CC List Scope” fields | v2.22 #1094360 | 46:00

The wording of the dropdown options for follower, delegated-approver, and email-CC scope fields has been revised to make the available choices clearer.

End user virtual agents can now use the function ‘Search Tickets’ | v2.22 #1094201 | 46:26

End-user virtual agents can now use the Search Tickets function. Mendy noted that the function may need to be added to the virtual agent’s permitted functions because it is not necessarily included by default.

Column Profiles can now be set for Supplier Contacts on the Self Service Portal | v2.22 #1093735 | 46:44

Supplier contacts who sign in to the self-service portal can now be given a configured column profile. This allows the information shown in their portal lists to be controlled in the same way as other portal views.

You can now restrict read/update of FAQ list fields based on Agent Role | v2.22 #1092687 | 47:49

Read and update access to fields stored against FAQ Lists can now be restricted according to the agent’s role.

Supplier Contacts with Self Service Portal Access can now view the Knowledgebase and Documents | v2.22 #1092585 | 48:26

Supplier contacts with portal access can now view knowledge-base articles and documents that have been made available to them.

Halo now maintains the connection to linked Jira Software issues when they are moved to a different Jira project | v2.22 #1089851 | 48:33

Halo will preserve its connection to a linked Jira issue when the Jira issue is moved from one project to another.

Various improvements to the self service portal asset and approval pages | v2.22 #1088952 | 48:41

The self-service portal asset and approval pages have received several display and configuration improvements.

• Asset column profiles can be selected for portal views.
• Asset lists now support a tile view.
• Custom HTML can be used to design asset tiles.
• Insertable fields can populate the custom HTML.
• Administrators can set a default asset view.
• Users can switch between table and tile views from the three-dot menu.

Mendy and El highlighted the flexibility these changes provide for creating more useful and visually organized portal asset pages.

You can now view which Sites a User is a Site Contact for on their User record | v2.22 #1088051 | 49:31

The user record now shows the sites for which that user has been assigned as a site contact.

The information appears in the user’s Preferences tab under the site-level notifications section. This can be helpful when reviewing contact responsibilities across customers with multiple sites.

You can now set a default note against a product bundle | v2.22 #1085601 | 51:37

A default note can now be stored against a product bundle. The note can then be included when the bundle is added to an invoice, quote, or sales order.

Added “has a value” and “does not have a value” filter options to Ticket Lists | v2.22 #1080062 | 53:04

Ticket-list filters can now specifically identify records where a field is populated or blank.

This removes the need for workarounds such as filtering for an empty string or attempting to match a blank value.

Improved the display of the status icon, priority, and agent columns in self-service portal ticket lists | v2.22 #1069797 | 53:50

The status, priority, and agent columns in portal ticket lists have been updated with a cleaner and more modern display.

Added the setting ‘Automatically apply the following template’ at action level | v2.22 #1066593 | 54:05

An action can now be configured to apply a selected ticket template automatically when the action is used.

This can reduce the number of steps agents must complete when an action consistently requires the same template.

Actions can now be configured to “Show From Address” by default | v2.22 #1066318 | 54:43

Email actions can now display the From Address field by default.

Agents could previously expose the field manually through the action’s three-dot menu. The new option makes it visible automatically for actions where selecting or confirming the sending mailbox is important.

You can now allow anonymous voting on the Self Service Portal | v2.22 #1065189 | 55:01

Portal ticket voting can now be made available without requiring the voter to sign in.

El suggested this could be useful for creating a feature-request board where customers or community members vote on proposed ideas.

You can now hide article ratings on the portal without disabling article voting | v2.22 #1065059 | 55:38

Article ratings can now be hidden from the portal while the underlying voting functionality remains enabled.

You can now search all configuration settings | v2.22 #1063563 | 55:46

Halo administrators can now search across configuration settings instead of manually navigating through each configuration area.

The feature must first be enabled under Configuration > Advanced Settings in the configuration section. Once enabled, searching from the main Configuration page will:

• Find settings containing the entered search terms.
• Show which configuration area contains each setting.
• Open the appropriate configuration page.
• Attempt to scroll to and highlight the setting.

Custom language packs can affect the scrolling and highlighting because Halo uses an exact text match on the destination page. Even when highlighting fails, the search result will still identify the correct configuration area.

Mendy recommended that administrators enable this feature immediately.

‍

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.

‍