Form fields
Add, remove, reorder, and validate fields on your public support form.
Form fields define what customers submit when they open your support page. SupportPage ships with sensible defaults; you can customize fields to match your intake process.
Open Support page → Settings → Form fields in the dashboard.
Default fields
New pages typically include:
| Field | Type | Notes |
|---|---|---|
| First Name | Text | Customer first name |
| Last Name | Text | Customer last name |
| Required for replies and status links | ||
| Subject | Text | Short summary |
| Message | Textarea | Main description |
Keep email on the form unless you have a documented process that does not need customer follow-up.
Field types
To add new additional fields to your form, use the Add field button. Here are the available types of fields that you have access to with some ideas on you can use them:
| Type | Use case |
|---|---|
| Short text | Order ID, account name |
| Long text / textarea | Detailed explanation |
| Contact address (validate format) | |
| Dropdown | Category, product area, severity |
| Checkbox | Opt-in, acknowledgment |
| Radio | Single choice among few options |
Add a field with Add field, choose the type, set a label, and configure options for choice-based types.
Required vs optional
Toggle Required per field. Required fields block submission until filled.
Best practices:
- Require only what you need to respond — long required forms reduce completion
- Use dropdowns for routing (Billing vs Technical) instead of free-text when possible
- Mark internal reference fields optional if customers may not know them
Ordering
Drag fields to reorder. Put the most important questions first — email and subject near the top helps triage in the inbox.
Labels, placeholders, and help text
| Property | Purpose |
|---|---|
| Label | Visible field name |
| Placeholder | Hint inside empty inputs — do not replace the label |
| Help text | Short guidance below the field (for example, "Found in Settings → Account") |
Clear help text reduces back-and-forth in ticket detail.
Validation
Built-in validation includes:
- Email format for email fields
- Required field enforcement
- Max length on text fields where configured
Invalid submissions show inline errors on the public form — customers fix and resubmit without losing other entries.
Sensitive data
Avoid collecting passwords, full payment card numbers, or government IDs on a public form. Use secure channels for credentials and PCI-sensitive data.
If you need account identifiers, ask for non-secret IDs (last four digits, public username).
How fields appear in the inbox
Each answer maps to a labeled row in ticket detail. Custom fields are not buried in the message body unless the customer repeats them there.
Testing changes
After editing fields:
- Save changes.
- Open the public form in a private window.
- Submit a test request.
- Confirm all answers appear correctly in the inbox.
Unpublished pages can still accept test submissions from logged-in operators depending on configuration — check Publishing.
Related topics
- Onboarding — Fields step
- Spam protection — unrelated to field schema but affects submission success
- Submitting a request — customer view