> 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/key-concepts.md). # Key Concepts The vocabulary used across the dForms docs: form, question, step and screen, Slides vs One page layout, score, outcome, partial submission, workspace, draft vs published, and the public link. This page defines the handful of words the rest of the documentation uses. Skim it once and the editor, the Logic tab and the Connect tab will make a lot more sense. *** ## Form A form is the thing you build, publish and share. Each form has a name (shown only to you in the editor and the forms list), an optional public title (what visitors see), a layout, a list of questions, design settings, logic, scoring, integrations and its own **Submissions** and **Analytics** pages. Forms belong to a workspace. Every member of the workspace can open, edit, publish and delete forms in it. ## Question, step and screen A **question** is one item in the list on the left of the editor. Most questions collect an answer (Name, Email, Single choice, Slider and so on). Some do not: a **Message** shows text with no input, a **Reveal screen** plays a short timed pause, and a **Scheduler** lets the respondent book a meeting. In the Slides layout the respondent moves through **screens**. A question on its own is one **step**: one screen. You can also group consecutive questions on the same screen (up to 10), so they are answered together and continue with one button. See [Several questions on one screen](/dforms/builder/screens.md). The **Counter** progress style counts screens (**Step 2 of 3**), while submissions, analytics and the question-by-question drop-off still count every question on its own. Every question also has a **Field key** (for example `email`, `team_size`) which is the stable name used in submissions, webhooks, HubSpot mapping and `[field]` placeholders.
The form editor with the question list on the left, the live canvas in the center and the question settings on the right

The editor: questions on the left, the live canvas in the center, settings for the selected question on the right.

## Layout: Slides vs One page You pick a layout when you create a form and can switch it later in **Design → Layout**. | Layout | How it behaves | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Slides** | One screen at a time: one question, or several questions grouped on the same screen. Respondents press **Next** (or **Enter**) to move on, a single-choice answer advances automatically when it is alone on its screen, and a **Back** arrow returns to the previous screen. Cover screen, reveal screens and step transitions are available. | | **One page** | Every question on a single page with one **Submit** button. Logic still applies live: questions show and hide as answers change. The cover renders as a header at the top, the progress reads **0 of 3 answered**, and an optional reveal screen plays once after Submit. |
The Design panel with the Layout section showing the Slides and One page cards with their descriptions, and the Reveal screen before results switch

Switch layouts any time from the Design panel. The live preview on the right updates instantly.

## Score Options in choice questions and ranges in slider questions can carry **Points**. When **Enable scoring** is on (Logic → **Scoring**), the points of every selected option are added up into one number per submission: the score. Contact, text and file upload questions never affect the score. The score is stored with the submission, shown in the **Submissions** table, sent to webhooks and HubSpot, and can drive logic ("Score so far") and outcomes. ## Outcome An outcome is a score range mapped to what the respondent sees at the end: a label (for example "You're a great fit"), a thank-you message, an optional redirect and a delay before it. You manage them in Logic → **Outcomes**. The first matching range wins, and the highest range has no upper bound so no score is left without an outcome. Scores that fall in a gap see the form's own ending (Design → **When the form ends**). ## Partial submission By default answers are saved when the respondent reaches the end. If you place the **Partial submit point** marker in the question list (the editor suggests **Capture after the email question** as soon as your form asks for an email), answers are stored the moment the respondent passes that point, even if they close the tab later. Those rows show up under **Submissions** with the status **Partial** (filter them from the **Status** column) and are upgraded in place to **Completed** if the person finishes. Webhooks and HubSpot can receive partial submissions too, unless [spam protection](/dforms/connect/spam-protection.md) is on: then partials are saved but only the complete, verified submission is delivered. ## Workspace A workspace is a separate space with its own forms, members, brand kit, notification emails and integrations. Workspaces in Forms are the same workspaces you see in the Dapta app: same name, same members, same roles (owner, admin, member). The workspace switcher at the top of the left menu moves you between them; the active one is the one every page acts on. ## Draft vs published Every change you make in the editor is saved automatically as a **draft**. The status next to the form name reads **Saving…** and then **Saved**, but nothing is live yet. Clicking **Publish** makes the current draft the live version that the public link serves. Until you publish again, new edits stay private and the badge **Unpublished changes** appears next to **Publish**. > **⚠️ Note:** Integrations in the **Connect** tab (HubSpot, webhook, emails) save to the live form immediately, without publishing. Tracking IDs, spam protection, design and questions wait for **Publish**. If someone else saves the same form while you are editing it, the editor stops saving and asks you which version to keep. See [Autosave, drafts & publishing](/dforms/builder/autosave-and-publishing.md). There is no unpublish button. To take a form offline, delete it from the forms list (this also deletes its submissions). ## Public link Each form has one public URL of the shape `app.dforms.ai/{account code}/f/{form slug}`, for example `app.dforms.ai/acme/f/lead-qualification-quiz`. The account code identifies your workspace. The `f` in the middle is always the same, so the link never names the person who built or shared the form. The slug is generated from the form name when you create the form; renaming the form later does not change it. To change the slug, click **Edit link** next to **Copy link** in the editor topbar. The change applies at once, and links you already shared keep working: they send visitors to the new address. Older links that carry a member's name in the middle (for example `app.dforms.ai/acme/alex/lead-qualification-quiz`) keep working too. You copy the link from the editor topbar (**Copy link**, or **QR code** for a scannable version) or from the copy icon on the form's row in the forms list. The same link powers the embed snippet and the auto-generated share card. ## What's next * [Getting Started](/dforms/getting-started.md): sign in and build your first form. * [Several questions on one screen](/dforms/builder/screens.md): group questions on one Slides screen. * [Logic, Scoring & Outcomes](/dforms/logic.md): conditions, branching, points and results. * [Partial submissions](/dforms/builder/partial-submissions.md): capture leads before the last question. * [Your public link](/dforms/share/public-link.md): what the URL is made of and how to share it. --- # 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/key-concepts.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.