InfiniTeaInfiniTea Docs
How It WorksFor Server Staff

Form Builder

The Form Builder lets staff create structured multi-page forms that collect information from members during ticketing or onboarding flows. Forms support various field types, validation rules, and conditional logic to gather exactly the information your team needs.

How Forms Work

Forms are always attached to a parent feature (Onboarding Flows or Ticketing). When a member triggers the parent feature, the form is presented as a series of pages they fill out. Responses are stored and accessible to staff through the dashboard.

Form Structure

Each form consists of:

  • Pages: Logical groupings of related fields. Members navigate between pages sequentially.
  • Fields: Individual inputs like text fields, dropdowns, checkboxes, file uploads, or multi-select options.
  • Validation rules: Per-field constraints like required fields, minimum/maximum length, regex patterns, or allowed file types.
  • Conditional logic: Show or hide fields based on previous answers to create dynamic forms.

Staff Workflow

  1. Open the form from its owning feature (navigate to the Onboarding Flow or Ticket category that uses the form).
  2. Edit pages and fields: Add, remove, or reorder pages. Within each page, configure fields with labels, descriptions, placeholder text, and validation.
  3. Set validation rules: Mark fields as required, set character limits, or add pattern matching for structured data like emails or IDs.
  4. Save and test: After saving, submit a test response to verify the form behaves as expected from the member's perspective.

Versioning Rule

Form Builder uses automatic versioning to protect historical data:

  • If submissions already exist for the current version of a form, saving changes creates a new version automatically.
  • Historical submissions remain linked to the version they were submitted against, preserving data integrity.
  • This prevents schema drift from corrupting or misrepresenting older responses.
  • You can view which version each submission belongs to in the response viewer.

Deletion Rule

  • Forms that have received submissions cannot be deleted. This ensures audit trails and historical data remain intact.
  • To retire a form, disable the parent feature or replace it with a new form.

Best Practices

  • Keep forms concise. Members are more likely to complete shorter forms (3-5 fields per page, 1-3 pages total).
  • Use descriptive field labels and placeholder text to reduce confusion.
  • Test forms with multiple staff members before deploying to your community.
  • Use conditional logic to avoid showing irrelevant fields to members.