Mandatory Fields

☑️ Mandatory fields

Decide which ticket fields must be filled in before a ticket is closed, and what happens when somebody closes one with any of them empty.

A resolution code nobody picked or a category left blank makes the monthly report wrong without anyone noticing. This setting stops that happening quietly. You choose how strict it is, from a warning up to refusing the close.

Developers: see the Mandatory fields - Developer Guide.

---

⚙️ Setting it up

Tickets → Settings → Mandatory fields.

1. Tick the fields

Field	What "filled in" means
Priority	a priority is chosen
Type	a ticket type is chosen
Department	a department is chosen
Category	a category is chosen (see Ticket categories)
Category at close	the "what it turned out to be" category is chosen
Resolution code	a resolution code is chosen
Team	the ticket belongs to a team
Owner	somebody owns the ticket
Requester	the ticket has a requester
Origin	how the ticket came in is recorded
First time fix	Yes or No has been answered - No counts as filled in
IT training provided	Yes or No has been answered - No counts as filled in
Scheduled work	the ticket has a work start time

Nothing is ticked on a new install, so nothing changes until you choose.

2. Choose what happens

Option	What the analyst sees	Does the ticket close?
Warn	a list of the empty fields, and Close anyway	yes, if they choose to
Warn, and email someone	the same	yes, and the addresses you enter get an email naming the ticket, the empty fields and who closed it
Refuse the close	a list of the fields to fill in first	no, not until every ticked field is filled in

The email option suits a service delivery manager who wants to know when tickets are being closed without the details. Enter one address or several, separated by commas, up to ten. The email goes out from the ticket's own mailbox. A ticket that never had one, such as one raised by hand, uses your first active mailbox. Every email is listed as Closure alert in that mailbox's activity log, failures included: Tickets → Settings → Mailboxes, the mailbox's Activity button, then the Outbound tab.

3. Record it on the ticket

Record it on the ticket writes an internal note when a ticket closes with fields empty, naming the fields, who closed it and how (the ticket screen, the API or a workflow). It is on by default.

It only applies to the two warning options. Under Refuse the close the ticket never closes, so there is nothing to record, and the switch is greyed out.

---

🎫 What analysts see

Close a ticket with a ticked field empty, whichever way you do it: the status dropdown, the right-click menu, dragging it onto a closed status, or a bulk action on a selection.

• Warn - Close with fields empty? lists the fields. Close anyway closes the ticket; Cancel leaves it as it was so you can fill them in.
• Refuse the close - Fill these in first lists the fields, and nothing changes.

Closing several tickets at once lists each ticket with its empty fields. If only some of them are refused, Close the rest closes the others, and the result tells you which ones stayed open.

---

📐 The rules it follows

• Everywhere a ticket can be closed. The ticket screen, bulk actions, the REST API and workflows all follow the same rule. A bulk close lists any tickets it could not close and says why. A workflow that tries to close a ticket under Refuse the close fails with the reason in its run history.
• A field filled in during the close counts. An API call, or a bulk edit, that sets the resolution code and closes the ticket at the same time is fine.
• A field a ticket cannot show is never required. Category, category at close and resolution code can each be switched off per company. Where one is off, it is skipped for that company's tickets. The Team field is skipped on an install that has no teams. Nobody is asked to fill in something they cannot see.
• Merging tickets never triggers it. Merging closes the tickets merged away, and there is no point stopping a merge because a ticket about to disappear has no category.
• Reopening a ticket is never affected, and neither is editing a ticket that is already closed.
• Portal users cannot close tickets, so the rule never reaches the self-service portal.

---

❓ What it will not do

• It does not check fields when a ticket is created. Tickets arrive by email, the portal, chat and the API, and most of those cannot ask for anything. The rule applies when a ticket is closed.
• It is one setting for the whole install for now. It is stored the same way as the other per-company ticket settings, so a column for each company can be added later without redoing it.
• It does not replace Checklists & SOPs. Mandatory checklist steps are a separate rule with their own setting on the Checklists tab. A ticket can be checked by both.