CW Service Board Conventions

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.