What custom fields are for
The built-in form asks what kind of feedback this is, how severe it is, a summary, and a description. Custom fields let you ask the two or three extra questions that turn a vague report into an actionable one.
Common examples: "Which area of the app?" as a dropdown, "How often does this happen?" as a select, "Order number" as text, "This is blocking me" as a checkbox.
Field types
Seven types are available. Each is validated on the server against the definition you saved, so a caller cannot submit a value your form never offered.
- text — a single line
- textarea — multiple lines, up to 2,000 characters
- select — a dropdown; only the options you define are accepted
- checkbox — a yes/no toggle
- email — validated as an email address
- url — validated as an http(s) URL
- number — validated as numeric
Keys and labels
Every field has a key and a label. The key is the stable identifier stored on the report — lowercase letters, digits, and underscores. The label is what the visitor reads, and what appears in the GitHub or Jira issue.
Changing a label is safe and takes effect immediately. Changing a key means new reports use the new key while old reports keep the old one, so pick keys you can live with.
Required fields
Marking a field required enforces it in two places: the browser will not submit without it, and the server rejects the submission if it is missing. Be sparing — every required field is a reason someone abandons the form.