Skip to main content
Tickets keep an audit trail so you can answer “what changed, who changed it, and when?” without reading the whole thread.

​
Field and attribute history

Creating or updating a ticket writes property history when a tracked value actually changes. Tracked examples:
  • Title, description, summary
  • Type, source, priority
  • Customer, assignee, assigned team, owner, owner team
  • Linked origin conversation
  • Parent / merged / split relationships
  • First response, resolved, closed, snooze, activity timestamps
  • Shared flag
  • Custom attribute values (order ID, lists, and so on)
Unchanged values are skipped. Empty or false defaults are skipped on create so opening a ticket does not flood history with blanks. Custom attribute edits also log old value → new value per field, including when a conditional field is cleared.

​
Status history

Each status move stores:
  • Previous status and new status
  • Who moved it
  • Time in previous status, in seconds
Use this to see whether tickets stall in waiting-on-customer or on-hold. The first status (on create) is logged as entering the default in-progress status with no “from” status.

​
Disposition history

Disposition changes use from → to semantics, including clearing a code. Path snapshots keep the breadcrumb readable after codes are renamed. See Dispositions.

​
Conversation and group snapshots

Attaching or detaching conversations or tracker members writes a snapshot of the full set (conversation IDs or #ticket numbers), not only the one row you clicked. That makes it obvious what the ticket was linked to before and after.

​
Workspace audit log

Creating, updating, cloning, and archiving types and statuses also appear in workspace audit logs as ticket type or ticket status events. Applying a disposition on a ticket is a ticket update. It does not write a separate settings audit row.

​
How to read history on a ticket

Open the ticket and scroll to:
  • Attribute history — field and custom attribute diffs
  • Disposition log — code changes
  • Status changes — dwell time between states
Read history when a customer asks why the ticket sat for two days, or when QA checks that required-to-close fields were filled before resolve.