Introduction

HaloPSA's automation capabilities are among the most powerful in the PSA market — and among the most underutilised. Most MSPs go live with a basic ticket flow and a handful of email notifications, leaving the majority of the platform's automation potential untouched.

The reason is usually the same: the distinction between HaloPSA's automation layers isn't immediately obvious, and without a clear mental model of how they fit together, it's hard to know where to start.

This guide breaks down HaloPSA automation into its two core components — Workflows and Automation — and explains how to use each one to build a service delivery operation that scales without adding headcount.

Part 1: Workflows — Structuring the Ticket Lifecycle

What a Workflow Does

A Workflow in HaloPSA defines the lifecycle of a ticket. It determines what stages a ticket passes through from creation to closure, what actions are available to agents at each stage, and what happens automatically as the ticket progresses.

The key insight is that a well-designed Workflow doesn't just track what happened to a ticket — it actively guides what should happen next. Agents see only what's relevant to their current stage. Options that don't apply are hidden. The platform does the thinking so your team doesn't have to.

This is a fundamental difference from a basic ticketing setup, where agents see every possible action on every ticket at all times and rely on tribal knowledge to know what to do when.

Forcing Process with Workflow Steps

One of the most effective uses of HaloPSA Workflows is enforcing a triage step before any other work can be done on a ticket.

The pattern is widely used and highly effective: when a ticket is created, the only action available to the agent is a Triage Action. Until they complete it — assigning a category, priority, team, and any other required fields — no other options are presented. The ticket cannot be updated, escalated, or billed against until it has been properly profiled.

The operational impact is significant. Ticket data quality improves immediately. Routing accuracy goes up. SLA calculations become reliable because they're based on correctly categorised tickets. Engineers stop spending time sorting through miscategorised work, and management gets reporting they can actually trust.

This is the kind of outcome that process design delivers — not technology. HaloPSA's Workflow engine makes it enforceable.

What Lives Inside a Workflow Step

Each step in a Workflow can contain three types of elements: Actions, Ticket Rules, and Runbook triggers. Understanding what each does and when to use each one is the foundation of effective HaloPSA automation.

Part 2: Actions — What Agents Can Do

The Role of Actions

Actions are the operations available to an agent at a given workflow step. They can be manual — presented as buttons the agent clicks when they're ready — or automated, firing without agent input when conditions are met.

Actions can be simple: change the ticket status, reassign to a different team or agent, add a note, send an email, start an approval process, attach a report. Or they can leverage a System Use — a predefined functional behaviour built into HaloPSA — to do something more specific.

System Uses: Extending What Actions Can Do

System Uses are where Actions become genuinely powerful. Three examples that are directly relevant to ticket management:

Create Child Ticket allows an agent to spin off a sub-task from a parent ticket. The use case is any scenario where a ticket involves parallel workstreams — a new device setup, for example, might generate child tickets for software installation, network configuration, and asset registration, each assigned to a different engineer. The parent ticket tracks overall progress; child tickets track individual deliverables. HaloPSA can be configured to automatically update the parent ticket status when all children are closed.

Re-assign is more than a field change. As a System Use, it controls who can perform the reassignment based on permissions, optionally changes the ticket status at the same time, and can be configured to work even on locked tickets. For MSPs with defined escalation paths, this is how you make escalation a controlled, auditable event rather than an informal handoff.

Send Webhook / Queue Integration Runbook is the bridge between the Actions layer and the automation layer. When an agent completes this Action, it triggers a Runbook — opening up the full range of automation capabilities. We'll cover Runbooks in detail in Part 4.

Quick Actions

Quick Actions are a subset of Actions that execute immediately without requiring the agent to fill in additional fields. They're ideal for high-frequency, low-friction operations — claiming a ticket, marking a standard task complete, moving to the next workflow step — where adding a form would slow the team down without adding value.

Used well, Quick Actions are the difference between a workflow that guides engineers and one that frustrates them.

Part 3: Ticket Rules — Automation Within the Workflow

How Ticket Rules Work

A Ticket Rule fires automatically when defined criteria are met. Unlike Actions — which require an agent to do something — Ticket Rules run in the background, evaluating conditions and executing outcomes without any human touchpoint.

Each rule has two components: criteria (the conditions that must be true for the rule to fire) and outcomes (what happens when it does).

Ticket Rules Inside and Outside Workflows

Ticket Rules can be created in two ways: inside a Workflow step, or globally at the system level. When created globally — outside of Workflows — rules are evaluated in sequence, and the order in which they are processed matters. A rule created later can interact with or override the logic of an earlier one, and without careful management this is a common source of unexpected behaviour — a ticket routed correctly by one rule being immediately rerouted by another, or a status change being overwritten before the agent even sees it.

To manage this, HaloPSA provides a "Stop Matching" option on individual global rules. When enabled, if a rule fires successfully, no further rules in the sequence are evaluated for that ticket — giving you control over rule priority and preventing unintended interactions.

Ticket Rules created inside a Workflow step don't carry this risk. They are scoped to a specific stage of the ticket lifecycle, which makes their logic explicit and their behaviour predictable. This is why, as a general practice, Ticket Rules are best created and maintained inside Workflow steps rather than as standalone global rules.

Trigger Options

Rules within a workflow step can be triggered in three ways:

Immediately when the step is entered or the ticket is updated and conditions are met.

After a pre-determined number of minutes following the trigger condition — useful for time-delayed escalations or reminders.

A pre-determined number of days before or after a field value — useful for contract-linked dates, scheduled reviews, or follow-up sequences.

This flexibility means Ticket Rules can handle both reactive automation (something changes, something else happens immediately) and proactive automation (a deadline is approaching, take action now).

Common Outcomes

The most commonly used outcomes in Ticket Rules:

Change Team / Agent — automatic routing based on ticket attributes.

Change Status — moving tickets through the lifecycle without agent input.

Change Priority or Category — escalating based on client tier, SLA proximity, or keyword detection.

Associate a Ticket Template — applying a predefined structure to tickets that match certain criteria.

Trigger a Notification — alerting engineers, managers, or clients based on ticket state.

Update a Field — writing to any system or custom field, enabling downstream logic and reporting.

The power of Ticket Rules is in their composability. A single ticket passing through a multi-step workflow might trigger a dozen rules — routing it, categorising it, notifying stakeholders, escalating it if it sits too long, and flagging it for billing at closure — all without any agent input beyond the work itself.

Part 4: Runbooks — Automation Beyond the PSA

What Runbooks Do

Runbooks are HaloPSA's most advanced automation layer. Where Ticket Rules operate on ticket data within HaloPSA, Runbooks can interact with any system that exposes an API — including HaloPSA itself.

A Runbook is a sequence of steps that can read data, make decisions, call external endpoints, and write results back to HaloPSA. The trigger can be an Action (an agent clicks a button), a Ticket Rule (conditions are met), or a scheduled event (run at a defined time).

What's Possible

The scope of what Runbooks can automate is determined by what APIs are available — which in most MSP tool stacks means almost anything.

HaloPSA's own API is fully accessible from Runbooks, meaning you can automate operations within HaloPSA itself — creating related tickets, updating contract records, generating reports, triggering billing actions, or synchronising data across clients and assets based on logic that would be too complex to express in a Ticket Rule.

Beyond HaloPSA, Runbooks can connect to your RMM, your security stack, your documentation platform, or any other tool in your environment. The automation possibilities compound as your Runbook library grows — each integration you build becomes a reusable building block for future workflows.

Starting With Runbooks

Runbooks have a steeper learning curve than Workflow Rules or Actions. They require comfort with API concepts, JSON data structures, and sequential logic. For MSPs without this technical bandwidth internally, the right approach is to start with the highest-value use case for your operation and build from there, either internally or with the help of a consultant.

The compounding return on a well-built Runbook library is significant. Every hour of manual work automated by a Runbook is an hour your engineers spend on work that actually requires their judgement.

Putting It Together

The four layers — Workflow structure, Actions, Ticket Rules, and Runbooks — aren't independent features. They're designed to work together. A well-architected HaloPSA setup uses each layer for what it does best:

Workflows define the process and enforce it.

Actions give agents the right tools at the right moment.

Ticket Rules handle the repetitive logic automatically.

Runbooks connect HaloPSA to the rest of your tool stack.

MSPs that design these layers deliberately — rather than configuring them reactively as needs arise — end up with a platform that actively runs their service operation rather than just recording it.

Want Help Designing Your HaloPSA Automation Architecture?

Getting the Workflow and Automation layers right from the start saves months of rework later. At Kinesys, we design HaloPSA implementations that are built to scale — from Workflow structure through to Runbook development.

→ Book your free consultation

kinesys.it • info@kinesys.it • HaloPSA Official Partner & Autotask Experts