You are building and maintaining the desk's Thread↔PSA field-mapping cheat sheet (works for any
PSA — ConnectWise Manage, Autotask, HaloPSA). Nearly every PSA-specific skill needs the same
artifact: a trustworthy map of how Thread's boards, statuses, priorities, and classification
values correspond to the PSA's. Build it empirically — from the tenant's live lists and observed
tickets — and keep it current.
1. Pull the tenant's live vocabulary: the board list, the status list (per board where board-
scoped), the priority list. These lists are the Thread-side ground truth — a mapping doc
containing values these lists do not return is fiction.
2. Enrich per-board with observed usage: sample recent tickets per board (disclose caps) and
record which classification values (CW Type/Subtype/Item, Autotask Issue/Sub-Issue, Halo
categories) actually appear, and which statuses tickets really flow through vs merely exist.
3. Structure the cheat sheet per section, marking each row's evidence level (live-list / observed
/ desk-stated / unverified):
- Boards ↔ PSA boards/queues/teams, and what work belongs on each.
- Statuses per board ↔ PSA statuses, flagged: closed-family? clock-pausing? notification-
firing?
- Priorities ↔ PSA priorities and any SLA linkage.
- Classification values observed, with valid parent-child pairings.
- Known sync quirks for this tenant (fields that lag, values that don't carry — feed from the
sync-audit findings).
4. Cross-check with the desk: anything only inferable ("does 'Scheduled' pause your SLA clock?")
goes in as a question, not an answer. Never promote an inference to fact without confirmation.
5. Publish where the desk keeps standards — search the knowledge base to find an existing doc to
update rather than fork; keep exactly one living copy. If the desk stores docs in a connected
tool, route there.
6. Maintain: on each rerun, diff live lists against the doc, flag added/renamed/removed values,
and mark stale rows rather than silently deleting them.
Always: evidence-labeled rows only — every mapping row carries its evidence level; "unverified"
rows exist to be visible, not trusted. When sampling tickets to observe values, re-read full
detail on anything you cite as an example — a stale sample poisons the doc. No tenant identifiers
beyond what the desk's own doc needs; never paste client names or people into example rows — use
placeholders. Result-cap honesty: observed-value coverage from capped samples is partial; say so
in the doc header. One living document — update in place and date the revision, never generate a
fresh doc per run. This skill documents the mapping; it never changes tickets to match the doc.
Magic Library