> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CW Service Board Conventions

> For desks synced to ConnectWise Manage running multiple boards — decide which work belongs on which board and execute cross-board moves without losing status, classification, or history.

<Info>
  **Category:** PSA-Specific Workflows · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/psa-specific/cw-service-board-conventions/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Dispatcher](/start-here/roles/dispatcher), [Service & Ops Manager](/start-here/roles/service-ops-manager)

**Outcome:** Faster Resolution & Response, Fewer Escalations & Less Noise

**When to use:** "Which board should this go on?" on a multi-board CW desk, moving a ticket between boards (help desk → projects, alerts → help desk, service → sales), or sanity-checking the desk's board-routing conventions.

**Run it:** on one ticket · across all misrouted tickets on a board · or as a Flow (triggered when a ticket is created, to place it on the right board).

## Prompt

```
You are deciding board placement and executing cross-board moves on a ConnectWise Manage desk.
Multi-board CW desks split work across boards (help desk, escalations/projects, alerts, sales,
VIP) and almost everything in CW — statuses, types, workflows, SLAs, team assignments — is
board-scoped. Moving a ticket between boards is a small migration, not a field edit.

1. Re-read the ticket at full detail and pull the live board list.

2. Decide the destination from the nature of the work, per the desk's conventions: reactive
   support vs project-sized effort vs monitoring alert vs sales/procurement. If the desk has a
   routing rules engine, defer to it; this skill covers CW-specific mechanics.

3. Before moving, snapshot what the move will destroy or reset: in CW, a board change re-maps
   status to the destination board's workflow (often back to its default/new status), and the
   destination board's types/subtypes/items differ. Record current board, status, and
   classification in a plain-text note — this is the history that survives.

4. Execute the move, then in the same pass set a valid destination-board status (from the
   destination board's status list) and re-classify per the destination board's taxonomy.
   Never leave a moved ticket sitting on the destination board's default status with stale
   classification.

5. Check side effects: destination board's SLA and notification workflows now apply; owner/team
   may need reassignment to someone who works that board.

6. Output: source → destination, the pre-move snapshot note text, the post-move
   status/classification you set, and anything (owner, SLA) still needing a human decision. For
   bulk moves, propose the list first and move only after confirmation.

Always: re-read full ticket detail immediately before the move; the ticket may already have
been moved or closed in CW. A board move without the snapshot note loses context permanently —
the note is mandatory and must be plain text. Never move a ticket to a board whose statuses you
have not fetched; you cannot set a safe landing status blind. Cross-board moves can restart or
void SLA tracking — call it out every time; never move a ticket inside an active SLA breach
window without explicit confirmation. One ticket, one board: if only part of the work belongs
elsewhere, split first rather than bouncing the whole ticket. If the desk's board conventions
are undocumented, propose the routing and label it a convention proposal — do not present it as
established policy.
```


## Related topics

- [CW Time Entry Conventions](/skill-library/psa-specific/cw-time-entry-conventions.md)
- [CW Project Tickets](/skill-library/psa-specific/cw-project-tickets.md)
- [CW Configurations Assets](/skill-library/psa-specific/cw-configurations-assets.md)