Plan requirement
| Subscription | Any plan |
| Access | Admin |
Deactivating a field is reversible and quiet. Deleting it is neither: the field cannot be recreated and its data cannot be recovered.
| Deactivate | Delete | |
| In the agent interface | Gone, on every ticket whatever its status | Gone, permanently |
| The data | Kept, and comes back on reactivation | Only in the ticket audits endpoint, nowhere else |
| Reversible | Yes | No. The field cannot be recreated or recovered |
Deactivating
The field disappears from the agent interface on every ticket, whatever its status, including closed and archived ones. What it does not do is destroy anything: the values stay, and reactivating the field brings them back exactly as they were.
This is almost always what you want.
Two system fields are the exception to "quiet". Type and Priority are the only system fields you can deactivate at all, and each takes something with it: without Type every ticket defaults to Incident, and without Priority your SLA targets stop applying. Neither announces itself.
Deleting
Deleting is permanent. The field cannot be recreated and its data cannot be recovered, and after that the ticket audits endpoint is the only place the values still exist. That endpoint records every change ever made to a ticket, so the history is technically still there, but it is reachable only through the API and not through any report or ticket view.
So it is worth being precise about what you are choosing: not a tidy-up, but moving a year of data somewhere only a developer can reach it.
Your business rules will tell you
This is the part worth correcting a common assumption about. A trigger, view or macro that keys on a tag which no longer exists returns an error. It does not quietly stop matching.
That is better news than it sounds: the breakage announces itself instead of showing up weeks later as tickets that never got routed. It does still mean a rule you had forgotten about can start failing the moment you delete a value.
Removing a drop-down value
The same decision one level down, and the behaviour splits by ticket status.
- On tickets that are not closed, the value is replaced with null. The ticket keeps existing; the answer is gone.
- On closed and archived tickets, a warning appears instead:
Missing field value
Changing the tag behind an option behaves differently again: existing tickets keep the original tag, but the option is deselected on them.
What to do instead
Deactivate first, wait a month, then decide. If nobody notices in a month you have your answer and you have lost nothing. If someone does notice, you have learnt what the field was for, which is usually cheaper than learning it from a report that changed shape.
Comments
0 comments
Article is closed for comments.