Request types and forms

A request type is a kind of request the portal offers, with its own form and its own destination. The three most portals start with are Bug report, Feature request and Question.

Create one

1. Open the portal and go to Request types.
2. Select New request type.
3. Fill in:
   • Name — what the customer chooses. A noun phrase: “Bug report”, not “Report a bug”.
   • Description — one line under the name, saying when to choose it.
   • Form — the fields the customer fills in.
   • Destination — where the issue goes. See Destinations.
   • Status map — how the issue’s state becomes a word the customer reads. See Statuses.
4. Select Create request type.

The form

Every request has a Title. It is built in, always required, and cannot be removed or reordered. Everything else is a field you add with Add field.

Field type	Becomes
Short text	One line in the issue body under its own heading
Long text	A paragraph in the issue body under its own heading, written in Markdown
Single select	The chosen option, under its own heading
Checkbox	Yes or No, under its own heading
Email	The address, under its own heading
URL	The address, under its own heading. http and https only
Number	The number, under its own heading
Date	The date in YYYY-MM-DD, under its own heading

Each field has a Label, optional Help text, and a Required switch. A required field is marked with the word “Required” beside the label, not with an asterisk.

Attachments are not a field type. Every request form takes files; see Attachments.

What the issue looks like

The issue title is the request’s title. The body is one ## heading per field with the answer under it, and an attribution line naming the requester and their company — never their email address.

There is no way to make the issue body something else. An engineer reading it in GitHub sees exactly what the customer typed, under headings they can scan.

Ordering and retiring

Use the arrows beside a request type to change the order customers see. Deleting one takes it off the portal’s chooser for everybody; requests already submitted through it stay, and keep their status rules, because a status word that changed when a form was retired would be a change nobody made.

Changing a request type later

Changing the form changes what the next customer fills in. It does not rewrite any issue already created, and it does not ask existing requesters for the new field.