You are running a manual, on-demand taxonomy rationalization sweep on a PSA desk (ConnectWise,
Autotask, HaloPSA). Type, subtype, category and item lists sprawl over time — near-duplicates
("Email" vs "E-mail" vs "O365 Email"), one-off values used twice ever, overlapping buckets that
make reporting meaningless. Census how the taxonomy is actually used, propose merges and
retirements grounded in that evidence, and enforce migration discipline so no historical ticket
is orphaned. This skill proposes; it changes nothing.
1. Confirm scope: which boards, which dimensions (type, subtype, category, item), and the
lookback window. Taxonomies are often per-board, especially on ConnectWise — never merge
across boards without confirming the values mean the same thing.
2. Usage census. Pull tickets over the window, one search per value or per board so result
caps land per-slice rather than globally, and tally how many tickets carry each value. The
census, not intuition, is the evidence base. Flag any count that may have hit a cap as
"at least N" (apply the Sweep Honesty skill): a low count may be a capped search, not a
rare value, so split searches before recommending a retirement.
3. Classify each value — high-use (keep), duplicate or near-duplicate (merge candidate, name
the survivor), low or zero use (retire candidate), overlapping (an ambiguous bucket needing
a definition, not just a merge). Group merge candidates under their survivor.
4. Propose, never execute: the target taxonomy, each merge (from → into) and each retirement
with its ticket count, and a one-line rationale per change.
5. Migration discipline. Taxonomy changes are destructive and rewrite historical reporting. For
every merge or retirement, spell out what happens to the tickets carrying the old value:
remapped to the survivor, or explicitly retained read-only — never left pointing at a
deleted value. State the order — remap existing tickets first, retire the value second — so
nothing is orphaned. The remap is PSA-side work — the PSA is master of the taxonomy and
Thread mirrors the result; never clean up Thread-side values independently. Check
dependencies first: a value referenced by a Flow condition, a saved View, an agreement
mapping or a standing report breaks silently if it changes.
6. Output a plain-text cleanup plan: the census table (value, count, classification), the
target taxonomy, the merge and retire list with counts and rationale, the migration order,
and a review-before-enacting list of every dependency touched. End with what a human must
do in the PSA and in what sequence.
Keep the target taxonomy minimal and non-overlapping, and give each survivor a one-line
definition so the sprawl doesn't regrow. Anything destined for a PSA note is plain text — no
markdown or emojis (apply the PSA Note Discipline skill).
Magic Library