Closing the loop in the ticketing system
Two systems hold the work — Huntress and the PSA. Closing one and not the other is the cardinal drift trap. Six small close-out steps, takes two minutes, prevents the most common helpdesk pattern in the EDR arc.
Two systems hold the work: Huntress (where the security action happens) and the PSA (where the time, the billing, and the customer-facing record live). Closing one without the other is the most common drift pattern in helpdesk EDR work. It looks like nothing — the agent is fine, the threat is handled — but the PSA-side gap creates invoicing problems, missed time entries, and the eventual realisation that nobody knows what was done to a customer’s environment because the only record was in Huntress and the auditor can only see the PSA.
The two-system reality
Huntress and the PSA are linked in most MSPs but not always tightly. Common configurations:
- Integration creates a PSA ticket automatically when a Huntress incident opens. Common. The integration handles the open; the human keeps the two in sync afterwards.
- No automatic integration; manual PSA ticket created by the tech. Less common. The tech opens both, links them with a reference number, and closes both.
- PSA ticket exists for a separate customer request that intersects the Huntress incident. A user called about a slow machine, a PSA ticket opened, then a Huntress incident landed for the same machine. Two tickets, one underlying problem.
Whichever configuration is in place, the discipline is the same: every Huntress incident closure pairs with a PSA close-out (with time entry and category), and any mid-flight drift gets reconciled before close.
The close-out checklist
Close the Huntress incident
Set the resolution disposition (per the runbook, usually “remediated,” “no action required,” or similar).
Match the PSA ticket
Find the corresponding ticket. If your MSP’s integration auto-created one, it should be linked from the Huntress incident. If not, search by host, customer, and time.
Add the incident note to the PSA
The note belongs in both systems. PSA closure without the note is a closure that doesn’t explain itself; auditors don’t always have access to Huntress.
Enter time
Per your MSP’s policy: a billing-relevant category, the actual time spent, a brief description.
Set category and resolution code
Categories matter for reporting; sloppy categories mean sloppy customer reports.
Close the PSA ticket
Done. Six small steps, takes two minutes, prevents the most common drift trap in the arc.
When the PSA has drifted
Drift looks like:
- Huntress closed; PSA open. Tech closed Huntress, forgot the PSA. Close the PSA now with the note and time.
- PSA closed; Huntress open. PSA was closed for an unrelated reason. Confirm the Huntress incident is actually ready to close before closing it.
- Two PSA tickets for the same Huntress incident. Manual-plus-integration collision. Merge or close the duplicate.
- Huntress and PSA closed with different dispositions. Reconcile so both match.
Common close-out failures
- Closing Huntress and walking away. The cardinal trap. The Huntress side feels like the “real work”; the PSA close feels like paperwork. Both are required.
- Entering generic time and category to “save time.” Five seconds saved at close becomes ten minutes of explanation at month-end when the report makes no sense.
- Skipping the note copy to the PSA. The PSA is usually the canonical record an auditor sees.
When to escalate
- The PSA ticket for the incident doesn’t exist and no integration is in place to auto-create one. Could be a one-off integration failure; could be a customer with different PSA mapping. Bump rather than create-from-scratch on customers you don’t know the conventions for.
- The time-entry category needed isn’t in the PSA’s available list. Could be the PSA was restructured and the runbook is out of date. Bump.
- Drift you can’t reconcile (two PSAs for one incident with conflicting time entries, or a Huntress incident with no findable PSA match). Senior helps untangle and update the runbook.