The editor is a single, document-style canvas — type, insert blocks, and arrange them like a doc. Three areas do the work:
The workspace sidebar on the left holds navigation across all your forms.
Beside Publish sits the issue indicator, a traffic light for the readiness check: green when the form is ready, amber for warnings, red for errors. Click it to list what it found — each entry links to the place you fix it. Errors block publishing. Warnings do not, but formbase asks first and offers to fix them for you. Publish checks lists every finding and how to clear it.
Above the form title, use Add Cover and Add Logo. The picker has four tabs — Upload{' '} (PNG, JPG, or WebP up to 5 MB), Colors for a solid color, Unsplash, and Icons. Drag a cover up or down to reposition it. Only uploads count toward your storage.
Click an empty line on the canvas and type / — or press Cmd/Ctrl + / — to open the block menu. Keep typing to filter. Four categories, in this order:
The menu only offers what fits where the cursor is: no questions or logic on a thank-you page, no root-only blocks inside a column. See{' '} Question types for the full catalogue and{' '} Form structure → Block menu for what the drag handle offers.
> 💡 **Just describe what you need** >> Don't feel like browsing the menu? Open AI chat and say “add a phone number and a date picker”. It inserts the > fields for you. >
Click a block's drag handle to open its menu. What it offers depends on the block: Turn into, Options,{' '} Validation, align, create repeating group, insert, duplicate, move, hide, and delete.
Select several blocks by dragging a rectangle around them, by shift-clicking a second block to take the range, or by pressing{' '} Cmd/Ctrl+A once for the current block's text and again for every block. The handle menu then acts on the whole selection: turn compatible blocks into another type, mark questions required or optional, hide or show titles, create a repeating group, duplicate, move, hide, or delete.
On a Mac use Cmd; on Windows and Linux use Ctrl.
Select any text to see a floating toolbar: bold, italic, underline, strikethrough, inline code, equation, link, font, font size, and color. See Content blocks → Text formatting for the full list.
Forms can be a single page or split into many. Insert a Page Break to create a multi-step flow with a progress bar, and{' '} 2 Columns to place blocks side by side. Both behave like any other block — drag to reorder, delete from the block menu. See Form structure for the full guide.
The Translate tab opens a side-by-side editor for every visible string in your form. Add languages, translate each question, and publish. See Translating form content for the full guide.
The floating button in the bottom-right opens AI chat — an assistant that can write, audit, and edit your form. Pick a starter prompt or just describe what you want. Usage draws from your AI credit balance, shown above the input.
The Theme button (palette icon) opens a docked panel with a light/dark mode toggle, preset themes, and per-section controls for fonts, colors, inputs, choices, buttons, and more. Presets work on every plan; custom colors and fonts need Pro. See{' '} Appearance & theming for details.
The Share button opens a sheet with two channels. Public link holds your share links — create several to tell campaigns apart or to set different languages and limits — with Embed, Popup, and{' '} QR Code beside the URL. Requests sends the form to one named person at a time. See{' '} Share links,{' '} Embedding & popups, and{' '} Creating requests.
The Settings button (gear icon) opens a dialog with six tabs. For a deep dive, see{' '} Form settings.
Switch to Preview to fill the form exactly as a respondent would: logic fires, variables resolve, and you can add repeating-group entries. Nothing is saved — answers live in memory and reset on reload, and uploads and payments are stubbed. Click{' '} Publish when you are happy; formbase keeps your draft separate, so changes only go live when you publish. To undo edits before publishing, hit Revert unpublished changes to go back to the last published version.
The Publish history button (clock icon) lists every published version with a timestamp, and shows each one's{' '} Form, Emails, and Translations as they were frozen at publish. Browsing works on every plan. Restoring needs Business: pick a version, click Revert to this version, then choose{' '} Open as draft (load it into the editor without publishing) or Publish now (go live right away).
> ℹ️ **Quick search** >> Press Cmd K (or Ctrl K) outside the canvas to jump to any form, folder, workspace, or setting. Inside the canvas > the same keys add a link instead. >
Every form starts as a single page. For short forms (under ~7 fields), that is usually enough. When a form gets longer or branches into different flows, split it into pages so respondents see one focused set of questions at a time.
Respondents navigate between pages with Next and Back buttons that formbase adds automatically. The final page shows a Submit button instead of Next. Back retraces the pages the respondent actually visited, so a page jump is undone step by step rather than dropping them on the page before.
The thank-you page is not one of these pages — it is the screen after submitting, and it never appears in the page count.
A thin progress bar at the top of the form shows respondents how far along they are.
> Conditional logic can jump to a specific page — for example, "If the respondent picks 'Self-employed', skip to page 4". The jump happens > when the respondent presses Next on the page with that question. On later pages, Next goes on in page order. A rule that reads only > hidden or calculated fields can jump from any page, but only forward. A page the jumps skip counts as hidden: its questions are not > required, and its answers are dropped. See Conditional logic. >
Columns let you place blocks side-by-side. Use them for compact layouts — a name and email on one row, an image next to a description, or grouped choice fields.
> Logic, Hidden Field, Calculated Field, Page Break, Thank You Page, and a repeating group only work at the top level of the form. The > block menu hides them while the cursor is inside a column. A repeating group forbids a little more: Payment, Schedule appointment, and > Documents are also out, because a submission pays, books, and is handed documents once — not once per entry. >
> ℹ️ **Responsive behavior** >Columns stack vertically on small screens. Respondents on mobile see one column at a time, so the form stays readable.
Every block has a drag handle on its left edge. Grab it to reorder blocks within a page or move them between columns.
Click the drag handle (or tap the block indicator on touch devices) to open a menu. What it offers depends on the block; these are the entries you will meet most.
Select several blocks at once — drag a rectangle around them, shift-click a second block to take the range, or press Cmd/Ctrl+A{' '} twice — and the same menu acts on all of them: turn into, required, title visibility, wrap into a group, duplicate, move, hide, delete.
A repeating group is a labeled container that holds a set of member fields — like a "Add additional guests" group with Name and Age. Respondents add as many entries as they need, so you don't have to guess how many you'll get up front. Insert a fresh{' '} Repeating Group from the block menu, or select a run of existing fields and pick Create repeating group.
For the full guide — building groups, filling them out, and how entries show up in submissions — see{' '} Repeating groups.
Every form has a thank-you page — always the last page. It is what respondents see after they submit. Customize it with headings, images, links, and piped answers — or redirect to an external URL instead.
For the full guide, see Custom thank-you page.
The block menu groups blocks into four categories: Basic Blocks, Form Fields, Layout, and Media. Every question lives under Form Fields. The names below are the exact menu labels — type a few letters to filter.
These fields collect typed answers. Email, Website URL, and Phone Number also check the format as the respondent types.
Only these six inputs carry a placeholder and a default value. Turn into switches freely between them.
Choice fields let respondents pick from a list you write.
Decision is the one choice question whose values are fixed — approve, decline,{' '}
changes — so a workflow can branch on the answer whatever you call the labels, in any language.{' '}
Decisions & approvals →
Picture choice is one block with two modes. Switch between them with Allow multiple selection /{' '} Allow single selection in the block menu.
These fields measure sentiment, preference, or priority. The Summary tab charts their distribution.
> ℹ️ **Linear scale is not in the block menu** >> A linear scale (a numbered scale from 1 up to 10 — good for NPS or Likert) has no entry of its own. Insert a{' '} > Star Rating and use Turn into → Linear scale in the block menu, or ask AI chat for one. Adjust the > maximum with Increase / Decrease scale max. >
Uploads on both sides count toward your workspace storage.
> Bot protection is a form-level setting, not a question type. It is always on for free forms; from Pro you can toggle it per form under{' '} > Form settings → Access. See{' '} > CAPTCHA and bot protection. >
The rest of the block menu structures and enriches the form. None of them collects an answer.
Basic Blocks — Heading 1, Heading 2, Heading 3, Bullet List, Numbered List. Paragraph has no menu entry: it is the default block, so just type on the canvas.
Layout — Table, 2 Columns, Repeating Group, Logic, Hidden Field, Calculated Field, Page Break, Thank You Page.
Media — Image, YouTube Embed, Google Maps Embed, Embed anything.
> Questions, logic, and page breaks are hidden from the block menu while the cursor sits on the thank-you page — it is the last screen, so > there is nothing left to ask or branch on. >
Type a question's title and options straight on the canvas. Everything else lives in the block menu: click the drag handle on the block's left edge (or tap the block indicator on touch) and pick from Turn into, Options,{' '} Validation, and the usual duplicate / move / hide / delete actions.
These options appear on every question, whatever its type.
A field's key — the name automations prefill and read it by — is set in the Keys table, which the toolbar's key icon opens for the whole form: one key per field, option, row and column. Leave a key empty to use the one derived from the title or label. Editing a key on a published form warns you that automations using the old key will break. Each option's hint row also carries its key as a chip you can edit in place. See Field keys for how keys are derived, frozen at publish, and used by callers.
> 💡 **Adding help text** >> formbase is a document-style editor — to add help text or instructions for a question, insert a paragraph or heading block above or > below the field on the canvas. Content blocks between questions are visible to respondents and work just like any other block. >
> ℹ️ **Title visibility and data** >> Hiding a title does not remove the field from submissions. It still shows as a column header in exports, so give hidden-title fields a > clear internal name. >
Min length and Max length live under Validation in the block menu and apply to{' '} Text Input, Text Area, and Website URL. Text Area is the multi-line variant of Text Input — switch between them with Turn into.
Minimum and Maximum live under Validation and apply to Number,{' '} Star Rating, and a linear scale. Number also has Step: the answer must be a multiple of it, so a step of 1 accepts only whole numbers and 0.5 accepts halves. Leave it empty to accept any number.
These settings apply to choice fields: Radio Buttons, Checkboxes, Dropdown,{' '} Ranking, Single Picture Choice, and Multi Picture Choice.
Single options can also be hidden or preselected from the canvas: with the cursor in an option, press ⌘ + H (Ctrl + H) to hide it, or ⌘ + D (Ctrl + D) to select it by default.
The Star Rating field shows 5 stars by default. Use Increase max stars and{' '} Decrease max stars in the block menu to set anything from 1 to 10. Turn it into a linear scale from the same menu; the maximum carries over and the menu items become Increase / Decrease scale max.
The Matrix / Grid field creates a grid of choices. Define Rows (the sub-questions) and{' '} Columns (the answers). The respondent picks one column per row. Under Validation you can{' '} Require all rows or set Min answered rows.
File Upload takes Min files, Max files, Max size (MB), and{' '} Accepted types under Validation. See{' '} File uploads & signatures for the details.
The Payment field collects a one-time charge. Set the Amount and Currency on the block — USD, EUR, GBP, JPY, CAD, AUD, CHF, SEK, NOK, DKK, NZD, SGD, HKD, AED, or TRY. Each currency has a minimum charge (0.50 for USD and EUR), and publishing is blocked until Stripe is connected and the amount is valid. See{' '} Payment collection.
A field's default value can come from another field in the same form instead of fixed text — a hidden field (for example a URL parameter) or a calculated field. It works on the six inputs that have a default-value slot: Text Input, Text Area,{' '} Email, Website URL, Phone Number, and Number.
To set it up:
To remove the reference, click the × on the chip, press Backspace, or press ⌘ + D again.
If you want a literal @ instead — a placeholder like @yourhandle — press Esc to close the menu and keep
typing; the input stays in the mode it was in. A chip turns red when its field has been deleted; re-adding a field with the same name
reconnects it.
The chip replaces the field's placeholder text. The @ only opens the menu as the first character, so a default like{' '}
jeff@example.com stays plain text.
When someone opens the form, the field is pre-filled with the referenced value — for example, a link ending in{' '}
?recipient=Jeff fills a Text Input that references the recipient hidden field with "Jeff". How it behaves:
?age=abc).
See Hidden fields and Calculated fields.
Validation runs as the respondent fills out your form. formbase highlights bad input inline and refuses to submit until everything passes.
Each question type checks its own shape, with nothing to configure. Email checks the address format.{' '} Website URL accepts http and https links only and rejects a host that is not a real domain. Phone Number{' '} checks the number against the selected country. Number, Date Picker, and Time Picker{' '} reject anything that is not a number, a date, or a time.
On Business, an email question can additionally require verification — the respondent confirms that address with a one-time code before the form accepts the submission. The toggle sits under Validation → Verification. See{' '} respondent email verification.
Open the block menu and pick Validation. The rules on offer depend on the question type; these are the exact menu labels.
Radio Buttons, Dropdown, Toggle Switch, Signature, Ranking, Payment, and Schedule appointment take no validation rules — required or not is the only choice. Inside a repeating group, email verification is not offered.
{`^\\d{5}(-\\d{4})?$`}
{`^#[0-9a-fA-F]{6}$`}
{`^[a-z0-9-]+$`}
A value that doesn't match shows a generic "Invalid value" error, so add a paragraph near the field describing the format you expect. An invalid regex is ignored and never blocks submission. Length rules count characters after trimming leading and trailing spaces.
formbase checks validation live in the browser as the respondent types. Format and rule errors appear immediately with an inline message; a "This field is required" error appears once the field has been touched, or when the respondent tries to submit.
> ⚠️ **Don't validate sensitive data with regex alone** >For things like credit cards or government IDs, use the appropriate field type or integration. Regex catches shape, not validity.
The File Upload field lets respondents attach files to their submission. Type / on the canvas and pick{' '} File Upload.
Click the drag handle next to the field and open Validation to set its rules:
The field shows respondents what it expects — "Accepted files: .pdf, .png", "Max 5 MB", "2-4 files" — so the rules double as the hint.
Size, count, and type are checked in the browser as the respondent picks a file; a violation shows an inline error and blocks submission. Two more limits apply on the server and cannot be raised per field:
Uploaded files are stored with the submission. Open a submission in the inbox to view or download them.
A File Upload field offers two logic conditions: has file and has no file. Use them to show a follow-up question only when nothing was attached, or to skip a page once the document is in.
The Signature field captures a drawn signature. Type / and pick Signature from the slash menu. Respondents draw with a mouse, trackpad, or finger. formbase stores the result as an image, viewable and downloadable from the submission inbox.
> ⚠️ **A signature makes the submission final** >> Any form version that contains a Signature, Payment, or Schedule appointment field turns off{' '} > edit after submit for submissions made against it. Respondents cannot reopen and > change what they signed. >
Signature fields support two logic conditions: is signed and is not signed. Use them to show a confirmation page only after a waiver is signed, or to require extra info when a signature is missing.
Signature data is not shown for partial (in-progress) responses: the inbox hides the thumbnail and exports leave the column empty until the respondent submits.
Signatures work well for any form that needs documented consent or acknowledgment:
image/* for photo evidence, with a high Max files so claimants can
document the damage properly
> Every file, including signatures and generated PDFs, counts against the workspace owner's storage. Set conservative size limits if you > collect large files regularly. >
A Documents block is a titled download list. You upload one or more files once, give each a display name, and every respondent sees the same list — on a public link and on a request alike. Each row opens the file in a new tab and has a download button. The block asks nothing of the respondent: it collects no answer of its own.
The block itself has no checkbox — you decide what "read" should mean. Add a required Switch question right below it, titled "I have read the lease contract", and the form cannot be submitted until it is on. Prefer several statements? Use a Checkbox with one option per document. Need a signature? Add a Signature question. All of them work with{' '} conditional logic, translations and exports as usual.
> 💡 **Why a separate question?** >> A Switch, a Checkbox and a Signature already do everything a built-in checkbox could, and they can be required, translated, referenced > in logic and read back through the API. The Documents block stays a list; the proof of reading is whatever question you put under it. >
Every completed submission records, under the block's field key, the documents that respondent was shown — its name and whether it came from the form or from a request. It appears in the submission view, in exports, in the PDF and in{' '} callbacks:
``` "documents": [ { "name": "Price list 2026", "source": "form" }, { "name": "Your lease contract", "source": "request" } ], "contract_read": true ```On a request, an automation can add documents for that one recipient into the same block. They appear below your authored files, marked "For you"; the authored files stay exactly as published for everyone. See{' '} Creating requests → Documents.
Word, Excel and PowerPoint files are not accepted yet — export them as PDF first.
---Respondent email verification is a per-question rule on Email fields. When it is on, the respondent confirms the address they typed with a 6-digit code that formbase emails to them. The form does not accept the submission until the code checks out, so fake or mistyped addresses never reach your inbox. Turning the rule on requires a Business plan.
Verification is not offered for email questions inside repeating groups — the server skips grouped questions too.
Code didn't arrive? Resend unlocks after 30 seconds. Five wrong codes retire the code and the respondent asks for a new one. Disposable-mailbox domains are refused outright, with "Use a non-temporary email address."
Respondents cannot leave the page or submit while a verification-required email question holds an unverified answer. The server checks the same thing on submit, so the rule cannot be bypassed by a hand-made request.
If your form sends from a custom email domain, verification codes use it too.
A verification belongs to the address and the respondent's session, not to the question. If two email questions hold the same address, one verification covers both. Changing the value re-checks it: a new address must be verified again.
> This rule verifies an email answer. To require respondents to sign in before they can open the form at all, use the{' '} > authentication gate instead. >
A repeating group is a labeled container that holds one or more questions — its member fields. Respondents add as many{' '} entries of the whole group as they need. Each entry collects a fresh set of answers for every member field inside.
Reach for one whenever a single respondent might supply the same shape of data more than once:
A repeating group is a structural block: a group title, the member fields inside it, and an add button. Groups live at the top level of your form — the editor pins that shape automatically, and you cannot nest one in another.
Repeating Group. The cursor lands in the title.', }, { title: 'Name the group', description: 'Give it a title, like "Additional guests". This is the heading respondents see above the entries. Hide it later from the block menu if you do not want it.', }, { title: 'Add member fields inside', description: 'Drop ordinary questions into the group — Text Input, Number, Date Picker, Dropdown, and more. Each keeps its own label, placeholder, and required toggle.', }, { title: 'Edit the add-button label', description: 'The button reads "Add one more" until you change it. Make it match the content — "Add another guest".', }, ]} />Already built the fields? Select them, open the block menu from the drag handle, and choose Create repeating group — it works on one block or on a run of them. The same menu on a group offers Hide title and Remove grouping, which unwraps the questions again.
The first entry shows inline — the group title, its member fields, and the add button, just like any other section of the form. As soon as a respondent adds a second entry, each one becomes a numbered card (01, 02, 03 …) with a remove control in its corner.
On a request that locks one of the group's member fields, the shape is fixed for that recipient: they can neither add nor remove entries.
> 💡 **Keep member fields focused** >> A repeating group works best with a handful of tight questions — the set a respondent fills in once per entry. The required toggle > applies per entry, so every entry must clear the same validation. >
A whole group can be shown or hidden by a logic rule, exactly like any other block. Member fields cannot: they are not offered as conditions, as show/hide targets, or as required/optional targets, because a rule would silently act on the first entry only. Branch on a question outside the group instead.
Once responses arrive, the group stays grouped across every surface. Each page below carries the full detail — this is just the map:
Pipe a repeating group into other questions, notifications, or integrations with an @ mention — mention a single member field to join that field's value across every entry, or mention the whole group to pull in all entries at once. See{' '} Answer piping → Referencing repeating groups for exactly how each reference resolves, with examples.
Type / on the canvas (or press Cmd/Ctrl + /) to open the block menu, then pick a block. Content blocks sit alongside questions and reorder with drag and drop. Paragraph is the default block — just type on the canvas; it has no menu entry.
An image carries an optional caption (Add caption in the block menu) and an Align submenu with Left, Center, and Right. Replace image swaps the file without losing the caption.
Three embed blocks live under Media. Each one starts empty; open its block menu to fill it in.
Select text in a paragraph, heading, list item, or table cell to reveal the floating toolbar:
Headings and lists are inserted from the block menu, not the floating toolbar.
Insert a Table from the block menu. Tables are static — respondents read them but cannot edit cells. Good for pricing grids or reference data.
Click any cell to edit it. Hover a row or column to reveal its grip, then click the grip for its actions:
Drag the same grip to reorder a row or column. Drag the border between two cells to resize; the first drag freezes the current widths, so the table keeps the proportions you saw. Cells take the same inline formatting as paragraphs — bold, italic, links, and answer piping with{' '} @ mentions.
Content blocks support answer piping. Type @ in any paragraph, heading, or list item to open the mention menu and insert a field reference. For example, a heading that reads "Thanks, @First name" shows the respondent's actual name when they fill out the form. See Answer piping for the full guide.
> Heavy media slows down form load. Use embeds where they directly help the respondent — a short explainer video, a map showing your > location. >
Every logic block has one or more rules. Each rule pairs a condition group (when should this fire?) with one or more actions (what should happen?). Nine action types are available:
A logic block is a document element — it sits on the canvas between questions, just like a heading or an image. You can place it anywhere: between two fields on the same page, at the top of a page, or right before a page break.
Conditions are the When side of a rule. Each condition picks a field, applies an{' '} operator, and often compares against a value. The field picker groups what you can watch:{' '} Questions, Hidden Fields, Calculated Fields, and Metadata (today, the respondent's locale).
Once a rule has two or more conditions, a toggle appears at the top of the When section:
Add a set of conditions nests a second group inside the first, one level deep, with its own All/Any toggle. That covers compound logic like "plan is Pro and (country is Norway or country is{' '} Sweden)". A set holds conditions only — it cannot hold another set.
> ⚠️ **A hidden question has no value** >> If logic hides a question, the answer it may already hold counts for nothing — not in conditions, not in calculations, not in the > payment amount, and not in the stored submission. The answer comes back only if the question becomes visible again. The same goes for > every question inside a hidden row, column or repeating group, and for a picked option that logic hides. A page that the Set next page > rules skip counts as hidden too: its questions are not required, and whatever was answered there is dropped. Hidden fields are > the opposite: they always carry their value. >
> 💡 **Keep it readable** >> If a single logic block feels too complex, consider splitting the logic across multiple logic blocks or restructuring your form pages. >
The operator list is decided by the field you picked — you only ever see the ones that field supports. Below, each heading names the exact set.
Every text comparison ignores letter case and spaces at either end, so x@Competitor.com ends with{' '}
@competitor.com.
The other text-like inputs carry a narrower set, so pick the type that matches how you need to compare:
Schedule appointment and Documents can be visibility targets but never condition sources. A booking is attached to the submission rather than stored as an ordinary answer, and a Documents block collects no answer at all. Use earlier qualification answers to show or hide either one. Every visible Schedule appointment question must be booked before submission; a hidden one does not block it. See Cal.com scheduling with logic.
Each action needs a target — the thing it acts on. The target depends on the action type:
Show and Hide reach beyond questions. Target any block on the canvas — a paragraph, heading, image, or layout container — to reveal a note that was hidden by default, or hide content once it is no longer relevant. They can also target individual options inside a choice field, not just the whole question. Hide a block from the block menu first, then write a rule to reveal it.
Every rule is independent, and they all evaluate together. Rules are read top to bottom, across logic blocks, in document order. How several rules on one target combine depends on the action.
So you can point several rules at one block without them fighting. A feedback form has a Radio Buttons question — "What can we help you with?" — with four options, and a "Can we contact you?" email field hidden by default. Four rules each Show that same email field (plus their own follow-up question) for their option. The email field appears no matter which option is picked, and stays hidden only if none is.
> 💡 **Often one rule is enough** >> To reveal a block for several answers, one rule with Any and a condition per answer — or a single{' '} > is not empty condition to cover them all — is easier to read than four rules. Reach for several rules when each option > also needs its own distinct follow-up. >
When two rules disagree on the same target — one Shows a block while another Hides it, or one makes a field required while another makes it optional — and both conditions match at once, the first rule wins. The later, losing rule is flagged in the editor: "This action never applies — an earlier rule already controls its target. Rule order decides: the first rule wins."
One ordering exception: a rule whose condition reads a calculated field runs after the rule that writes it, whatever the document order, so a score is always computed before anything branches on it. Rules that write each other's calculated fields in a loop raise a publish warning that names the chain — break the loop so values resolve predictably.
A question that ends up hidden is never required, whether it was hidden by a rule or hidden from the block menu with no rule to reveal it. The asterisk disappears and submission is not blocked — otherwise a respondent could be locked out of a form by a field they cannot see.
A satisfaction survey asks "How would you rate your experience?" with a 1-5 Star Rating. A logic block below it uses the condition "rating is less than or equal to 3" with the action Show targeting a Text Area field that asks "What could we improve?" Respondents who rate 4 or 5 never see the follow-up.
A signup form has a Radio Buttons question: "Which plan fits you best?" Below it sits a paragraph — "Good choice! Our Pro plan includes priority support." — hidden by default with the block menu's Hide. A logic block reveals it: if plan is{' '} "Pro", Show the paragraph. The encouraging note appears only for Pro pickers, and stays hidden for everyone else.
An event registration form has a Radio Buttons question: "Are you attending in person or remotely?" Two logic blocks follow:
Rules 1 and 2 read the attendance question, so they act when the respondent leaves its page. After that, Next goes on in page order. Rule 3 reads a question on "Venue details", so it acts when the respondent leaves that page. In-person attendees then skip "Streaming setup". Each path collects only relevant information, then both converge on a shared "Confirmation" page.
A lead-qualification form has three Star Rating questions: budget, timeline, and authority. A calculated field named "Lead score" uses a logic block with the Calculate value action to add the value of each rating. A second logic block reads the calculated field: if Lead score is greater than 12, Set next page "Priority follow-up"; otherwise jump to the standard confirmation page.
The URL populates a hidden field named plan (e.g. ?plan=enterprise). A logic block checks: if plan{' '}
is "enterprise", Show the "Dedicated account manager" question and Make required
the "Company size" field. Free-tier respondents never see these questions.
An order form calculates a running total. A logic block uses the condition: if Order total is less than 10, Prevent submit form. The respondent cannot submit until the minimum order threshold is met.
While a prevent rule is active, the button reads as unavailable and the respondent is told why. Type the reason into{' '} Message shown to respondent on the action row — "Your order must total at least 10" — so they know which answer to change. Leave it empty and the form falls back to "This form cannot be submitted with the current answers." (or "You cannot continue to the next page with the current answers." for a navigation block). When several prevent rules fire at once, the first one that carries a message supplies the wording.
> 💡 **Test logic with Preview** >> After setting up your rules, switch to Preview in the top toolbar and fill out the form as a respondent would. Logic > fires in real time in Preview, so you can verify every branch, hidden field, and validation gate before publishing. >
Forms often need context that the respondent can't (or shouldn't) provide themselves. Hidden fields solve this by letting you attach metadata to each submission through the URL. This is useful when you already know something about the respondent before they open the form — where they came from, who referred them, or which record they belong to in your system.
Type / on an empty line and pick Hidden Field from the Layout category. It only works at the top level of
the form — not inside a column or a repeating group. Each hidden field has two settings:
utm_source, contact_id). It is
also this field's key, so it is what a caller sends and what the answer comes back under. See{' '}
Field keys
A parameter name must be URL-safe as written: letters, digits, and - _ . ~ ! * ' ( ) are safe. Write spaces and other special
characters percent-encoded, for example recipient%20name. An empty, invalid, or duplicate parameter name is a publish error —
the issue indicator in the toolbar flags it and publishing stops until you fix it.
When a respondent opens your form with a matching parameter in the URL, the hidden field captures that value automatically. For example, if your hidden field's parameter name is utm_source, the URL below sets the field to newsletter.
``` https://form.formbase.so/abc123?utm_source=newsletter ```You can pass multiple hidden fields at once:
``` https://form.formbase.so/abc123?utm_source=newsletter&utm_medium=email&contact_id=12345 ```?utm_source=) leaves the field empty.
?score=abc leaves it empty.
On a share link, to show a URL value in a visible field the respondent can edit — say, pre-filling their name — make the hidden field the field's default value by typing @. See{' '} Default values from other fields.
The hidden-field-plus-@ technique above exists because a share link has only one way in: the URL. Anyone can edit a URL, so a share link can carry a value only through a parameter, and a hidden field is what receives it.
A request has a second, private way in. The caller sets the answers when they create the request, server side, so a request can pre-fill a visible question directly — no hidden field and no @ default involved. The recipient opens the form with the answer already in the box.
prefill
{' '}
— starting answers for visible questions, addressed by field key. The recipient sees them and can change them.
readonly
{' '}
— the subset of those pre-filled keys the recipient may read but not edit.
context
{' '}
— values for hidden fields, which the recipient never sees.
The split is enforced. Sending a visible question's key in context is rejected, with an error telling you to send it in{' '}
prefill instead, and the reverse is rejected too. So add a hidden field when you want to{' '}
carry data you don't want shown, not merely to pre-fill something.
> On a request, ?param= values are not read at all — they do not fill a hidden field, and they do not override anything the
> caller set. This is deliberate: the recipient holds the link, so honouring URL parameters would let them rewrite the caller's own
> context. Request context always wins, because on a request it is the only source.
>
?email=jane@example.com from your email tool and make that hidden field the
default of the form's Email question. The respondent sees their address already filled in and only fixes it if it's wrong.
> Email platforms (Mailchimp, ActiveCampaign, HubSpot), ad platforms (Google Ads, Meta), and link shorteners all let you append URL > parameters. Hidden fields catch them with zero extra setup on the form side. >
In the Submissions table, hidden fields show as their own columns — formbase marks them with an eye-slash icon so you can tell them apart from visible questions. They also appear in exports, integrations (Google Sheets, webhooks, etc.), and the submission detail panel.
> ℹ️ **UTM in analytics vs. submissions** >> formbase records utm_source, utm_medium, and utm_campaign with each visit's analytics, and the Traffic Sources chart groups submissions > by source and medium, but it doesn't save them on each response. To see a parameter's value per submission, add a hidden field with that > name (for example utm_source). It then shows in both the submissions table and analytics. >
Hidden fields work as condition sources in conditional logic. A logic rule can read a hidden field's value and branch — showing different questions, jumping to a page, or updating a{' '} calculated field.
For example: pass ?plan=enterprise via the URL. A logic rule checks if the hidden "plan" field equals "enterprise" and jumps
to a dedicated page with enterprise-specific questions.
Calculated fields are invisible to respondents but compute values based on logic rules you define. They store either a{' '} number or text result, and update live as the respondent answers questions.
The flow: you create a calculated field, set an initial value, then add logic rules with the Calculate value action. Each rule runs an operation (add, multiply, set, etc.) when its condition is met.
Type / on an empty line and pick Calculated Field from the Layout category. It only works at the top level
of the form — not inside a column or a repeating group. Set:
0 for a score) or
pick a hidden field of the same type to seed it from a URL parameter. If the parameter is
missing or invalid, the field starts at 0 (number) or empty (text)
These are the exact entries in the operation picker on a Calculate value action.
Each operation takes a value that is either:
A numeric operation is skipped when its value is empty or isn't a number, and dividing by 0 is skipped too, so the current total stays as it is. Answers to questions hidden by logic don't count — a hidden question has no value at all, so its answer never reaches a calculation.
Every matching Calculate value rule runs, in document order, on the running value — they stack rather than compete. One exception to document order: a rule that reads a calculated field always runs after the rule that writes it, so a score is finished before anything branches on it. Rules that write each other's fields in a loop are flagged as a publish warning that names the chain, so break the loop rather than publish through it.
Quiz scoring — Create a calculated field "Total score" with initial value 0. Add logic rules: if Q1 equals "Yes", Add 10; if Q2 is greater than 5, Add the value of Q2. The score updates live as the respondent answers.
Dynamic pricing — A product order form has a Number field for quantity and a Dropdown for size (Small, Medium, Large). Create a "Price" calculated field. Logic rules: if size is "Small", Set to 10; if "Medium", Set to 15; if "Large", Set to 20. Below those, add a rule with no conditions that Multiplies Price by the quantity field. Rules run top to bottom, and a rule with no conditions always runs. Pipe @Price into the thank-you page. To charge that calculated price directly, see Dynamic pricing in Payment collection.
Lead qualification — Three Star Rating questions rate budget, timeline, and authority. A "Lead score" field uses{' '} Add for each rating. A logic rule checks: if Lead score is greater than 12, Set next page "Priority follow-up"; otherwise jump to the standard thank-you.
Concatenating text — A text calculated field "Full name" starts empty. Logic appends @First name, then appends a space, then appends @Last name. Use @Full name in the thank-you page or email notifications.
> 💡 **Chain with logic** >> Calculated fields also work as condition sources. One rule computes a value, another reacts to it — e.g. "if Total > 50, jump to the Premium page." This lets you build multi-step scoring without any code. >
A visible field can start with a calculated field's value, so the respondent reviews a computed value instead of typing it. In a Text Input, Text Area, Email, Phone Number, Website URL, or Number field, type @ at the start of the input and pick the calculated field. The respondent can still change the value.
The input takes the first value the calculated field has — usually its initial value, or the hidden field that seeds it. Later changes from logic rules don't replace what is already in the input. To show a value that keeps updating, pipe it into text with an{' '} @ mention instead. See{' '} Default values from other fields for details.
Type @ in any text that supports it (see below). A mention menu appears listing your form's fields grouped by type:{' '} Hidden Fields, Answers, Repeating groups, Calculated Fields, and{' '} Metadata. Pick a field and formbase inserts a variable chip at your cursor.
In the editor, piped values show as a chip (e.g. @First name). When a respondent fills out the form, formbase replaces each chip with their actual answer.
To type a plain @ instead — an email address or a handle — press Esc to close the menu and keep typing. The menu also closes on its own when nothing matches what you typed after the @.
Choice option labels and matrix row and column labels take mentions too, but a narrower menu: only Hidden Fields, Calculated Fields, and Metadata — the values that exist before anyone answers. An option label is how the option reads in the summary, in exports, and in the logic picker, so it cannot depend on another answer.
Button labels and repeating group titles take no mentions. Two related features work differently:{' '} redirect query parameters pick a field from a dropdown for each parameter, and input defaults put a value inside a field instead of in text.
A mention shows a value as text the respondent can't change. To put a value inside a field so the respondent can confirm or edit it, use a field reference as the field's default instead: type @ at the start of a Text Input, Text Area, Email, Phone Number, Website URL, or Number field. That menu lists only Hidden Fields and Calculated Fields, because those have a value before the respondent starts answering. See{' '} Default values from other fields.
That is the technique for a share link, where a value can only arrive through a URL parameter and so needs a hidden field
to land in. On a request you don't need any of it: the caller pre-fills a visible question directly when
they create the request, using prefill, and can mark a key readonly so the recipient sees it but cannot change
it. Build a hidden field when you want to carry data the respondent should never see, not just to pre-fill an answer. See{' '}
Requests don't need a hidden field to pre-fill.
In body text the @ menu lists five groups, in this order:
A field that a chip points at but that no longer exists shows the tooltip "Referenced field was deleted" and renders as empty at fill time. If you delete a hidden or calculated field and add another with the same name, existing chips reconnect to it on their own. Question references never reconnect that way — titles change and collide, so they stay broken until you re-insert them.
Beyond field answers, the Metadata group carries runtime values. Some are available everywhere; others only in email templates. The name below is what the chip reads.
> Drop a 6 Digit PIN into the respondent confirmation email as a reference number. Respondents can quote it in follow-up > conversations, and you can search for it in the submissions table. >
name parameter mapped to the Name question and a{' '}
plan parameter mapped to Plan. The preview shows the URL respondents are sent to:
Repeating groups let respondents add as many entries as they need, so a single reference can pull in more than one value. How the @ mention resolves depends on what you point it at.
In an integration column the whole group appears as numbered, labeled rows instead, so each entry stays readable: "1. Full name: Jane Appleseed, Age: 34, 2. Full name: Marcus Lee, Age: 29".
A mention left pointing at a deleted field is a publish error, not a warning: the issue indicator in the toolbar flags every stale reference — in form content, email templates,{' '} translated emails, and integration message templates — and publishing stops until each one is fixed. Open the flagged location, remove the broken chip, and re-insert the correct field.
> The thank-you screen is the highest-attention moment after a respondent commits. Use it for the next ask: book a call, share the form, > view a confirmation. >
Thank-you page text translates alongside the rest of your form. Open the Translate tab and the thank-you blocks show up under each language — headings, paragraphs, and link labels can all be localized. Piped answers (@ mentions) carry through automatically. See Translating form content for the full workflow.
> Setting a redirect URL turns off Allow another response, and turning that on clears the redirect. If respondents need > to submit several times, use a thank-you page instead. >
> ℹ️ **Embeds with autoClose** >
> An embedded form opened with the autoClose parameter does not redirect —
> the embed closes itself instead.
>
Three options that apply to the form as a whole. Changes are saved with the dialog's Save changes button.
For source language, browser matching, and localized links, see Language setting. For translating questions, options, and descriptions into other languages, see{' '} Translating form content.
Public link access decides who can open and submit the form through its public link. A one-line summary at the top of the tab says who can open it as the switches stand, and whether spam checks run. A request is addressed to one person and opens from a signed link, so it skips these gates.
People sign in before they submit, so each person submits once across devices. Someone who has already submitted is blocked on every device, so this is the strongest way to keep one response per person.
Turn on Password and type one in the field that appears under the switch. People enter it before the form opens. If you leave the switch on without typing a password, publishing warns you and turns the gate off rather than locking everyone out.
A Cloudflare Turnstile check runs before each submission: invisible bot detection that blocks automated submissions, with a quick interactive check in rare cases. It's always on for free forms and can't be turned off; on Pro the switch is yours per form. On a custom domain it uses your workspace Turnstile keys, and the row says so. See{' '} Bot protection (Turnstile) for details.
The Submissions tab covers when the form accepts answers, what happens after someone submits, and how long you keep responses. Rows that only apply to people who arrive through a share link say Public link only; a request already knows its recipient and is completed once.
Three states: Open, Until a date, or Closed. Until a date shows a date picker; the form stops taking answers at the start of that day and shows a "Form closed" message after it. Closed stops new responses right away, and pending requests expire with the form. The row's description always tells you which state the form is in.
Never, On a date, or After a number of days. After deletes each response once it is that old; On a date deletes everything daily once that date passes, including responses that arrive afterwards. Picking one clears the other, and the earliest date you can pick is tomorrow.
Setting or changing a retention rule requires Business. A rule already stored keeps running after a plan change — retention is a promise to your respondents, not a perk — and you can clear it on any plan. See{' '} Submission retention.
One choice of three; picking one clears the others.
Public link only. Shows an "Edit your response" link on the thank-you page. The form reopens pre-filled with their answers, and formbase updates the submission when they resubmit. Pick 1, 2 or 3 edits next to the switch — there is no unlimited.
A form with a Payment, Signature, or Schedule appointment question cannot support editing after submission; publishing warns you and turns the setting off.
> ℹ️ **Pair with the submission confirmation** >> Include the edit link in the submission confirmation email so they can find it later. Set this up in the{' '} > Submission confirmation section below. >
There is nothing to turn on. formbase creates a draft when the respondent answers their first question, saves every change in the background, and restores the progress if they come back. On submit, the draft becomes the completed response.
Where the draft lives depends on your plan — not on who the respondent is:
One list of every email the form sends: New submission alert, Request invitation,{' '} Submission confirmation, and Reminders. Each row shows who receives it and when, with a switch to turn it on or off — the invitation is always on. Click a row to unfold its editor in place: a Write view with the To, Subject and Message fields, and a Preview view that renders the email with sample answers. All of them take a custom subject and body with @ variables.
The line under the tab title names the address every email on this form is sent from — noreply@formbase.so until you pick a
verified domain of your own. One setting covers every email in the list. Domains are managed for the whole workspace — follow{' '}
Use your domain to add and verify one, then any form in the workspace can pick it.
Sends an email to you or your team whenever a response comes in. Leave the subject and body empty and formbase sends its own template.
The default alert to the workspace owner's address works on Free. Adding other recipients, attaching the PDF, or customizing the subject, the body, or the "View Submission" button, requires Pro or Business.
Sends a confirmation to the respondent right after they submit. Pick the email question that holds their address in the{' '} To row; leaving it empty is a publish warning and the confirmation is switched off. If the form asks for no address at all, the confirmation still goes to a request's recipient — public-link responses get none.
One switch, one schedule, two kinds of target: a share-link respondent sitting on an unfinished draft, and a request recipient who has not completed. They get the same email, and the row shows the schedule at a glance.
Sent once, when a request is created with email delivery. Its recipient is set on each request, so you only author the copy, and there is no switch: the row reads Always on. Nothing here affects the public link. See{' '} The request invitation.
Every email above takes the same @ variables. Type @ in the subject or body to open the mention menu. See{' '} Answer piping → Metadata variables for the full reference.
Emails go out in the language the form is shown in. Respondents reading the form in another language get formbase's localized default unless you translate your copy — the note under the list links straight to{' '} Translate emails.
> ℹ️ **Field reference validation** >> If you delete a form field that an email template still references, formbase warns you in the publish indicator before you publish. The > same check covers translated email templates and > integration message templates. >
The remaining two tabs in the settings panel link out to dedicated features:
Each publish creates a snapshot. On Business, formbase keeps the 50 most recent per form and drops the oldest when a new publish passes the cap — but never a snapshot a submission or a live respondent link still points at, so a busy form can hold more than 50.
On Free and Pro, formbase keeps only the newest published version, plus any older version a submission, an open request, or a live respondent link still points at. Older versions are removed the next time the form is published.
Anyone who can edit the form can open the history and browse the versions it holds. Reverting requires the Business plan, and it is the workspace owner's plan that counts: a member on Business cannot revert a form owned by a Free or Pro workspace.
Click the Publish history button (clock icon) in the top toolbar — it appears once the form has been published at least once. The dialog lists your 20 most recent versions, newest first, each with its date, time, and how long ago it was; the live one carries a Live badge. Click Load older versions at the bottom to fetch the rest.
Selecting a version previews it without changing anything. The preview has three tabs: Form, Emails (the owner notification, respondent confirmation, and reminder copy saved in that version), and Translations (the translation bundles it published with).
Pick any version other than the live one and click Revert to this version. A confirmation dialog offers two ways out:
A trashed form cannot be reverted — restore it first.
A revert restores everything the snapshot froze:
Access controls, notification delivery settings and recipients, integrations, and retention rules stay as they are.
> ⚠️ **Reverting replaces your current draft** >> If you have unpublished changes in the editor, reverting overwrites them. Only published versions become snapshots, so publish your > current draft first if you might want it back. >
The issue indicator sits beside the Publish button in the top toolbar. It is a traffic light for the whole form: green with a check mark when nothing is wrong, amber with a triangle when there are warnings, red with a cross when there are errors. Click it to open the list, grouped under Errors and Warnings.
Each entry shows the finding and, underneath it, the action that clears it. Clicking the entry takes you there — into the editor and scrolled to the block, into the right tab of form settings, or into the Translate tab for that language. The list updates as you type, so you never have to press Publish to find out.
For the settings warnings, pressing Publish in that dialog is the one-click fix: formbase applies exactly what each warning says it will do — switching off the password gate, the self-notification, the respondent confirmation, the reminder, or edit-after-submit, or clearing the redirect — and then publishes. Content warnings are never auto-fixed; the form publishes as it is.
Field keys are the names your integrations and requests address — and so are the option, row and column keys under them. See{' '} Field keys for how they are derived and frozen; publish is where the collisions are caught. The publish dialog gathers every key this publish removes, renames or duplicates, at either level, under one heading:{' '} Keys changing in this publish.
requests.create starts rejecting the key.', 'Update the automations that use this key.', ], }, { label: { title: '…“Company” now publishes as “company”. Set its field key back to “company_name” to keep them working.', description: 'Warning', }, cells: [ 'Same warning, with the successor named: the field whose key you retyped, or the single new field standing where the old one was.', 'Set the old field key on this field — the warning clears and the key carries on.', ], }, { label: { title: 'Option key “pro” of “Plan” will no longer exist after this publish. Integrations and requests that use it will stop matching that answer.', description: 'Warning', }, cells: [ 'An option, row or column key the live version publishes is dropped by this one — you deleted the option or retyped its key. A workflow branching onanswers.plan == "pro" stops matching, and a request prefilling pro is refused. When the option still exists the warning names the key it publishes as now.',
'Set the old key back on the option in the Keys table, or update the automations that use it.',
],
},
{
label: { title: 'Two options of “Plan” use the option key “pro”.', description: 'Error' },
cells: [
'Two options of one question — or two rows or two columns of one matrix — were typed onto the same key. Derived keys break their own ties with _2; only keys you set by hand can collide.',
'Give each option its own key.',
],
},
]}
/>
> ℹ️ **Removed keys are your call**
> > Dropping a key is a warning, never an error. If you removed the field on purpose, publish anyway and update the automations that read > it. >
These are the settings warnings, and every one of them is cleared by the dialog's Publish button.
Form copy and email copy are counted separately, so the same language can appear once for each.
These are not issue-indicator entries — they appear as a red notification when you press Publish:
Set the source language under Form language in Form settings → General. This is the language you author the form in and the fallback respondents see when no published translation matches.
Source language controls formbase's built-in respondent UI: buttons, validation messages, progress text, default success messages, default respondent emails, date/time formatting, and number formatting.
> ℹ️ **Source language is not translation** >> Changing source language localizes built-in UI. It does not rewrite your question labels, help text, options, content blocks, custom > thank-you pages, or custom emails. Use Translating form content for custom > content. >
formbase offers 65 languages, and the built-in respondent UI is translated into every one of them. The list runs from Afrikaans, Amharic,
Arabic, Bengali, Bulgarian, Burmese, Catalan, Croatian, Czech and Danish through to Ukrainian, Urdu, Uzbek, Vietnamese, Chinese
(Simplified) and Chinese (Traditional), and it includes the regional variants en-GB, es-MX, fr-CA{' '}
and pt-BR. The picker in Form settings → General is searchable — type a name or a code to find one.
Respondents see the source language unless the form has published translations. Once at least one translation is published, formbase resolves the content language in this order, highest priority first:
> ℹ️ **The language screen** >
> A respondent who arrives with none of the first three — no stored pick, no ?lang=, no share-link default — sees{' '}
> "Pick your language to start" before the questions, whatever their browser prefers. That screen is skipped as soon as
> one of the three is present, which is why a share-link default or a ?lang= link is the shortest path for a campaign.
>
Use ?lang= when you want to send people directly to one language. For example, send French respondents a link ending in{' '}
?lang=fr. If the requested language is not published, formbase falls back to the normal resolution order.
Share-link defaults are useful when one campaign, QR code, embed, or partner link should open in a specific language without forcing that language forever. Respondents can still switch if more published languages are available.
Respondent forms and generated PDFs lay out right-to-left when the active language is written that way — Arabic, Hebrew, Persian, Urdu, and the other RTL scripts in the list. Direction follows the active respondent language, so one form can serve both directions.
en-GB, es-MX,{' '}
fr-CA, and pt-BR.
?lang=xx.
formbase separates the source language from each published translation. Your form content stays authored in the source language. Each translated language stores only the translated fragments for that form: question titles, options, content blocks, placeholders, email copy, and other respondent-facing strings.
Translation rows are tied to stable block ids and source-text hashes. When you edit the source text later, formbase can tell which translations are still current, which are missing, and which need review.
> ℹ️ **Source language does not auto-translate your custom content** >> Setting the source language localizes formbase's built-in UI. It does not rewrite labels, help text, options, custom thank-you content, > or custom emails that you authored. Use the translation editor for those. See{' '} > Language setting for source-language and respondent-language behavior. >
Open a form and click Translate in the toolbar. Pick a language, then translate each row manually or ask AI to draft a suggestion. Each row shows the Original, the Translation, and a status. Two tabs split the work:{' '} Form content and Emails. Changes save as you type.
Click Add language and pick one from the list. Any of the 65 languages formbase supports can be added except the form's
own source language, and each language can be added once. The four regional variants — en-GB, es-MX,{' '}
fr-CA, pt-BR — are separate entries, so pick one when wording, formatting, or legal copy differs by market. See{' '}
supported languages.
> Arabic, Hebrew, Persian, Urdu and the other right-to-left languages can be added like any other. The respondent form and the generated > PDF lay themselves out right-to-left for them. >
Field references stay intact across translations. If an email says Hello @Name, the translation should keep the field mention
and translate only the surrounding text.
Use AI for first drafts, not blind publishing. The translation page offers quick-action chips that change with the state of the language you have open, and each row has its own Suggest / Re-suggest button.
AI writes into the row as a suggestion, not a saved translation. Accept or decline per row, or use Accept all /{' '} Decline all in the toast. Keep product names, legal terms, and glossary terms consistent across rows.
> 💡 **Translate in review-sized batches** >> Translate one language, review the most important pages and email copy, then publish. For high-stakes forms, have a native speaker > review legal text, consent language, and payment-related copy before publishing. >
Above the rows, each language carries a completion badge counting how many rows are complete, missing, and outdated.
The translation editor builds a live source manifest from your current form and email settings. Each manifest row has a stable translation key and a hash of the source fragment. This lets formbase update translation status without guessing from plain text.
Email translations can include @ mentions that pipe respondent answers into the message. If you delete or rename a field that
a translated email still references, formbase flags the stale reference before you publish.
The same reference checks apply to source email templates and integration message templates in{' '} notification settings.
Translations are draft-first. Respondents only see a language after you publish it. Publishing an empty language removes it from the respondent language picker.
Publish after source copy is stable when possible. If you rewrite source copy after translating, use the outdated status to review only rows that changed instead of re-checking every row.
Missing strings fall back to the source language for that specific row. Respondents never see blank labels because one translation entry is empty. This makes it safe to publish incrementally, but mixed-language forms can feel unfinished, so review the completion count before shipping.
Translations carry beyond the on-page form.
> formbase stores the respondent language with the submission. Later emails, PDF generation, and re-renders can use that language even if > you publish new translations later. >
@ mentions after AI translation. They should stay present and in the right sentence position.
?lang=xx before sending localized links.
> Every plan includes the translation editor. AI-assisted suggestions use AI credits — see{' '} > AI credits & usage. >
A Stripe connection belongs to one form: connect it from the form you want to collect money on, and repeat for the next form. Card details never pass through formbase.
The badge on the Payment block tells you where the connection stands:
> ⚠️ **Publishing is blocked until payments are complete** >> A form with a Payment field will not publish until every payment block has a supported currency and an amount at or above that > currency's minimum, and the form has a connected Stripe account with charges enabled. >
formbase uses{' '} Stripe Connect {' '} to link your Stripe account to your form. The charge is created on your account, not ours. In practice:
formbase can see your Stripe account status (whether charges are enabled and onboarding is done) and basic transaction info (payment status, amount, receipt link). It cannot read your Stripe balance, your customer list, or anything outside payments made through your forms.
Pick a currency and type an amount on the Payment block. The amount must be at least Stripe's minimum charge for that currency — $0.50 for USD and EUR, £0.30 for GBP, ¥50 for JPY, 3 kr for SEK and NOK. Stripe caps a single charge just under 1,000,000, so keep amounts below that.
Supported currencies: USD, EUR, GBP, JPY, CAD, AUD, CHF, SEK, NOK, DKK, NZD, SGD, HKD, AED, TRY.
The Payment field takes one-time charges only. Recurring subscriptions are not part of it.
You can vary the amount from the respondent's answers. Add a Set payment amount action to a logic rule above your Payment field and point it at the block.
Each action picks how it changes the price — set to, increase by, or decrease by:
The value itself can be:
Rules run in the order they appear in the form, starting from the price on the block. A later set to overwrites whatever earlier rules produced, so put your most specific rule last.
Example: a ticket form has a Dropdown ("Standard" or "VIP") and a Number field for quantity. A calculated field multiplies the base price by quantity. A logic rule targets the Payment field: if the Dropdown is "VIP", set the payment amount to the calculated field.
Add-on example: a $50 price on the block, a "Rush delivery" switch that increases the amount by 15, and a "Member" switch that decreases it by 5. With both on, the respondent pays $60.
> 💡 **The block price is the fallback** >> The price you set on the Payment block is what respondents see before any rule fires. Make it your most common price so the form never > shows a placeholder amount. >
The respondent clicks Complete Payment on the card and Stripe Checkout opens, hosted by Stripe. After paying they return to the form to finish and submit. The amount charged is recomputed on the server from your own rules — a tampered client cannot change the price.
If the payment fails (expired card, insufficient funds), the card shows the error and a Retry payment button that reopens Checkout.
Once a respondent has paid, formbase locks the questions that fed the amount — the conditions and values of any rule that set it, the fields behind a referenced calculated field, and anything that controls whether the Payment block is visible. Locked questions show their answers read-only with "Locked because this answer was used for a completed payment." The rest of the form stays editable.
> ⚠️ **A payment makes the submission final** >> Any form version containing a Payment, Signature, or Schedule appointment field turns off{' '} > edit after submit for submissions made against it. >
Payments show up with the response in the Submissions tab:
The payment also goes out with the submission: notification emails, the PDF, exports, webhooks, Zapier, n8n, Make, request callbacks and the API all carry its amount, currency, status and receipt link under the Payment question. See{' '} Bookings and payments for the shape.
Payments land in your Stripe account, so you handle refunds and disputes yourself. formbase reserves the right to issue refunds on your behalf in cases of abuse or policy violations. When Stripe reports a refund or a dispute, the payment on the submission changes to{' '} Refunded, Partially refunded or Disputed; integrations are not sent again.
Stripe's own documentation covers both in depth:
A Payment field can also be read by logic: amount equals, amount is greater than,{' '} amount is less than, is completed, and is not completed. See{' '} Conditional logic for the full operator reference.
When a respondent presses submit, formbase asks Turnstile for a token and verifies it on the server before the submission is written. The check normally runs silently; if it cannot resolve on its own, a small dialog appears and asks the respondent to confirm. There are no image puzzles. The dialog follows your form's theme and language.
The check runs on the submit, not on page load, so it never delays the form opening. A submission that fails verification is rejected and the respondent is asked to try again.
> ℹ️ **Requests are not gated** >> Bot protection applies to share links only. A{' '} > request link already names one recipient and authorises one completion, so it skips Turnstile — as it > skips the sign-in requirement and response limits. >
For forms shared on form.formbase.so links, bot protection is built in — no setup, no keys, nothing to configure. formbase
manages Turnstile for you.
On the Free plan (and for guest forms), bot protection is always on and can't be turned off. The{' '} Bot protection (Turnstile) switch under Form settings → Access stays locked on.
On a Pro or Business plan, the switch is yours. Turn bot protection on or off per form from{' '} Form settings → Access → Bot protection (Turnstile).
If your paid plan lapses, your own setting keeps applying for the first 30 days. From day 30 bot protection locks back on — the Free-plan default. See upgrading & downgrading.
Custom domains require a Pro or Business plan. If you share forms on a custom domain (for example{' '}
fill.yourdomain.com), you bring your own Turnstile keys (BYOK): Cloudflare ties a Turnstile widget to specific hostnames, and
formbase's own key only covers formbase.so.
Until the keys are saved, the switch on a custom-domain form is disabled and shows as off, because no challenge can run there. What happens to submissions on that branded URL depends on the plan:
> ℹ️ **No custom domains? Skip this.** >If all your forms use the default formbase share links, you do not need Turnstile keys. Bot protection works automatically.
Turnstile does not change your monthly allowance — 1,000 submissions a month on Free, 50,000 on Pro and Business. See{' '} limits & quotas.
Turnstile is one layer. Combine it with the access controls in Form settings → Access:
> ⚠️ **No protection is perfect** >> Sophisticated bots can bypass any CAPTCHA. For high-value forms, layer defenses: Turnstile, an authentication gate,{' '} > email verification, and a look at the submissions before you act on them. >