Skip to content

The ticket closed but the credential wasn't purged

If you closed a ticket but the linked credential is still there, work through these — most cases are a detection or verification setting.

Close detection is poll-based by default, so a purge can lag the ticket close by up to the poll interval (a few minutes). Wait briefly and refresh before digging further.

Your policy sets what counts as “closed” — resolved or closed (the default), closed only, or never purge on ticket status. If the ticket only reached a status that isn’t your trigger, or the trigger is set to never, nothing purges. Check the request’s ticket card for the last-seen status, and the status mapping for your vendor (custom statuses show as unknown until mapped).

3. Unverified webhook without “Trust unverified”

Section titled “3. Unverified webhook without “Trust unverified””

If the ticket is linked through the generic webhook or a platform automation — anything SafeHanded can’t read back — the status is unverified. By default it updates the card but doesn’t purge. Enable Trust unverified webhooks in Policy to allow close-to-purge on those (an availability trade-off, never a confidentiality one).

Adapters that can read the ticket back (e.g. Halo, ConnectWise) verify and purge without this setting.

If you set a grace period, a purge is delayed by that long so a quick reopen can cancel it. The credential purges after the grace window if the ticket stays closed.

5. The request wasn’t linked to that ticket

Section titled “5. The request wasn’t linked to that ticket”

Close-to-purge only acts on requests linked to the ticket (or quoting its reference). Confirm the request actually carries that ticket reference.

Check the integration’s own troubleshooting on its setup page, and the audit log for a ticket_status_changed event — its absence means the status change never reached SafeHanded (a detection issue), while its presence with no purge points at the trigger/verify settings above.