> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dforms/builder.md). # Building Forms A tour of the dForms editor: the topbar with the form name, save status, Build / Logic / Design / Connect tabs, Preview, share buttons and Publish; the question list and its screens; the live canvas a The editor is where a form takes shape. Everything you see on the canvas is exactly what respondents will see, and every change is saved as a draft automatically until you decide to **Publish**. This page names each part of the screen so the rest of the section can refer to them.
The form editor with the question list on the left, the live canvas in the centre and the Question settings pane on the right

Left: the question list. Centre: the live canvas. Right: settings for the selected question.

*** ## The topbar
The editor topbar: the back arrow and form name with the Unpublished changes chip, the Build, Logic, Design and Connect tabs, the Saved status, Preview, the share buttons and Publish with its menu

From left to right: name and publish status, the four tabs, save status, Preview, share buttons and Publish.

| Element | What it does | | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Back arrow | Returns to the **Forms** list; your work is already saved. | | Form name | Click it to rename the form inline. The placeholder reads **Untitled form**. Renaming the form does not change its public link. | | **Unpublished changes** | An amber chip next to the name whenever the draft differs from the live version. | | **Build** | The default tab: questions, canvas and settings. | | **Logic** | The logic canvas plus the **Branching**, **Scoring** and **Outcomes** dialogs. See [Logic, Scoring & Outcomes](/dforms/logic.md). | | **Design** | Language and button text, theme, colors, typography, logos, cover screen and ending, next to a large live preview. See [Design & Branding](/dforms/design.md). | | **Connect** | Integrations, tracking & pixels, submission emails and spam protection. See [Connect & Integrations](/dforms/connect.md). | | Save status | **Draft** (no questions yet), **Saving…**, **Saved**, **Retrying…**, **Not saved** or **Saved elsewhere**. See [Autosave](#autosave-and-draft-recovery) below. | | **Preview** | Opens the full preview with real device frames. See [Preview on desktop, tablet and mobile](/dforms/builder/preview.md). | | **Copy link** · **Edit link** · **Embed** · **QR code** · **Open form** | The share cluster: copy the public URL, change the last part of the link, get the embed snippet, get a QR code of the link, open the live form in a new tab. See [Publish, Share & Embed](/dforms/share.md). | | **Publish** | Makes the current draft live. Disabled when there is nothing new. The arrow next to it opens a menu with **Revert to the previous published version**; see [Autosave & publishing](/dforms/builder/autosave-and-publishing.md#revert-to-the-previous-version). | **Edit link** (the pencil) opens **Edit this form’s link**. Type the new last part of the address (lowercase letters, numbers and hyphens, up to 80 characters) and click **Save link**. The change applies at once, without **Publish**, and links you already shared keep working: they send visitors to the new address. If another form in the workspace already uses that link, the dialog says so. **QR code** opens **QR code for this form**, with the dForms logo in the middle, **Download PNG** and **Download SVG**. The code opens the same link as **Copy link** and keeps working after you edit the link. See [Share with a QR code](/dforms/share/qr-code.md). *** ## Around the canvas There is no second toolbar. The controls you use most sit next to the canvas:
The Build tab with the Desktop and Mobile switch above the canvas and the Add question button under the question card

The Desktop / Mobile switch sits above the canvas and Add question under the card.

| Control | What it does | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Add question** | Under the question card (and at the end of the question list). Opens the **Add a question** gallery. See [Question types](/dforms/builder/question-types.md). | | **Desktop / Mobile** | Above the canvas. Resizes it so you can edit at phone width without leaving the editor. | On **Logic**, **Branching**, **Scoring** and **Outcomes** float as buttons over the logic canvas. *** ## The question list (left) The **Questions** column lists every step in order with its number, a type icon and badges such as **Contact**, **{n} rules** (or **1 rule**) and **Hidden**. Click a card to select it; drag the handle to reorder. Below the cards you will find: * A dashed **Add question** card: the same gallery as the button under the canvas. * **Partial submit point**: a dashed, draggable marker. Drop it after a question to save answers as a partial submission from that point on. See [Partial submissions](/dforms/builder/partial-submissions.md). * A nudge card when the form asks for an email but has no marker yet: **Capture after the email question** places the marker for you. On a **Slides** form, a small chain icon on the top edge of a card joins that question to the screen of the question above (**Show on the same screen as the question above**), or splits a screen at that point (**Start a new screen here**). The icon appears when you hover or focus the card, and stays visible while two cards are joined. Joined cards form one block with a label such as **Screen 2 · 3 questions**; question numbers stay the same. See [Several questions on one screen](/dforms/builder/screens.md). On narrower windows (below 1024 px wide) the list is hidden, and a strip of question buttons under the canvas lets you select and add questions. To group questions there, use the screen switch in **Question settings**. ## The canvas (centre) The canvas shows **Question {n} of {total} · editing live**. Click any text to edit it in place: the title (**Type your question…**), the description (**Add a description (optional)**) and the option labels. Type `@` or `[` in a title to insert an earlier answer ([Recall answers with @](/dforms/builder/recall-answers.md)). Some types render a live control: a country picker on Phone, a slider on Slider, a calendar embed on Scheduler. The button under the question shows what respondents will read (**Next** or **Submit**, or your own words from **Design → Button text**). It is not editable on the canvas; see [Language & button text](/dforms/design/language-and-button-text.md). When the selected question shares a screen with other questions, the canvas shows the whole screen as one card, the way respondents see it. Every question on it stays editable, and the one selected in the list is highlighted. ## The settings pane (right) **Question settings** holds everything that is not text: the **Question type** select, **Required**, type-specific sections (**Options**, **Name fields**, **Answer length**, **Scheduler**, and so on), **Logic** with **Edit logic**, the **Show on the same screen as the question above** switch (Slides only), **Advanced settings** (field key, default answer, hidden question, ends the form, prefill URL) and the **HubSpot** mapping block. See [Question settings](/dforms/builder/question-settings.md). *** ## The app menu while you edit While you edit, the app menu on the far left stays folded to icons so the canvas keeps its width. Hover it, or move the keyboard focus into it, and it opens over the canvas to show its labels; move away and it folds again. The arrow at its top (**Expand sidebar**) opens it too. Opening it here never changes whether the menu stays open on the other pages. *** ## Autosave and draft recovery You never click Save. Roughly a second after you stop typing, the editor writes the draft and the status pill cycles **Saving…** → **Saved**. * If a save does not reach the server, the pill shows **Retrying…** and an error message explains: **Can’t reach the server. Your changes are kept and saving will retry automatically.** The editor keeps trying in the background. * If the server refuses a save, or a change is not valid yet, the pill reads **Not saved**. The error message, and the pill's tooltip when you hover it, give the reason: **Couldn’t save: {reason}**. Fix the field and the save goes through. * If someone else, or another tab, saved the same form while you were editing, the pill reads **Saved elsewhere** and nothing else is saved until you choose in the banner: **See saved version** or **Keep mine**. See [Autosave, drafts & publishing](/dforms/builder/autosave-and-publishing.md#if-someone-else-saves-the-same-form). * Closing the tab mid-save is safe: the editor flushes the pending change on the way out and also keeps a local backup. * If the browser crashes before a save lands, the next time you open the form you will see **Unsaved changes recovered**: "This form has edits from a previous session that never reached the server. Restore them, or keep the saved version?" Click **Restore edits** to continue where you left off, or **Discard** to keep the server copy. Autosave only touches the **draft**. Respondents keep seeing the last published version until you click **Publish**; the **Unpublished changes** badge reminds you that there is something to publish, and **Publish** first waits for any edit that is still being saved. Read [Autosave, drafts & publishing](/dforms/builder/autosave-and-publishing.md) for the full lifecycle. > **⚠️ Note:** The exception is **Connect → Integrations**: connecting or mapping HubSpot and webhooks applies to the live form immediately, without a publish. *** ## In this section * [Create a form](/dforms/builder/create-a-form.md): the new form dialog, layouts and templates; duplicate or delete from the list. * [Question types](/dforms/builder/question-types.md): the 14 tiles, grouped as Contact, Choice, Text and Content. * [Question settings](/dforms/builder/question-settings.md): Required, placeholder, default answer, field key, hidden, ends the form. * [Dynamic questions (variants)](/dforms/builder/dynamic-questions.md): ask a different title depending on an earlier answer. * [Recall answers with @](/dforms/builder/recall-answers.md): insert earlier answers into later copy. * [Hidden fields & URL prefill](/dforms/builder/hidden-fields-and-url-prefill.md): `?key=value` prefill and hidden questions. * [Partial submissions (lead capture point)](/dforms/builder/partial-submissions.md): save answers before the end. * [Several questions on one screen](/dforms/builder/screens.md): group questions so they are answered together on one Slides screen. * [One-page layout](/dforms/builder/one-page-layout.md): every question on a single page. * [Preview on desktop, tablet and mobile](/dforms/builder/preview.md): check the draft in device frames. * [Autosave, drafts & publishing](/dforms/builder/autosave-and-publishing.md): status pill, recovery, conflicts, publish. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dapta.ai/dforms/builder.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.