Forms and Responses

Forms collect structured customer information before, during, or after work. Operators use them for contact requests, intake, quote requests, support escalation, file collection, and follow-up handoffs.

The console is the source of truth for form definitions, templates, publishing, responses, routing, and customer record linkage. The sites app renders published forms at /{site}/forms/{formSlug}.

Surface Map

Build A Form

Start with the purpose of the form, then build only the fields needed to act on the submission.

Configure:

• Name and slug.
• Public or intake purpose.
• One or more pages when the form needs sections.
• Fields, labels, help text, and placeholders.
• Required fields and validation.
• Select, multi-select, radio, and checkbox options.
• File upload fields when the team must receive documents or images.
• Submit button text and success message.
• Notification recipients.
• Whether the form should create or link a customer record.
• Whether the form should create a ticket.
• Whether authentication or multiple submissions should be allowed.

Supported field types include short text, long text, email, phone, URL, number, dropdown, multi-select, radio buttons, checkboxes, date, time, date and time, file upload, rating, and signature.

Keep field names stable once a form is receiving real submissions. Changing display copy is usually safe; changing field meaning after launch makes old responses harder to interpret and exports harder to compare.

Templates

Templates are accelerators, not final policy.

Use a template when:

• The team is setting up a common workflow.
• The operator wants a complete starting point.
• The form needs a conventional field order.
• A launch path needs to be created quickly and reviewed later.

After choosing a template:

1. Review every field.
2. Remove questions the team will not use.
3. Add required fields only when they are truly needed.
4. Confirm the success message matches the next step.
5. Confirm notifications and routing before publishing.
6. Open the live form and submit a test response.

Do not publish an untouched template for a real workspace. A template should become workspace-specific before customers see it.

Publish And Link

Draft forms are editable but should not be treated as customer-ready. Published forms are available at:

/{site}/forms/{formSlug}

Before sharing a form:

• Confirm the slug is final.
• Open the public route.
• Submit a complete test response.
• Submit an incomplete test response to check required fields.
• Upload a test file if the form accepts files.
• Confirm the success state is clear.
• Confirm the submission appears in the intended console surface.

Unpublish a form when it should no longer accept responses. Prefer unpublishing over deleting when historical submissions still matter.

Submissions And Responses

Responses are the per-form operating view for submissions. The all-forms response stream is handled through Inbox; old /responses navigation lands there. Per-form responses remain available at:

/responses/{formId}

Older links to /forms/{formId}/submissions also land on the per-form responses view.

Operators can use Responses to:

• Search submissions.
• Filter by status.
• Review submitter, date, and preview fields.
• Open the full detail sheet.
• Mark a submission as pending, processed, failed, or spam.
• Export submissions as CSV.
• Download files from file upload fields.

Use status as an operational triage marker. Pending means the item still needs review, processed means the team handled it, failed means the submission needs investigation, and spam means the item should be suppressed from normal work.

CSV Export

Use Export CSV for reporting, handoff, cleanup, or offline review of a single form’s submissions.

Export rules:

• The export belongs to one form.
• The current status filter can narrow the export.
• Field values are exported as customer data.
• File uploads are represented as submission metadata, not as bundled file contents.
• CSVs should be stored and shared with the same care as customer records.

Do not use CSV as the source of truth after export. If a status, customer link, or submission detail changes later, reopen the console before acting.

Signed File Downloads

File upload answers are reviewed from the submission detail sheet. When a file is available, the console shows a download link backed by a signed URL.

Operator rules:

1. Confirm the workspace and customer before opening a file.
2. Download only from the submission detail view.
3. Do not paste signed URLs into tickets, notes, or external messages.
4. If a link expires, reopen the submission detail instead of reusing the old URL.
5. Store downloaded files according to the workspace’s privacy and retention policy.

Signed URLs are access paths, not durable records. The durable record is the form submission and its file attachment metadata in the console.

Inbox Routing

Inbox is the cross-workflow triage surface. It helps operators answer:

• What came in?
• Which customer is involved?
• Which form, booking, order, or ticket is related?
• Who should handle the item?
• Has the team already acted?

For launch-critical forms, test that a new submission appears in Inbox or in the documented team workflow. If a submission is missing, check the form’s publish state, public route, required fields, submission success state, notification settings, and whether the operator is viewing the correct workspace.

Customer Records

Forms should attach useful context to the customer record whenever identity can be matched or intentionally created.

Customer record linkage can depend on:

• Email address.
• Portal session.
• Existing customer identity.
• Form settings.
• Booking, order, or intake context.
• Operator cleanup after submission.

Use the customer detail page before replying. A form submission can be part of a larger history that includes bookings, orders, tickets, consent, payments, notifications, and internal notes.

Duplicate customer records usually mean the identifying data changed, a guest flow was not claimed, or the form was not configured to create or link customers the way the team expected.

Launch Checks

• Form has a clear owner and purpose.
• Template fields were reviewed and customized.
• Required fields block incomplete submissions.
• Public route renders at /{site}/forms/{formSlug}.
• Submission appears in Inbox or the per-form Responses view.
• Customer record links when expected.
• CSV export works for the form.
• File upload downloads work from the detail sheet.
• Notifications go to a monitored address.
• The team knows when to mark a response processed, failed, or spam.