ConnectWise Workflow Rules: A Practical Guide That Skips the Theory

Workflow rules are the most powerful and most neglected feature in ConnectWise PSA. When they're configured well, they eliminate hours of manual work every day — routing tickets automatically, enforcing SLAs, escalating stuck issues, and keeping your team focused on actual work instead of administrative housekeeping. When they're configured poorly, they create cascading chaos that's almost impossible to debug.

I've inherited ConnectWise instances with 80+ workflow rules where nobody could explain what half of them did. I've also built rule sets from scratch for MSPs that had been routing every ticket by hand for years. Both experiences taught me the same thing: a small number of well-designed rules beats a large number of rules that grew organically.

Here's the practical approach I use.

The rules every MSP should have (and probably doesn't)

Before getting into the details, here are the workflow rules I consider essential for any MSP running ConnectWise. If you don't have these running right now, this is your starting shortlist:

Auto-route new tickets by board and type. When a ticket hits the Service board with a type of "Network Issue," it should automatically get assigned to the networking team or a specific tech based on your resource groups. No dispatcher intervention needed for routine routing.

Escalate tickets approaching SLA breach. If a ticket's SLA response time is 80% elapsed and it hasn't been responded to, automatically escalate — either by changing priority, notifying a manager, or reassigning to a backup resource.

Follow up on client-waiting tickets. If a ticket has been in "Waiting - Client" status for 48 hours (or whatever your threshold is), automatically send a follow-up email to the client. If they don't respond after a second follow-up, auto-close with a note.

Notify management on Priority 1 creation. When a critical-priority ticket gets created, immediately notify the service manager and the team lead. Don't rely on someone checking the dispatch board at the right moment.

Alert on stale tickets. If a ticket has been in "In Progress" status for more than X hours without a time entry or note update, flag it. A ticket that's supposedly being worked but shows no activity is either forgotten or miscategorized.

Auto-assign based on client. If a client has a dedicated technician or team, tickets from that client should route directly. This is especially important for VIP clients with dedicated SLAs.

That's six rules. Most MSPs I audit either have none of these or have versions of them that are misconfigured and not actually firing correctly.

Naming conventions: boring but essential

When you're looking at a rule list and trying to figure out what "Workflow Rule 23" does, you've already lost. Name your rules so that anyone — including future you — can understand what they do at a glance.

The format I use: [Trigger] - [Board] - [Action]

Examples:

• "New Ticket - Service - Auto-route by Type"
• "SLA Warning - Service - Escalate at 80%"
• "Status Change - Service - Client Follow-up after 48h Waiting"
• "Priority 1 - All Boards - Notify Service Manager"
• "Stale Ticket - Service - Alert after 4h No Activity"

You can immediately tell what each rule does, which board it applies to, and what triggers it. When something goes wrong, you know exactly where to look.

Building rules that don't conflict

The number one problem with workflow rules in mature ConnectWise environments is conflicts. Two rules trigger on the same conditions and do contradictory things. One rule assigns a ticket to Tech A, another reassigns it to the Help Desk group. One rule changes the status to "In Progress," another changes it back to "New." The result is unpredictable behavior that nobody can troubleshoot.

Before creating any new rule, I always do this:

Open the workflow rules list. Filter to the same board. Review every rule that fires on the same trigger event (ticket created, status changed, SLA warning, etc.). Check for overlapping conditions. If a new rule's conditions overlap with an existing rule, either modify one to add exclusion conditions or combine them into a single rule with the right logic.

ConnectWise processes workflow rules in order. If two rules conflict, the one that processes last wins. This ordering dependency is fragile and hard to maintain, so it's much better to avoid the conflict in the first place.

The testing protocol

Never deploy a workflow rule directly to a production board. Every time. No exceptions.

Create a test board (I usually call it "WF Testing" or "Automation Test"). Configure it with the same statuses and types as the target board. Create your rule targeting the test board. Generate test tickets that match the rule's trigger conditions. Verify the rule fires correctly and produces the expected result. Check that it doesn't fire on tickets that shouldn't match.

Only after confirming correct behavior, change the rule's board target to the production board.

This adds maybe 15 minutes to the process and prevents the kind of incident where a misconfigured rule auto-closes 200 tickets overnight. I've seen it happen. More than once.

Debugging rules that aren't working

When a workflow rule isn't firing and you can't figure out why:

Check the event. Is the rule set to trigger on "Ticket Creation" but the ticket was created via email parser, which might use a different internal event? Email-parsed tickets sometimes behave differently than manually created ones.

Check every condition. Open the rule and walk through each condition against the ticket that should have triggered it. I've found issues where a condition was checking for "Board = Service" but the ticket was on a sub-board, or a type condition was checking for an exact match that had a trailing space in the name.

Check the processing order. If another rule fires first and changes the ticket's properties (status, priority, board), your rule might no longer match by the time it processes.

Check the activity log. ConnectWise logs workflow rule execution in the ticket's activity/audit trail. Look for entries showing the rule fired but the action failed, or entries showing a different rule fired and changed conditions before yours processed.

Disable and re-enable. Sometimes — and I don't love admitting this — a rule just needs to be toggled off and back on after a change. It's not documented anywhere, but I've seen it clear up issues more than once.

Advanced patterns

Once your basic rules are solid, there are some more sophisticated patterns worth considering:

Cascading escalation. Instead of a single escalation rule, build a series: at 50% SLA, change the ticket color/flag. At 75%, notify the assigned tech. At 90%, notify the manager and reassign to a senior resource. At 100% (breach), notify the service director. This gives your team graduated warnings instead of a single alarm.

Auto-categorization based on email content. If your email parser creates tickets on a catch-all board, you can use workflow rules with note/description content matching to automatically categorize and route. "Password" in the subject → type "Password Reset" → route to Help Desk. This isn't perfect — keyword matching is blunt — but it catches the common cases.

Automated time entry creation. For certain ticket types where the work is predictable (password resets, new user onboarding), you can auto-create a time entry with a default duration. The tech adjusts if needed, but the baseline entry ensures the work gets captured even if they forget.

After-hours routing. Different rules for tickets created outside business hours. Route to an on-call tech, adjust SLA timers, or auto-respond with expected response times. Requires configuring your business hours in ConnectWise properly first.

Maintenance is not optional

Workflow rules are not set-and-forget. Your business changes. Team members join and leave. Client tiers change. SLA policies evolve. Service boards get restructured.

I recommend a quarterly rule review. Pull up every active rule. For each one, ask: is this rule still relevant? Does it reference team members or groups that still exist? Does it align with our current SLA commitments? Has the business process it automates changed since it was last modified?

Disable or delete rules that are no longer relevant. Update rules that reference outdated resources. Document any changes. A clean, well-maintained rule set with 15 rules will outperform a bloated, unmaintained set with 60 rules every single time.

---

Need help building or cleaning up your workflow rules? Book a call and I'll walk through your current setup.