Choosing the Right Ticket Status Colors in HaloPSA

If you work in IT, you’ve been here: you’re restoring someone’s laptop and see photos you weren’t looking for. You find software nobody paid for. Someone senior asks you to print something and keep it between the two of you. You turn around and found yourself out in the middle of nowhere, relying on your best judgement -- hoping it was to make the right call -- and using the next complex problem to push aside any lingering doubts about your choice.

That’s what North Star is about. Over three Tuesdays, Matt Topper and Mendy Green will talk through the everyday judgment calls that come with working in tech. They’ll use ideas borrowed from law, medicine, and engineering, not to tell you what to do, but to give you perspective and context for the decisions you've had to make, and hopefully help you re-center on your moral compass. You're navigating constant grey areas often with little to no training.

Let's change that.

These three conversations are free to attend, will last 45 minutes, and they're live, so bring your team and a scenario of your own to the chat! We hope you'll include even your greenest employees on these sessions. You and your techs make these calls every day and, as always, an ounce of preparation is worth a pound of cure.

The schedule (all at 1 PM ET):

• Nov 24 · Part 1: Conscience Doesn’t Scale: why “what would the boss do?” stops working
• Dec 1 · Part 2: Where’s the Line?: pirated software, personal files, and how far is too far
• Dec 8 · Part 3: Keep This Between Us: when the client, your boss, and your gut disagree

Save your seat

Add all three sessions to your calendar → LINK HERE

See you on November 24th!

‍

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.

‍