Publish an app to the web

Some apps are for your team; some are for the world — a product catalog your customers browse, an event agenda on attendees' phones, a price list you text to a client. Publishing gives an app a public, read-only web page without anyone needing an account.

Publish an app

You'll see the Publish card if you're an owner of the app and your plan includes published apps.

1. Open the app and go to its Settings page. 2. In the Publish to the web card, flip the switch. 3. Copy the link, share it, or point a phone camera at the QR code.

The public page shows the app's records — as a list or image-led tiles — a record's details, and its dashboards, in the app's own design. It works well on phones — readers get image tiles first. They can search and browse, but never change anything. Sensitive fields stay masked, exactly as they are for a viewer in your workspace.

How the page looks

The public page shows the app the way you see it. Your Display settings for this app — dark or light mode, brand colour, text size, layout density, design style, and whether records open as a list or as tiles — all travel with the page, so a reader opening the link sees the app you styled, not a generic one. Change a setting any time and the page follows within a minute.

Two things deliberately stay behind: your interface language (the page speaks the app's own languages) and settings that are personal chrome rather than the app's look. If several people own the app, the page follows whoever last touched the Publish card.

On a phone the navigation moves to a bottom tab bar: each form gets its own tab — with four or more forms, the first two plus a More menu — followed by the dashboard and Submit when the app has them. Records open as image-friendly tiles there; readers can still switch to the table view. On a desktop those tabs sit in the header instead.

Group records for browsing

A catalog reads better by category; an event agenda reads better by day. In the Publish card, pick a field under Group records by for any form, and the public page shows that form's records under group headings — in list and tile view alike.

Grouping is optional and set per form, so a two-form app can group its catalog by category and leave its price list ungrouped. Records with no value in the field gather under their own heading, and a reader who sorts by a different column flattens the groups until they sort back.

Choose exactly what the public sees

By default the public page shows what a workspace viewer sees. If a form carries fields the public shouldn't browse — a cost price beside the selling price, a supplier name — mark the fields you do want public in the Rules sheet, and the public page then shows only those:

One rule per field, no value needed. As soon as any field of a form is marked, everything unmarked disappears from the public page — it isn't just hidden in the browser; it never leaves Sheetward's servers. One side effect: search is switched off on a narrowed form, so nobody can probe hidden values through it. Nothing changes for your team inside the workspace.

Accept submissions from the public

A published app can also take input — an RSVP, an inquiry, a request form — without giving anyone an account. In the Publish card, pick a form under Public submissions and the public page gains a Submit tab.

Submissions are checked against the form's rules exactly like any record — required fields, formats, dropdown values — and land in your records list with public@intake as their creator, so you always know which rows came from outside. Submitters see only a thank-you note (plus a reference number when the form assigns one automatically); they can never browse, edit, or see other submissions. Sheetward limits how fast — and how many — submissions the page accepts in a day, and when bot protection is turned on, submitters pass a quick automated check before their entry goes through.

Manage the link

• New link replaces the address. Every previously shared copy stops working — within a minute at the outside — so use it if a link ends up somewhere it shouldn't.
• Unpublish takes the page down just as fast. Publishing again later creates a fresh link.
• The link is deliberately unguessable, and public pages ask search engines not to index them: the audience is whoever you hand the link to.

What can't be published

An app using the approval workflow or restricted record visibility can't be published, and an app marked sensitive stays private too — those features exist to control who sees each record, and a public page can't honour that. The Publish switch explains this and names the setting to change if you want the app public after all.