Building a form with the guide

New form → Guided builds a form step by step, with the form beside the steps as the requester will see it and what one request would make from it. It can also write the automation that goes with the form, when the form should do more than open a case: route it to a team, tell someone, or declare an incident or record a change from it. Nothing is saved until Create the form; then the form opens in its editor, the one place to change it afterwards. Blank is the quick way: a name and a unit, then the editor.

The steps

Step	What you decide
What it creates	A case, or a case and an incident, a change, or a standard change from an approved template (with Incident or Change Management on). And the form's name.
Where	The unit the cases go to; the portal and menu section it is shown in, or none (the hosted page, an embed on a website, or posted from a server); and who can use it.
Questions	Suggested questions for what it creates, to add to, remove, reorder and change.
What it fills in	The case's priority and team, and, for an incident or a change, which field of it each answer goes into and fixed values for the rest.
After sending	The thank-you text, who is told, and labels on every case.
Review	The checks, the automation's name, and whether the form is Live or Paused when it is created.

The preview shows the form in the unit's branding, and below it the case and the record from sample answers. The steps you've done can be picked on the step bar to go back.

A case always comes first

A form always opens a case: the requester follows it by email and on the portal, and replies there. A form that declares an incident or records a change does it through an automation that runs when the form is submitted, using Create a record. The incident or change is linked to the case; staff work on it, and the requester never sees it.

Creates	What the automation makes	Suggested questions
A case	Nothing more, unless the case goes to a team or someone is told.	How can we help?
A case and an incident	An incident, linked to the case. Without a commander it starts as New.	What is affected, since when, how many people, anything else.
A case and a change	A normal change as a draft, for someone to complete and send for approval. A service is needed.	What, why, when, what if it goes wrong.
A case and a standard change	A change from an approved template, pre-approved, planned from when the form is sent.	What, when, anything else.

What the answers fill in

Each question can go into a text field of the incident or change, like its title or summary, or be kept on the case. Several answers in one long text field each get a line with their question, and a link to the case. Fields that aren't text, like impact, urgency, the service or the template, get a fixed value here. Every answer stays on the case whichever you pick: the questions never become fields of incidents or changes.

The automation is a normal rule under Platform → Automations, named after the form, which runs when a form is submitted on this form only. You can change it there later, like any other rule.

Who can use it

Who can use it	Means
Anyone	Anyone who finds the form, within the unit's own rules for who may submit.
Signed-in portal users	Contacts signed in on a portal. On a portal, visitors are asked to sign in first; on the hosted page, a contact who isn't signed in is refused. A server-mode request counts as signed in, because your backend vouches for its users.
Staff	People of the desk who can see the form's unit, signed in on the desk, on the hosted page. A staff form can't be on a portal.

A form that declares incidents starts as Signed-in portal users: a form open to anyone is easy to flood. The form's hourly cap applies either way. You can change who can use a form later on the Build tab of its editor.

What is checked

The Review step lists what Create the form checks, and the same is checked again when you create it:

• You may make forms in the unit (Form settings).
• For an automation, you may write automations in the organization (Manage automations).
• For an incident or a change, its plugin is on, and you may create it in the form's unit yourself: Work on incidents (incident.write), Work on changes (change.write), and for a standard change also Standard change templates (change.template). The automation then creates it as System, as rules do.
• The automation is valid: the team, the person and the values exist in the organization, and every needed field of the record is filled in.
• On a portal: you manage it (Portal settings), it may send cases to the unit, and it is on. A portal that is off is a warning: nobody sees the form there until it is turned on.

If a check fails, nothing is created. Paused creates the form turned off: it takes no requests until you turn it on in the editor.