Not every interaction happens behind a login. A prospective customer fills in a lead form on a website. An applicant submits a job application through a public posting. A partner consults a status dashboard to see whether their orders are processing on schedule. The general public browses a product catalog or a knowledge base. These are all real workflows, and they all have the same awkward shape if you're running a business platform: the data lives in the internal system, but the interaction happens outside it. The naive solution is to build a separate public-facing application, duplicate the data model, hand-write the integrations between the two, and spend the rest of eternity keeping them in sync. The better solution is to let the same platform serve public-facing pages, with appropriate controls on what's exposed and how.
Public canvas pages are the headline capability. Any canvas page can be marked public, at which point it becomes reachable at a stable URL without authentication. The content of the page still follows the canvas page's bindings and dynamic areas, but it renders for anonymous visitors instead of signed-in users. That means public pages get the full expressive range of the canvas builder — layouts, blocks, conditional rendering, computed values, iterators — without requiring a separate authoring tool.
Public forms are the companion for the write side. A canvas page published to the public can include a form that creates records in the internal system: a lead form that creates Lead records, an application form that creates Applicant records, a registration form that creates Member records. The form is built with the same form builder the internal application uses, with the same validation rules, the same conditional visibility, the same field types. The records it creates land in the same tables internal staff work with. There's no separate "public data" schema to maintain; the public form is a front door into the existing data model.
Public queries and views cover the read side for more structured data exposure. A query that's marked public can power a view that's available to anonymous visitors — a catalog listing, an event calendar, a status page, a leaderboard. The query's access rules determine what's visible; sensitive data is filtered out at the query level rather than hoping the public page happens not to show it. That separation of concerns is important: the data model declares what's safe to expose, and the public page uses only what the data model has approved.
Per-tenant domain keeps public pages on URLs that feel like part of the tenant's own web presence. A public page on a tenant's portal-style subdomain looks like a normal web page from the tenant's organization; the visitor doesn't see a generic platform URL or a shared domain that belongs to someone else. For customer-facing workflows where the public page is meant to feel like an extension of the tenant's website, this domain integration is what keeps the experience seamless.
Rate limiting on public endpoints is the first line of protection against abuse. A public form that accepts submissions from anonymous visitors is also, by definition, a public form that can be hammered by automated traffic. The platform's rate-limiting machinery — covered in more depth in the API protection article — applies to public endpoints with its own policies, so a burst of submissions from one source gets throttled before it becomes a problem. Legitimate visitors never notice; abusive traffic gets blocked.
Anti-spam heuristics handle the shape of abuse that rate limits alone don't catch. Hidden honeypot fields trap bots that fill in everything they see. Time-based heuristics flag submissions that arrive impossibly fast — a human couldn't type a full form in two seconds, but a bot can. Submission patterns that look automated get filtered out before creating internal records. These controls apply by default to every public form, which means implementers don't have to wire up separate anti-spam for each new public-facing surface they build. The whole layer is there, protecting all public forms consistently.
Public file access uses signed URLs for cases where a file should be shared with an anonymous visitor without making it generically public. A confirmation email after a public form submission might include a link to a receipt PDF; that link is a signed URL, valid for a limited window, accessible without authentication but not broadly indexable. For the "share a specific thing with a specific anonymous person for a limited time" pattern, signed URLs are exactly the right shape.
Caching is applied to public pages where the content allows. A catalog page whose contents change only when the catalog itself is updated can be served from cache for subsequent visitors, which keeps response times fast even under significant traffic. A status page whose contents change frequently has a shorter cache lifetime or is served fresh each time. The caching rules are configured per page and respect the content's actual update frequency, so the public pages stay fast without ever showing stale data beyond the configured freshness window.
Transitions from anonymous to authenticated are the feature that closes the loop between public workflows and internal ones. A public form submission can trigger an automation that creates an invitation for the submitter, turning an anonymous lead into a signed-in user in one motion. A public registration form can automatically create an account for the new member. A public inquiry can generate a magic-link that lets the inquirer check their status in the internal portal. The public side and the authenticated side aren't separate worlds; they're connected surfaces of the same platform, and moving a visitor from one to the other is a built-in capability rather than a custom integration.
For tenants running customer-facing workflows, partner portals, or any interaction that doesn't belong behind the company firewall, public pages are often the feature that eliminates a whole separate web-development project. The same canvas page builder, the same form builder, the same query system, the same data model — just with the access control set to "public" instead of "authenticated." For the adjacent topics, the canvas page builder article covers the authoring surface, the REST API article covers programmatic access from partner integrations, the file uploads article covers how visitor-submitted files are handled, and the API protection article covers the rate-limiting machinery in detail.