HaloPSA Automation Rules: A Practical Guide to Workflows That Actually Work

Last month I helped an MSP owner troubleshoot a problem where high-priority tickets were sitting untouched for hours. His team swore they never saw them come in. Turns out, he had built an automation rule to route critical tickets to his senior engineers, but a second rule (created six months later by someone else) was reassigning those same tickets to the general queue based on the ticket type. The two rules were fighting each other every time a critical ticket came in, and the ticket was bouncing between queues so fast that nobody's dashboard ever caught it.

That's HaloPSA automation in a nutshell. When it works, it's the best thing about the platform. When it doesn't, it creates problems that are almost impossible to diagnose without understanding exactly how the engine processes rules.

This guide is everything I've learned about building HaloPSA automations that actually hold up in production.

How HaloPSA's Automation Engine Actually Works

Before you build anything, you need to understand the execution model. HaloPSA processes automation rules based on trigger events, and the order matters more than most people realize.

When a ticket event occurs (creation, status change, field update, SLA breach), HaloPSA evaluates all active automation rules that match that trigger type. Rules execute in the order they appear in the automation list, top to bottom. If Rule 1 changes a field, and Rule 2's conditions depend on that field, Rule 2 will see the value that Rule 1 just set, not the original value.

This sequential processing is powerful when you design for it. It's a nightmare when you don't.

HaloPSA's documentation covers the basics of rule creation (HaloPSA Automation Guide), but the execution order behavior and rule interaction patterns are things you learn from building and breaking things in production.

Trigger Types You Actually Need

HaloPSA supports several trigger types. Here are the ones I use constantly and the ones I almost never touch:

High-value triggers:

• Ticket Creation - The most common trigger. Routes new tickets, sets initial fields, sends acknowledgment emails. Every MSP needs at least three or four rules on this trigger.
• Status Change - Fires when a ticket moves between statuses. Essential for SLA management, notification chains, and workflow progression.
• SLA Breach (Warning and Violation) - Fires when an SLA timer hits a threshold. This is how you build escalation chains that actually work.
• Field Change - Fires when a specific field value changes. Useful for priority escalation, team reassignment, and audit logging.

Situational triggers:

• Ticket Update - Fires on any update. Be careful with this one. It fires constantly and can create performance problems if the conditions aren't tightly scoped.
• Scheduled - Fires on a time-based schedule. Useful for stale ticket cleanup and periodic reporting, but don't overload it.
• Agent/User Response - Fires when a client or agent adds a note. Good for reopening closed tickets when a client responds.

Rarely worth the complexity:

• Approval-based triggers - Useful in very specific change management workflows, but most MSPs don't need this level of formality for day-to-day service delivery.

Pattern 1: Ticket Routing That Scales

The most important automation you'll build is ticket routing. Get this right and your dispatch overhead drops dramatically. Get it wrong and tickets land in the wrong queue, sit unassigned, or ping-pong between teams.

Here's the routing pattern I use for most MSPs:

Layer 1: Client-Based Routing

Create rules that match on the client (or client site) and route to the appropriate team. If you have dedicated account teams or client tiers, this is where that logic lives.

• Condition: Client = "Acme Corp" AND Ticket Type = "Incident"
• Action: Assign to Team = "Acme Dedicated Team", Set Priority based on client SLA tier

Layer 2: Category-Based Routing

For tickets that don't match a client-specific rule, route based on category or ticket type.

• Condition: Category = "Network" AND Priority >= "High"
• Action: Assign to Team = "Network Engineering"
• Condition: Category = "Onboarding/Offboarding"
• Action: Assign to Team = "Projects", Set Status = "Scheduled"

Layer 3: Default Catch-All

Every routing setup needs a catch-all. If a ticket doesn't match any specific rule, it should land somewhere visible with a flag that says "this needs manual triage."

• Condition: Team = Unassigned (after all other rules have run)
• Action: Assign to Team = "Service Desk", Add internal note = "Auto-routed to default queue. Needs manual triage."

The key principle: build routing in layers, most specific to least specific. Client rules first, then category rules, then the catch-all. This way, a ticket for Acme Corp's network issue goes to the Acme team (Layer 1), not the generic Network Engineering team (Layer 2).

Pattern 2: SLA Escalation That Actually Escalates

Most MSPs configure SLAs in HaloPSA but never build the automation to enforce them. The SLA timers tick, they breach, and nothing happens except a color change on a dashboard nobody's watching.

Here's how to build escalation that forces action:

Warning Threshold (75% of SLA)

• Trigger: SLA Warning
• Condition: Priority = "Critical" or "High"
• Actions:
  • Send notification to assigned agent: "Ticket #[ID] is approaching SLA breach. [X] minutes remaining."
  • Send notification to team lead
  • Add internal note logging the warning

Breach Threshold (100% of SLA)

• Trigger: SLA Violation
• Condition: Response SLA breached
• Actions:
  • Reassign to team lead
  • Send notification to service manager
  • Change priority up one level (if not already Critical)
  • Add internal note: "SLA BREACHED. Auto-escalated to [Team Lead]."

Extended Breach (SLA breached + 30 minutes, no update)

This one requires a scheduled rule that checks for tickets in breach status with no recent activity.

• Trigger: Scheduled (runs every 15 minutes)
• Condition: SLA Status = Breached AND Last Updated > 30 minutes ago AND Status != "Waiting - Client"
• Actions:
  • Send notification to service manager AND owner/partner
  • Add internal note: "Extended SLA breach with no activity. Escalated to management."

The important detail: make sure your "Waiting - Client" status pauses the SLA timer. HaloPSA lets you configure which statuses pause SLA calculations in the SLA configuration settings. If you don't set this up, your SLA metrics will be meaningless because every ticket waiting on a client response will blow through its SLA target through no fault of your team.

Pattern 3: Status-Based Workflow Automation

Status changes are the backbone of ticket lifecycle management. Every status transition should trigger something useful.

New to In Progress

• Trigger: Status changes to "In Progress"
• Actions:
  • Start SLA resolution timer (if not already running)
  • Send client notification: "A technician is now working on your request."

Any Status to Waiting - Client

• Trigger: Status changes to "Waiting - Client"
• Actions:
  • Pause SLA timer
  • Send client notification with the question/request
  • Start a 3-day countdown timer for auto-follow-up

Waiting - Client (3 days, no response)

• Trigger: Scheduled (daily)
• Condition: Status = "Waiting - Client" AND Last Client Response > 3 days
• Actions:
  • Send follow-up email to client: "We're still waiting on your response regarding ticket #[ID]. Please reply at your convenience."
  • Add internal note: "Auto follow-up sent, day 3."

Waiting - Client (7 days, no response)

• Trigger: Scheduled (daily)
• Condition: Status = "Waiting - Client" AND Last Client Response > 7 days
• Actions:
  • Send final email: "We haven't heard back regarding ticket #[ID]. This ticket will be automatically closed in 48 hours if we don't receive a response."
  • Add internal note: "Final follow-up sent, day 7. Auto-close pending."

Waiting - Client (9 days, no response)

• Trigger: Scheduled (daily)
• Condition: Status = "Waiting - Client" AND Last Client Response > 9 days
• Actions:
  • Change status to "Closed"
  • Send closure notification: "Ticket #[ID] has been closed due to inactivity. If you still need assistance, simply reply to this email and we'll reopen it."

This auto-follow-up and auto-close sequence is the single highest-impact automation most MSPs can implement. I've seen it reduce open ticket backlogs by 15-25% within the first month. All those tickets sitting in "Waiting - Client" limbo for weeks finally get resolved or closed.

Pattern 4: Notification Rules That Don't Create Noise

The fastest way to make your team ignore automation is to over-notify. If every ticket event generates an email, your techs will filter all PSA notifications to a folder they never check. Then when something actually important happens, nobody sees it.

My notification philosophy: notify only when human action is required, and make every notification actionable.

Notifications worth sending:

• New ticket assigned to you
• SLA warning on your ticket
• Client responded to your ticket
• Ticket escalated to you
• High-priority ticket created for your client

Notifications NOT worth sending:

• Every status change on every ticket (this is what dashboards are for)
• Time entry added to a ticket
• Internal notes added by other techs (unless explicitly mentioned)
• Ticket closed (the client gets this, your tech doesn't need it)

In HaloPSA, configure notifications at the automation rule level, not at the global notification settings level. This gives you precise control over who gets notified, when, and why. The global notification settings are a blunt instrument. Automation rule notifications are a scalpel.

Common Gotchas That Will Waste Your Time

I've hit every one of these. Learn from my mistakes.

1. Circular Rule Triggers

Rule A changes a status, which triggers Rule B, which changes a field, which triggers Rule C, which changes the status back, which triggers Rule A again. Infinite loop. HaloPSA has some built-in loop protection, but it doesn't catch everything, and when it does catch it, it silently stops processing, which means your downstream rules don't fire.

Prevention: Map your rules on paper (or a whiteboard) before building them. Draw arrows showing which rule can trigger which other rule. If you see a cycle, redesign.

2. Rules That Fire on Their Own Changes

If you have a rule that triggers on "ticket updated" and one of its actions is to update the ticket (add a note, change a field), it will trigger itself. HaloPSA handles some self-trigger scenarios, but not all of them consistently.

Prevention: Use the most specific trigger possible. Don't use "ticket updated" when "status changed" or "field changed" would work. The narrower your trigger, the less likely you are to create self-triggering loops.

3. Test Tickets That Trigger Production Rules

You create a test ticket to verify a new automation rule, and it fires every production rule you've got, sending emails to clients, escalating to managers, and creating a mess.

Prevention: Create a dedicated test client and test team in HaloPSA. Build an exclusion condition into your production rules: "Client != Test Client." Run all automation testing under that test client. This is five minutes of setup that saves hours of cleanup.

4. Automation Rules That Reference Deleted or Renamed Items

You rename a team, delete a ticket type, or change a status name, and you forget that three automation rules reference the old name. The rules silently fail because their conditions no longer match anything.

Prevention: Before renaming or deleting anything in HaloPSA, search your automation rules for references to that item. HaloPSA doesn't always warn you about downstream dependencies. This is a manual check you need to build into your change process.

5. Too Many Scheduled Rules Running Too Frequently

Scheduled automations that run every 5 minutes and query large ticket sets will slow down your HaloPSA instance. I've seen environments where aggressive scheduled rules added noticeable latency to ticket loading.

Prevention: Run scheduled rules at the minimum frequency needed. Stale ticket checks don't need to run every 5 minutes. Once or twice a day is fine. SLA-related scheduled checks can run every 15-30 minutes. Scope your conditions tightly so the rule evaluates the smallest possible ticket set.

Performance Tips for Larger Environments

If you're running more than 20 automation rules, performance matters.

Order your rules by frequency. Put your most commonly triggered rules at the top of the list. Since HaloPSA evaluates rules top-to-bottom, putting your high-frequency rules first means the engine finds a match faster and spends less time evaluating rules that rarely fire.

Use exit conditions. If a rule matches and you don't want subsequent rules to process the same ticket on the same trigger event, use conditions that prevent downstream rules from matching. For example, if Rule 1 assigns a ticket to Team A, and Rule 2 should only fire on unassigned tickets, Rule 2's condition of "Team = Unassigned" naturally prevents double-processing.

Archive instead of deleting. When you retire a rule, disable it instead of deleting it. You might need to reference the logic later when building a replacement, and HaloPSA doesn't have a rule history or audit log for deleted rules.

Review quarterly. Set a calendar reminder to review all automation rules every quarter. Check that conditions still reference valid teams, statuses, and ticket types. Check that the rule's purpose still matches a current business process. Disable anything that's orphaned. I've found that roughly 10-15% of automation rules in any environment older than a year are stale.

Building Your First Automation Set

If you're starting from zero, don't try to build everything at once. Start with these five rules and expand from there:

1. Auto-route new tickets to the appropriate team based on ticket type or category
2. Send SLA warning notifications to the assigned tech and team lead
3. Escalate SLA breaches to the service manager with automatic reassignment
4. Auto-follow-up on Waiting - Client tickets after 3 days
5. Auto-close inactive tickets after 7-9 days with client notification

Those five rules will handle 80% of your automation needs. Build them, test them thoroughly under a test client, run them for two weeks, and review the results before adding more complexity.

Every rule after those five should solve a specific, documented problem. "We keep having X happen and it wastes Y hours per week" is a good reason to build a rule. "It would be cool if..." is not.

Wrapping Up

HaloPSA's automation engine is genuinely powerful. I've built environments with 40+ rules handling everything from ticket routing to project milestone tracking to automated procurement workflows. When the rules are well-designed, well-documented, and well-maintained, they transform how an MSP operates.

But the gap between "powerful" and "reliable" is entirely about discipline. Name your rules clearly. Document the logic. Test in isolation. Review quarterly. And never, ever build a new rule without checking how it interacts with every existing rule on the same trigger.

If your HaloPSA automation feels fragile or unpredictable, it's probably not a platform problem. It's an architecture problem. And architecture problems are fixable.

---

Need help designing or untangling your HaloPSA automation rules? That's exactly the kind of thing PaxRig does. Book a discovery call and we'll map out an automation architecture that holds up as you grow.