Kaseya BMS Workflow

You are keeping status and queue changes inside the Kaseya BMS (Vorex lineage) model and
reconciling drift. BMS organizes service tickets by queue (the routing unit Thread mirrors as a
board), status (a global list, not per-queue as on ConnectWise), ticket type, and location —
the client site, which drives dispatch and contract selection. Service Desk and Projects are
separate modules.

1. Re-read the ticket at full detail. Never act on a status or queue seen earlier — BMS→Thread
   sync lags by minutes, and a stale list result is not evidence of divergence.

2. Pull the live status and queue lists. BMS statuses are tenant-configured from a global list,
   so verify rather than assume the common defaults (New, Assigned, In Progress, Waiting for
   Customer, Completed) exist here, and never set a status or queue the live lists didn't
   return.

3. Status moves: map the request onto a status that exists, then classify it before writing —
   completed-family (which closes the ticket in BMS)? stops the SLA clock? triggers a BMS
   workflow or notification? State every side effect in your proposal. Never close a ticket as
   a side effect of a status move; completed-family transitions are deliberate acts with their
   own QA gate.

4. Queue moves: confirm the target queue exists and warn that a queue change in BMS can
   re-trigger routing and assignment workflows and change which SLA applies. Confirm before
   moving.

5. Service desk vs projects: an item you can't find may be a BMS project task — those follow
   the Projects module's own statuses and generally don't appear in Thread. Say so explicitly
   rather than reporting "ticket does not exist", route it to a human with BMS access, and
   never touch project tasks.

6. Location: where a client has several sites, check the ticket's location against the contact
   and the reported site. A wrong location can bill against the wrong contract in BMS — flag
   the mismatch, never silently fix it.

7. Sync audit, on request, per queue: split the searches per signal — tickets completed-family
   in BMS but open in Thread, open tickets whose Thread queue doesn't match the desk's map,
   tickets stuck in a waiting status past the desk's threshold. Give counts and samples, saying
   "at least N" where a search may have capped (apply the Sweep Honesty skill), and reconcile
   one ticket at a time, proposing before applying.

8. Output current state in each system, the proposed change and its side effects. Apply only
   after confirmation, then record it in a note — plain text, no markdown or emojis (apply the
   PSA Note Discipline skill).

BMS is master: when the two disagree Thread moves to match BMS, never the reverse, unless the
desk documents an exception. If this tenant's sync doesn't carry queues or locations into
Thread, run advisory-only from the desk's documented map and state that limitation.