Forms: let anyone add a record, without an account

A public view link lets someone read one view. A form is the other direction: a page anyone can open, with no account, where filling it in creates one record in one of your tables.

Bookings from a website, a sign-up sheet, a repair request, a supplier's details — the intake half of most real work starts with somebody who will never have a login typing into a box.

Making one

Open a database, go to Forms, choose Add form, and pick the table it should write to. The form arrives working, with the first few of the table's fields already on it — a handful rather than all of them, because adding the three you want is less work than dismissing the twelve you don't. The rest are waiting under Add a question.

The builder is split in two, and the split is the point. On the left is what a visitor will see; on the right is the door.

• Questions — drag them by the handle to reorder (or use the arrows, or focus a handle and press ↑/↓). Each one shows its field type, and can be required, can carry a different label than the field's real name, and can have a line of help text under it. Remove one with ×; add it back from the tray underneath.
• Title and description — what a visitor reads above the questions.
• The link, and whether it's open — copy the link, or open it to see exactly what a visitor sees. There is no separate preview, because the real page is one click away and a preview that drifts from it would be worse than none.
• After submitting — the message shown once the record is in. Defaults to "Received."
• Brand — a logo above the title, a cover image across the top, and the form's colour. Images save the moment you pick one. The colour starts as your database's and keeps following it unless you choose otherwise, so changing the database's colour still reaches every form that never opted out.
• Name — internal, so your team can tell two forms apart. Deleting the form lives here too.

Owners and editors can build forms. Viewers don't see the tab at all — same as webhooks, and for the same reason: both are the wiring a database is built with rather than the data it holds.

Which fields can go on a form

Text and long text, numbers, currency and percent, dates, checkboxes, single and multi select, email, phone and URL.

Everything else is absent from the builder rather than shown and disabled:

• Formulas, lookups and rollups compute themselves. There is nothing to type in, and they fill in on their own once the record exists.
• Attachments would mean public uploads onto your storage. Not yet.
• Linked records would mean showing a stranger a picker full of your other records. That one waits for field-level permissions.

If a field on a form is later converted into something a form can't accept, the page quietly drops that one question and keeps serving the rest.

What a visitor can see

Only the form. The page carries its title, description, the questions you chose and their help text, and — for select fields — the choice names and their colors. It also carries whatever you put in Brand: a logo above the title, a cover across the top, and a colour. That is the whole of what it borrows: the page does not carry the database's name, the table's name, any field you didn't put on the form, your member list, or a single existing record. You can check this yourself: open the form and view the page source.

Questions look the way they do inside the database: a select opens Tabla's own list of coloured chips rather than the browser's grey box, and a date opens the same calendar the grid uses. Nothing on the page is left to the operating system's own widgets.

It is built for a phone, because that is where most people answer one. Below a phone's width the card gives up its frame and the questions take the full screen, and every control is sized for a thumb.

Arabic works throughout — an Arabic title, Arabic questions, Arabic choices and Arabic answers, each line finding its own direction, so a form that mixes a name in Arabic with an email address renders both correctly.

Where submissions go

Into the table, as ordinary records. There is no separate submissions inbox, and that is the design rather than an omission: a submission is a record. It appears in the grid, opens in the record panel, can be filtered, exported, edited, deleted and restored from trash exactly like a row somebody typed.

Which also means the things that already watch your tables watch forms for free. A record_created webhook fires on every submission with the standard payload, so an email on each new response is a two-minute Make or n8n scenario. Tabla doesn't send that email itself — the tools built for it do it better, and routing it through them means one place to change when the recipient changes.

Fields you left off the form still get their defaults, exactly as they would had the record come in over the API. The record's activity feed opens with Created via and the form's name, so a row that arrived through the public door is never mistaken for one somebody on your team typed.

Pausing, and turning it off

The Accepting submissions switch closes a form without destroying it: the page still loads and says "This form is closed." A visitor who bookmarked it learns the form is shut rather than that they mistyped the address.

Deleting the form's table switches off every form on it in the same motion. For the seven days the table spends in the trash the forms are off this list and their URLs stop resolving — a visitor gets a plain not-found, not "This form is closed", because nobody chose to close them. Restoring the table brings back exactly the ones the delete switched off; a form you had paused yourself stays paused.

Deleting a form is how you truly revoke the link — the URL stops working immediately. Records it already created are untouched: deleting the door does nothing to what came through it. Their history still records that they arrived through a form, though the name goes with the form — those lines read "Created via a form" once there is no name left to print.

Keeping spam out

A public write endpoint attracts robots. Several things run before a submission is ever accepted:

• Rate limits, per form: a cap per minute from any one address, and a daily ceiling. They're counted per form, so one busy form never closes another's door.
• A hidden field no person can see or tab into. Anything that fills it in gets a normal-looking thank-you and no record.
• A minimum fill time. A submission that arrives faster than a human could have read the page is treated the same way.
• A size cap on the submission itself, and no file uploads at all.

Anything that gets past all of that arrives as a plain record — so clearing it is selecting rows and deleting them, and they sweep through the seven-day trash like anything else.

What forms don't do yet

One page, one table, one record per submission. No conditional questions yet — when they come, they'll speak the same condition language filters already use, rather than a second one to learn. No multi-page flows, no redirect to your own URL, and no custom fonts.