What a ticket field is and which standard fields exist

Ticket fields are what your rules and reports read. The standard set covers more than people expect before they start adding.

Ticket fields are what your rules and reports read. The standard set covers more than people expect before they 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.

Type and Priority are off by default on newer accounts. That is deliberate: many teams do not need them, and a field nobody fills in accurately is worse than no field.

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

• Creating a custom ticket field
• The field types and when to pick which
• Why my ticket field does not appear on the form
• Can I use a custom field that is not on the form