Create and publish a form
Open **Forms** and select **New form**. Start from scratch, use a template, or describe what you need with the AI Form Builder. Add and arrange your questions, then customise the form's design, confirmation message, and availability settings. Use **Preview** to test the complete experience. When it is ready, publish the form and copy its public link. You can also embed it on a website. New responses will appear automatically in the form's **Responses** area. ## Publish a form When you are ready to make a form available to the public, select **Publish**. Hub opens a **Review and apply** panel showing: - The form name and fields. - The submission destination. - The form's public address. Any pending edits you have made — including field changes and private submission settings — are saved atomically with publication. Review the summary carefully, then select **Publish** to confirm. The form goes live and its public link becomes active. To take a form offline, select **Unpublish**. Unpublishing preserves any unsaved edits and keeps existing responses intact. ## After submission: follow-up settings All post-submission options are grouped under **After submission** in the form settings. This includes: - **Thank-you content** — the message or destination shown after a successful submission. - **Destinations** — where respondents are sent after submitting. - **File delivery** — files sent to the respondent after submission. - **Immediate email reply** — an automated email sent directly to the submitter. ### Immediate email reply You can configure an immediate email reply that is sent to the respondent's submitted contact email as soon as the form is received. To set this up: 1. In **After submission**, enable **Immediate email reply**. 2. Write the reply content, or select a saved template. 3. Save the form. Saving a configured reply creates or updates a form-specific workflow using the `form_submitted` or `meeting_booked` trigger. The submitter's reply is resolved from the submitted contact email independently of portal sharing. **Delivery:** Reply links are prepared before the completion event. Delivery failures surface in workflow activity. Stable workflow and provider idempotency prevents duplicate replies if the same submission is replayed. Failed submissions revoke any prepared grants. **Separate file emails** continue to work. An explicit consolidation option is available if you want to combine the immediate reply and file delivery into a single email. A duplicate-email warning is shown if both would go to the same address. ## Service-specific request and booking actions Services on a site can now use different journeys for each service. In the form or service settings, you can choose: - **Sign-up link** — the existing destination behaviour. - **Request form** — a form that creates a service request record. - **Native booking form** — Hub's native booking experience. - **Stripe checkout** — an existing payment checkout. Cards and detail headers share the same resolver and editor, with collection defaults and per-record overrides. Existing destinations remain when no specific action is configured. ### Compatible forms and previews The form editor shows a compatibility indicator when a form is selected as a request form for a service. Published-form compatibility errors are shown if the form is not in a suitable state. Preview actions are disabled when valid context (a published site and service) is not available. ### Server-validated attribution Form submissions for service requests are validated against the published site configuration. Linked and embedded forms retain their existing behaviour when valid context is absent. ## Form submissions alongside orders Sites manage **Orders**, **Submissions** and **Bookings** together in a unified view with server-side filters and cursor pagination. Each accepted attributed response enters a private index. - Selected forms can create service orders automatically on submission. - Other submissions offer idempotent manual conversion to an order. - **Owner** comes from the current linked record; service progress is independent of Stripe payment and record status. ### Authenticated APIs Authenticated APIs expose safe detail projections including original answers, linked records/bookings, and completion-specific follow-up activity. Conversion, attachment and progress writes are audited on the linked record and reject deleted records. ### Historical indexing Historical indexing of older responses is paged, repeatable and creates no orders or emails. Older unattributed responses can be attached explicitly from the form's **Responses** view while retaining original attribution. ## Capture marketing consent Forms can capture an explicit marketing opt-in from respondents. When a checkbox question is mapped to **Marketing consent**, a checked visible answer is saved atomically to the respondent's workspace CRM contact record with a timestamp, the form source and the response ID. ### Set up a marketing consent checkbox 1. Add a **Checkbox** question to the form. 2. In the question inspector, find **Save submission to** under **Destination**. 3. Choose **Marketing consent** from the destination list. 4. Save and publish the form. **How it works:** - A checked, visible consent checkbox writes the opt-in to the respondent's CRM contact record. - An unchecked or hidden checkbox does not change an existing consent choice. Respondents who leave it unchecked are not opted out if they had already consented elsewhere. - Only checkbox questions can be mapped to Marketing consent. - If no matching CRM contact exists, Hub creates one atomically with the response. - Newsletter-purpose forms without a separate checkbox retain their existing subscription behaviour. > **Important:** This checkbox gives respondents an explicit, informed choice. Use clear label text such as "I agree to receive marketing emails". Do not pre-check the box. ## File attachment questions You can add a **File** question type to collect documents, images or other files from respondents. ### Size limits Forms use inline file storage, which means uploaded files are embedded directly in the form response rather than stored as separate files. This keeps delivery fast but applies a firm size cap: - **Maximum file size: 250 KB per file.** - **Maximum total response size: 350 KB** across all answers in a single submission (including text, selections and files). If a respondent selects a file that is too large, a clear error message appears beside the upload field and they can choose a different file. Their other answers are kept so they do not need to retype them. If the combined response exceeds the total limit, the form prompts them to remove an attachment or shorten their answers before submitting. > Larger file uploads are not currently supported through forms. If your workflow requires files above 250 KB, consider asking respondents to share a link to the file instead. ### Upload feedback While a file is being read by the browser, the field shows the file name. Once reading is complete, the field confirms the file is ready. Respondents can select **Remove file** at any time to clear the selection and choose again. If a file cannot be read, an error message explains what happened and invites them to try again. ## PDF delivery uploads Forms can include a PDF delivery step that sends a personalised document to the respondent. PDF uploads used in form delivery are accepted through the workspace asset library path. Files up to 25 MiB are accepted; the file picker shows only PDF and other approved MIME types.