> 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/logic.md).

# Logic, Scoring & Outcomes

The Logic tab of the dForms editor: the interactive Logic canvas, the read-only Logic map on small screens, and the form-wide Branching, Scoring and Outcomes dialogs that turn a plain form into a qual

Logic is what makes a form react to its respondents: questions that appear only when they matter, answers that jump ahead or end the form, points that add up to a score, and endings that change with that score. Everything lives in the **Logic** tab of the editor, next to **Build** and **Connect**.

***

## The Logic tab

Open any form in the editor and click **Logic** in the top bar. On a desktop screen you get the **Logic canvas**: every question is a card, the lines between them show the path a respondent takes, and the buttons above it open the three form-wide editors: **Branching**, **Scoring** and **Outcomes**.

<figure><img src="https://3835013762-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCy5rSNtQmtqYCGzJlNEB%2Fuploads%2Fgit-blob-53565ff5e9a616c010aa418a5840102d03a4026d%2Fforms-logic-01-logic-tab-canvas.png?alt=media" alt="The Logic tab showing the Logic canvas with question cards, a dashed jump to a later question, three outcome cards and the End marker, with the Branching, Scoring and Outcomes buttons highlighted"><figcaption><p>The Logic canvas. Dashed lines are jumps, the cards on the right are the outcomes, and <strong>END</strong> is where a skipped form lands.</p></figcaption></figure>

How to read the canvas:

* **START** is where every respondent begins. Cards then run left to right in question order.
* A solid line is the normal path: "continue to the next question in order".
* A dashed line is a jump created by a branching rule. The label on the line is the answer that triggers it (for example **$2,000+ / month**). A jump with no target leads to the shared **END** marker (the rule reads **skip to end**).
* The highlighted cards near the end are your **Outcomes**: one per score range, stacked because a respondent only ever sees one of them.
* On a **Slides** form, questions you grouped on one screen sit inside a frame with a chip such as **Screen 2 · 3 questions**. Jumps leave from the screen and land on its first question. See [Several questions on one screen](/dforms/builder/screens.md).
* Hover a card to reveal its edit button (its tooltip reads **Edit the logic for {question}**). It opens the same Logic dialog you get from the **Build** tab, so you can fix a rule without leaving the canvas.

The controls in the bottom left let you **Zoom out**, **Zoom in**, **Fit to screen** and **Auto-arrange**. Drag a card to move it; drag the empty canvas to pan. Cards you moved keep their position until you click **Auto-arrange**, which restores the automatic layout.

***

## The Logic map on small screens

Below a laptop-sized window the canvas is replaced by a read-only **Logic map**: a vertical list of the same cards, with the jumps and conditions written out in plain sentences (**If Under $500 / month → skip to end**, **Show if What's your main goal? is any of Capture more leads, Qualify faster**). Questions that share a screen carry the same **Screen 2 · 3 questions** chip. You can read the flow on a phone or a narrow window, but editing happens in the dialogs.

***

## The three toolbar dialogs

| Button        | What it opens                                                                                                                                                                                                                                                                                                                   |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Branching** | Every question in order, with its **Always go to** catch-all, its **If answer is** rules and its **Show when** / **Hide when** conditions. The summary line at the top reads, for example, **3 of 8 questions carry logic.** A question that shares a screen notes that its jump happens when the respondent leaves the screen. |
| **Scoring**   | Every point value in the form on one screen, plus the **Enable scoring** master switch.                                                                                                                                                                                                                                         |
| **Outcomes**  | The score ranges and what each range shows at the end: a label, a thank-you message, an optional redirect.                                                                                                                                                                                                                      |

<figure><img src="https://3835013762-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCy5rSNtQmtqYCGzJlNEB%2Fuploads%2Fgit-blob-5bb75a1ab4ab766830716db0c66a8c536943e5f3%2Fforms-logic-02-branching-dialog.png?alt=media" alt="The form-wide Branching dialog listing every question with its Always go to control, and the summary line 3 of 8 questions carry logic highlighted"><figcaption><p>The <strong>Branching</strong> dialog is the quickest way to review all the logic of a form in one place.</p></figcaption></figure>

***

## What a qualifying form looks like

A typical lead qualification form combines the four building blocks in this order:

1. **Points** on the answers that matter (team size, budget, urgency). See [Scoring](/dforms/logic/scoring.md).
2. **Conditions** so that follow-up questions only appear when an earlier answer calls for them. See [Show & hide conditions](/dforms/logic/conditions.md).
3. **Branching rules** that send a disqualifying answer straight to the end, or a hot lead straight to the booking step. See [Branching & jumps](/dforms/logic/branching.md).
4. **Outcomes** that map score ranges to different endings: "Not a fit", "Nurture", "Book a call". See [Outcomes](/dforms/logic/outcomes.md).

> **💡 Tip:** A new, empty form offers templates under **Or choose a template**. The **Lead qualifier** template ships with points, a branching rule and outcomes already wired. Create a form, pick it and open the **Logic** tab to see a working example.

## In this section

* [👁️ Show & hide conditions](/dforms/logic/conditions.md): show or hide a question based on an earlier answer or the score so far.
* [↪️ Branching & jumps](/dforms/logic/branching.md): send respondents to a later question or to the end depending on their answer.
* [🏅 Scoring](/dforms/logic/scoring.md): award points per option and per slider range, and read the highest possible score.
* [🎯 Outcomes (results by score range)](/dforms/logic/outcomes.md): map score ranges to labels, messages and redirects.
* [🏁 Ending screen](/dforms/logic/ending-screen.md): the default thank-you screen every respondent sees.
* [✨ Reveal screens](/dforms/logic/reveal-screens.md): a short processing pause before a result.


---

# 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/logic.md?ask=<question>&goal=<user_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.
