Build a ticket form
Build a consistent ticket form for your team, customer portal, website and chat widget.
On this page
Overview
Ticket Form Builder at #/settings/system/ticket-form is the single schema for every intake surface: Admin Create Ticket, Customer Portal, Public Form, and Chat widget Add New Ticket. There are not four forms. Each field has type, label, required, help, width, default, validation, surfaces, visibility, conditions, and optional sensitive flag. Historical values stay on existing tickets after you edit the schema.
When to use this
One schema stops “the portal asked for a serial number but chat did not.” Surface checkboxes hide a field where it does not belong (for example chat_transcript only on the widget) without forking the form.
Where to find the controls
Settings → System → Ticket Form, or Settings overview → Open Form Builder. ? Help on the builder opens this article. Public shortcode [elegant_support_form] uses the same schema (public_form surface).
Who can make these changes
elegant_support_manage_settings to edit the schema. Agents only fill the rendered form. Public visitors hit the public REST with honeypot, rate limit, and nonce.
Before you begin
Add a type from the palette, set surfaces, required, and conditions, preview admin / portal / chat_widget / public_form at phone or desktop, then save (PATCH ticket-form). Reset restores the shipped schema. Core-like types (chat_transcript, and constraints on button) have limited deletion.
Follow these steps
- Open the builder.
- Add fields.
- Drag order.
- For each field pick surfaces (admin, portal, chat_widget, public_form).
- Add options for select / multi-select.
- Add conditions (show when another field equals a value).
- Mark required only on surfaces that must block submit.
- Preview each surface.
- Save.
- Submit a test ticket on every surface you enabled.
Settings reference
Types: text, textarea, select, multi-select, checkbox, button (submit alignment), email, number, date, file/attachment, heading, help text, divider, hidden, chat_transcript (chat_widget only, often core). Also: sections via heading/divider grouping, conditional logic, surface visibility, required, labels, placeholder, help_text, default_value, rows, min/max, width, visibility (for example customer), sensitive, historical values on the ticket.
Example workflow
You add a select Product visible on all four surfaces and a textarea Serial required only on portal and public_form. Chat stays short; the portal still collects the serial. Attachments use the file type with Tickets upload limits.
Good practices
Keep chat_widget fields few; use the Document tab for KB and Add New Ticket for structured intake. Hidden fields can carry campaign ids on the public form.
Important considerations
Changing a field key does not migrate old stored keys. Deleting a field hides it on new submits but historical values remain. Do not put secrets in help text on public_form.
If something does not work
Field missing on one surface: surfaces[] does not include it, or a condition failed. Attachment rejected: Tickets file rules, not Form Builder type alone. Chat tab empty: live_chat feature off or schema has no chat_widget fields besides transcript. Reset confirmation is destructive to unpublished edits.