The form builder covers the common case elegantly: a form that maps to a single record on a single type, generating a clean create-or-edit experience from the type's properties. That's what ninety percent of day-to-day forms look like. The other ten percent don't quite fit. A multi-step onboarding wizard that writes to several types along the way. A survey that collects opinions without creating a permanent record. A contact form on a public marketing page. A loan calculator that computes a quote without persisting anything. A feedback form that combines record properties with free-standing input fields. Canvas forms are how these get built.
A canvas form is a block you drop into a canvas page. Like any other canvas block, it lives inside the page's layout — alongside text, images, tabs, tables, iterators — and can be placed, sized, and styled to fit the surrounding design. Unlike a regular form, it isn't tied to a single type's properties. It can combine fields drawn from any number of types with custom canvas-only input fields that don't correspond to any property on any record. That mix is what makes canvas forms flexible enough to handle the cases the object-bound form builder can't.
Custom layouts are the default expectation inside the block. Fields can be arranged manually — side by side, in groups, with inline labels, with custom spacing — rather than being constrained to the sequential flow of the standard form. For forms that are the centerpiece of a page (onboarding wizards, calculators, public submissions), that freedom is what lets the form look like it was designed for the page rather than dropped into it.
Canvas forms carry context from the page they live in. If the canvas page is opened for a specific customer, the form knows about that customer and can default its fields accordingly. If the form is inside an iterator, each iteration's item is available. If parameters were passed through the URL, they're available too. Bindings happen through the same expression language used everywhere else, so the context reaches the form the same way it reaches everything else on the page.
Context plays two roles. A form can inherit from an object — defaulting its fields to the object's current values, submitting updates back to it when the user saves. That's how a canvas form serves as a richly-designed edit page. Or the form can operate without an object, collecting input that an automation will process on submit. That's how a canvas form becomes a wizard, a survey, a calculator, or a submission form. The same block, bound differently.
Validation rules are inherited from the underlying property types where applicable — a field bound to a date property brings its calendar validation along automatically — and canvas-only fields can define their own rules: min, max, length, regex. The same server-side re-validation that protects standard forms applies here. What the form accepts is what the handler receives, with no client-only trust.
Event hooks are what turn a form from a passive input device into a piece of application logic. Before render lets you prepare context or compute defaults. Before validate lets you transform input before the rules run. After submit is where most of the work usually happens — this is where automations fire to create or update records, send notifications, publish webhooks, or do anything else the submission implies. On abort cleans up when the user cancels. The hook set is deliberate: enough to cover the common application-form patterns without turning the form into a pile of ad-hoc scripts.
Flash messages and redirects close the loop after a successful submit. A flash message ("Thanks — your submission was received") shows on the next page the user sees. A redirect sends them to a thank-you page, a confirmation page, or back to where they came from. For public-facing forms that drop submissions into the tenant, the combination of flash and redirect is what makes the form feel like a normal public page rather than a weird detour into the application.
Elevated permissions handle the important case of forms that let users do something they couldn't otherwise. A public contact form run by an anonymous user typically doesn't have write access to the tenant's types. Rather than opening up those permissions to anonymous users in general — which would be a broad, permanent grant — the form can be configured to run with elevated permissions only at the moment of submission, only for exactly the actions the form specifies. That scopes the privilege tightly: anonymous visitors can submit the form and the submission creates the right records, but those visitors cannot otherwise read or write anything in the tenant. It's the principle-of-least-privilege applied at the form level.
Dynamic option loading is the feature that makes complex forms feel alive. Selecting a country populates the list of states. Selecting a product category populates the list of available products. Selecting an organization populates the list of contacts at that organization. Option lists are loaded on demand as user input changes, so forms stay snappy even when the underlying lists are large.
Modal presentations let canvas forms open as dialogs rather than inline. For actions that interrupt the current task briefly — a quick edit, a confirmation, a small multi-field input — a modal form is often the right shape. The same canvas form definition works inline or modal; the presentation choice is a block-level setting, not a separate form to build.
Replicator support covers the repeating-group pattern within a canvas form. A form that needs to collect a variable number of line items, attachments, or contacts uses a replicator — the user adds and removes rows as they work. The repeating sections article covers the pattern in more detail; the relevant point here is that canvas forms participate naturally.
Abort support closes a loop that matters for complex handlers. A form submission can be aborted cleanly from inside a handler — say, because a validation check against an external system fails — and the user stays on the form with a helpful message rather than being thrown to an error page. That's the kind of detail that separates a form you can deploy publicly from one you can only use internally.
The combination of canvas forms, the automation builder, public pages, and elevated permissions is what makes the platform capable of running customer-facing flows without a separate front-end framework. A public lead form, a customer portal, a registration flow, a self-service scheduling tool — all of them are canvas forms with handlers, running inside the same tenant the back-office uses. That consistency is the real win: one data model, one permission system, one audit trail, and user-facing pages that read and write against the same data the internal team works with.