Skip to content

Forms on Tickets

Ed Mozley edited this page Nov 11, 2026 · 3 revisions

Forms on tickets

A ticket can carry forms from the Forms module. You fill them in on the ticket, the answers stay with it, and the ticket can wait for them before it closes.

Asked for in #272, 5.0.0. It is the ticket twin of Forms on tasks, and works the same way.


What it is for

  • A new starter request needs its equipment form: device, start date, software.
  • A security incident needs its incident report before anyone may close it.
  • A change of address needs the confirmation form filled in by whoever handles it.

Before this, the form lived in the Forms module and somebody pasted a submission number into a note. Now the form is on the ticket.


Switching it on

Tickets β†’ Settings β†’ Checklists β†’ Forms on tickets. It is off by default, and the Forms module must be switched on too. Switching it off hides the Forms button and stops checking required forms. Nothing is deleted.


Using it

A Forms button appears on each ticket's toolbar. Once forms are added it shows a count, such as Forms Β· 1/2 (one of two submitted).

  • In a workspace the same forms also appear on the Work tab, beside the checklists and tasks, once the ticket has at least one.
  • Right-click a ticket, or a selection, and choose Add form β–Έ to add one without opening it. Forms already on the ticket are ticked. On a selection, a ticket that already has the form is skipped and counted.
In the panel What it does
Add Adds a form. It is always the form's newest version. A form can be on a ticket only once.
Fill Opens the form in a window, on the same fill page tasks use.
Save draft Keeps half-finished answers that anyone on the ticket can carry on with. If two people save at once, the second is told who saved first and shown their answers. Nothing is overwritten.
Correct Changes a submission. The new answers replace the old ones on the ticket, and the old submission stays in Forms, marked as replaced.
Answers Shows the submitted answers to people allowed to read them (see below).
Requirement Required - blocks closing, Required - warns on closing or Optional.
Remove Takes the form off the ticket. Submissions already made stay in Forms.

Closing a ticket

  • A form set to blocks must be submitted before the ticket can reach a closed status. Closing is refused and the form is named. This applies everywhere a ticket can close: the inbox, bulk actions, workflows and the REST API.
  • A form set to warns asks first. Closing anyway is recorded, in the same way as closing with checklist steps outstanding.
  • Checklists β†’ Block every ticket with outstanding steps also makes every required form block.

Who can do what

Needs
Add, remove, change the requirement Write access to Tickets
Fill in or correct Write access to Forms
Read the answers Access to Forms, or the role permission Read the form answers on tickets you can see

Anyone else who can see the ticket sees who submitted a form and when, but not the answers. Ticket access on its own never shows form answers, which is the same rule as on tasks.


Where the answers show up

  • On the ticket, under Forms β†’ Answers.
  • In the ticket history: Form added, Form submitted, Form resubmitted, Form removed.
  • In the case report (Tickets β†’ the ticket β†’ Case report), beside the checklists. Answers appear only when the person producing the report may read them.
  • In Forms, as ordinary submissions. A submission a ticket relies on cannot be deleted there.
  • In the REST API: GET /tickets/{id}/forms and POST /tickets/{id}/forms/{ticket_form_id}/submissions. See REST API - Tickets.

Merging moves the forms to the surviving ticket, once each (the survivor's own copy wins). The trash keeps them, and deleting for good removes the requirement but keeps the submissions in Forms.


Related

FreeITSM

Getting Started

Modules

Multi-tenancy (planned)

Responses to feedback

Blue sky thinking

Bugs resolved

Pull requests

Links

Clone this wiki locally