What a ticket field is and which standard fields exist

Plan requirement

Subscription Any plan
Access Agent

Ticket fields are what your rules and reports read. The standard set covers a great deal before you start adding.

The standard fields

  • Requester and Assignee. Who it is for and who is on it.
  • Subject and Description. The first message.
  • Status. Who has to act next.
  • Type. Question, incident, problem or task.
  • Priority. Low, normal, high or urgent.
  • Group. Which team owns it.
  • Tags. Free labels that rules can read.

Of that list, Type and Priority are the only two you can take off a form or deactivate. The rest are permanent. Many teams do want them gone, on the reasonable ground that a field nobody fills in accurately is worse than no field, but both have a consequence to weigh first.

  • Deactivate Type and every ticket defaults to Incident.
  • Deactivate Priority and your SLA targets stop applying. That one surprises people, because the two features look unrelated until the promises quietly stop being measured.

A ticket with the field panel on the left showing Assignee, Followers, Sharing, Tags, Type, Priority and a custom Product type field, beside the conversation with its Public reply and Internal note tabs.

The panel down the left is where the fields live. Everything above the divider is about who is involved, everything below it describes the ticket, and a custom field such as Product type sits among the standard ones without looking any different to the agent.

What a field is for

A field exists so that something can act on it. Three things read fields: your agents, your business rules, and your reports. If a field serves none of those, it is a question your agents answer for nobody.

That is the test worth applying before adding one. Not "would this be nice to know" but "what will change because we know it".

System fields and custom fields

System fields cannot be deleted, though some can be deactivated. Custom fields are yours: you create them, decide their type, and put them on forms.

Both appear in triggers, views and Explore in the same way, so a custom field is not a second-class citizen once it exists.

Fields and forms

A field existing does not put it in front of anyone. Forms decide which fields appear on which tickets, which is why a field can be perfectly configured and still invisible.

See also

Was this article helpful?

0

Still stuck?

Our support team will take a look with you.

Comments

0 comments

Article is closed for comments.