ConnectWise PSA is probably the most powerful tool in your tech stack. It's also, without question, the most misconfigured. I've lost count of how many ConnectWise instances I've opened up and immediately found boards that serve no purpose, workflow rules fighting each other, agreement billing that misses entire categories of charges, and custom fields that nobody remembers creating.
The thing about ConnectWise is that it can do almost anything. That's its greatest strength and its biggest trap. Because "can do anything" very quickly becomes "does a lot of things poorly" when the configuration is built reactively — adding a board here, a status there, a workflow rule because someone complained about something once — instead of designed intentionally.
This guide is how I approach a ConnectWise configuration from the ground up. Whether you're setting it up for the first time or trying to unfurl years of accumulated configuration debt, these are the decisions that matter most.
Start with the service board structure
Every ConnectWise problem I've ever troubleshot traces back to the board structure eventually. It's the foundation. Get this wrong and everything built on top of it — routing, SLAs, reporting, automation — will be compromised.
Here's the mistake I see constantly: too many boards. Someone creates a board for every client, or every technician, or every sub-category of ticket type, and within a year you've got 25 boards that nobody can keep straight. Dispatching becomes a nightmare, reporting is fragmented across boards, and workflow rules have to account for dozens of board-specific variations.
My general rule: most MSPs under 30 people need somewhere between 4 and 8 boards. That's it.
A typical structure that works well:
Service — Your bread and butter. Break/fix, incidents, general support requests. This is where the bulk of your tickets live.
Projects — Longer-duration, planned work. Onboarding, migrations, infrastructure buildouts. Anything with phases and milestones.
Sales/Pre-Sales — Opportunities, quotes, prospect-related activity. Keeps the sales pipeline visible without cluttering the service queue.
Internal — Internal IT, admin tasks, procurement. Stuff that doesn't belong in a client-facing board but still needs tracking.
Alerts/Monitoring — RMM-generated tickets from your monitoring tools. These need different SLAs and routing logic than human-created tickets, so they get their own board.
That's five boards. Some MSPs add a sixth for Procurement or Change Management if their processes warrant it. But if you're sitting at 15+ boards right now, I'd strongly encourage you to map out which tickets actually land where, and you'll probably find that half your boards get fewer than five tickets a month. Those boards should be consolidated.
Statuses: fewer is better, and naming matters
The default ConnectWise status set is... fine. It's not great. Most MSPs bolt on additional statuses over time, and before long you've got "New," "In Progress," "Waiting on Client," "Waiting on Vendor," "Waiting on Parts," "Waiting on Approval," "Scheduled," "On Hold," "Pending Review," "Escalated," and twelve more that mean slightly different things to different people.
I aim for 6–8 statuses per board, and every single status should answer one question clearly: what is happening with this ticket right now, and who is responsible for the next action?
A status set I've used successfully across a lot of MSPs:
New → Ticket just came in, hasn't been touched. (Next action: triage/dispatch) In Progress → A tech is actively working this. (Next action: tech continues work) Waiting - Client → Ball is in the client's court. We need information or approval. (Next action: client responds) Waiting - Vendor → We're waiting on a third party. (Next action: vendor responds) Scheduled → Work is planned for a specific date/time. (Next action: tech performs scheduled work) Completed → Work is done, pending final review or closure. (Next action: review and close) Closed → Done. Archived.
That's seven. You might add "Escalated" if your escalation process warrants a dedicated status rather than just a sub-type or priority change. But resist the urge to create a new status every time someone identifies a new "waiting" scenario. "Waiting on Parts" is just "Waiting - Vendor" with a note.
Priorities and the Impact-Urgency matrix
ConnectWise has a built-in priority system that supports an Impact-Urgency matrix. I've heard estimates that somewhere around 75% of ConnectWise users don't use it. That's a shame, because when it's configured properly, it takes the subjectivity out of priority assignment and makes SLA enforcement actually defensible.
The concept is simple: Impact (how many people or systems are affected) combined with Urgency (how time-sensitive the issue is) produces a Priority level. A server outage affecting the whole company is high impact, high urgency — Priority 1. A single user who needs a monitor replaced is low impact, low urgency — Priority 4.
Set up a 3x3 or 4x4 matrix. Map every combination to a priority level. Then configure your SLA response and resolution times against those priority levels. Now when a client argues that their non-urgent request should be treated as critical, you've got a framework to point to instead of a subjective argument.
The matrix doesn't need to be complicated. Three levels of impact (one person, multiple people, entire organization) crossed with three levels of urgency (low, medium, high/critical) gives you nine combinations that map cleanly to four priority levels. Done.
Workflow rules: the engine under the hood
This is where ConnectWise either saves you enormous amounts of time or creates cascading chaos that nobody can debug. I've seen both.
The principles I follow for workflow rules:
Name them clearly. "WF - Service - Auto-assign Tier 1 tickets to Help Desk group" is a useful name. "Workflow Rule 47" is not. Future you will thank present you.
Document the logic. Every workflow rule should have a note (I use the internal notes field) explaining what it does, why it exists, and when it was last reviewed. I can't tell you how many times I've found orphaned workflow rules with no documentation that nobody is sure about disabling because "what if it breaks something?"
Avoid conflicts. Two workflow rules that trigger on the same conditions but do different things will fight each other in unpredictable ways. Before creating a new rule, check every existing rule that fires on the same trigger conditions.
Test in isolation. Create a test board. Run your new rule against test tickets. Verify the output before deploying to production. I know this sounds obvious, but you'd be amazed how many workflow rules go straight into production and cause problems for days before anyone notices.
Common workflow rules that almost every MSP should have:
Auto-assign new tickets based on board, type, and client. Auto-close tickets that have been in "Waiting - Client" for X days after an automated follow-up. Escalate tickets approaching SLA breach. Notify the service manager when a high-priority ticket is created. Route RMM alerts to the monitoring board. Auto-apply time entry templates for common ticket types.
Agreement configuration: where the money lives
I could write an entire separate post about agreement billing — and I probably will — but here's what matters most.
Agreements are how your recurring revenue gets tracked and billed in ConnectWise. If they're configured wrong, you're either not billing for things you should be billing for, or you're billing inaccurately and creating client disputes that waste everyone's time.
The most common agreement mistakes:
No additions configured for variable-count products. If a client's M365 license count changes and your agreement doesn't have an addition set up to track that automatically, you're manually reconciling license counts every month. Or more likely, you're not, and you're losing money.
Agreement types that don't match your actual service delivery. ConnectWise supports several agreement types — standard, prepaid hours, block time, retainer, and more. Using the wrong type for how you actually deliver the service creates billing friction.
No agreement exclusions for out-of-scope work. If your managed agreement covers standard support but not project work, and there's no exclusion rule configured, techs will log project-level time against the managed agreement and it'll never get billed separately.
Stale agreements that haven't been reviewed. I see this constantly. An agreement was created two years ago, the client's environment has doubled in size, and nobody's adjusted the agreement terms. The MSP is effectively providing twice the service for the same price.
Go look at your agreements right now. Pick your top five clients by revenue. Check whether the agreement additions are up to date, whether the covered devices/users match reality, and whether the billing amounts reflect your current rate card. I'd bet money at least one of them is off.
Integrations: your PSA isn't an island
ConnectWise needs to talk to your RMM, your accounting platform, your documentation system, and probably half a dozen vendor portals. Every integration that's broken, misconfigured, or simply not set up is a manual process someone on your team is doing by hand.
The must-have integrations:
Accounting (QuickBooks or Xero) — Invoices, payments, and product costs flowing automatically. RMM — Bidirectional. Alerts create tickets. Configurations sync. Device data is current. Documentation (ITGlue, Hudu) — Click from a ticket to the client's documentation without switching tools.
The nice-to-have integrations that make a surprising difference:
BrightGauge or Power BI — Real dashboards instead of ConnectWise's built-in report writer, which is functional but painful. Rewst — If you're doing any kind of process automation beyond what ConnectWise workflow rules can handle, Rewst fills the gap.
The stuff nobody talks about
A few things that don't fit neatly into categories but matter a lot in practice:
Clean up your configuration items. If your Configurations tab is full of decommissioned devices, former employees' workstations, and servers that were retired three years ago, your agreement billing based on configuration counts is wrong. Garbage in, garbage out.
Review your custom fields annually. You'll find fields that were created for a one-time project and never removed, fields with dropdown options that don't match current terminology, and fields that duplicate information available elsewhere in the ticket.
Security roles need attention. Most MSPs set up security roles once during implementation and never revisit them. People accumulate permissions over time as they move between roles or take on new responsibilities, and nobody ever removes the old access. Review quarterly.
API member keys. Every integration that connects to ConnectWise uses an API key tied to a member account. If that member account gets deactivated or if someone changes the password, the integration breaks. Document which integrations use which API keys, and make sure those member accounts are clearly flagged as integration accounts that shouldn't be modified.
Where to start if your ConnectWise is a mess
If you're reading this and recognizing your own environment in every section, don't try to fix everything at once. You'll burn out and nothing will get finished.
Start with the three things that directly impact revenue: agreement billing accuracy, time entry compliance, and invoice generation. Fix those first. Everything else — boards, workflows, integrations, reporting — is important but secondary to making sure you're actually collecting the money you've earned.
Then work outward: clean up the board structure, rationalize your statuses, document your workflow rules, and build reporting that tells you something useful. Take it in 2-week sprints. Each sprint targets one system. That's manageable even when you're running an MSP at the same time.
Or bring in somebody who's done it before and can compress months of fumbling into weeks of focused execution. That's an option too.
Want help getting your ConnectWise instance in shape? Book a discovery call — I'll take a look at your setup and tell you where to start.
Cory Neese
Founder & PSA Consultant at PaxRig
Cory helps MSPs get more out of their ConnectWise and HaloPSA platforms through expert configuration, migration, and automation. He founded PaxRig to bring enterprise-level PSA expertise to the MSP channel.