The default views — table, kanban, calendar, list — cover most day-to-day work. Most of what users do in the application is look at records, edit records, and move records through states, and the default views are designed for exactly that. But every real implementation has pages that don't fit the mold. A landing dashboard that summarizes the state of the business. A customer portal that shows a tailored slice of the platform to external users. A printable invoice that has to follow strict branding. A multi-step onboarding wizard. A report layout that combines charts, tables, and narrative text. Building those by hand means writing templates, which means touching code, which means a developer. Canvas lets implementers compose them visually.
A canvas page is a tree of blocks. The palette covers the obvious building materials — text, images, dividers, buttons, links, tabs — and extends into the data-aware ones that make canvas more than a page layout tool: form blocks that render a form for an object, table blocks that render a view of a query, iterator blocks that repeat a child structure over a list. Blocks can nest freely — a tab contains a table, the table contains an iterator, the iterator contains a card layout of its own — so the tree of blocks on a page matches the structure of the content the page is trying to express.
Each block can be bound to a data context: a specific query, a specific object, a variable that was passed in. That binding is what makes the page aware of its own data. A table block bound to a high-value open deals query stays synchronized with that query; edits to the query propagate to every page that renders it. An iterator over the current customer's orders walks through the orders when the page is opened for that customer. Bindings are expressed the same way filters and expressions are expressed elsewhere in the platform, so the skill transfers.
Conditional rendering lets blocks appear or disappear based on expressions. The "overdue balance" warning panel only shows when the customer's balance is actually overdue. The "upgrade" call-to-action only shows for customers on the starter plan. The internal notes section only shows for users in the support role. Conditions are evaluated at render time and re-evaluated as the page's context changes, so the layout stays honest about what the current user and the current data warrant.
Dynamic areas are the feature that turns static pages into interactive ones. A dynamic area is a zone that re-renders automatically when its inputs change or when an external event fires. A filter control at the top of a dashboard triggers a re-render of the charts below it, without a full page reload. A button that runs an automation updates the record and the surrounding panels reflect the change immediately. For pages where interactivity is the point, dynamic areas are the mechanism behind it.
Iterators do the heavy lifting when a page has repeated structure. An iterator bound to a query renders its inner blocks once per record — which is how product catalogs, portfolio grids, team-member directories, and any other "list of things in a nice layout" page gets built. Iterators can bind to queries, to list variables, or to streamed JSON responses from external systems, which covers both tenant data and live data from integrations.
Input parameters let a canvas page behave like a function. A page can accept parameters from the URL, from a form submission, from the caller that opened it. The page's bindings and conditions reference those parameters the way an automation references its arguments. That means the same canvas page can serve as a generic template for many contexts: a customer-detail page parameterized by customer ID, a campaign report parameterized by date range, a portal landing page parameterized by the current external user's organization.
Action bindings on buttons and links close the loop between display and behavior. A button on a canvas page can trigger an automation — with the page's current context handed to the automation as arguments — or navigate to another URL, or submit a form, or perform any of the actions the automation builder exposes. That's what turns canvas from a read-only display surface into a working application page: users interact with what they're looking at, and the platform responds by running the automations that implement the tenant's business logic.
Sandboxed custom HTML is the escape hatch for the cases where the built-in blocks don't quite cover what a page needs. The same rich-text allow-list that governs sanitization elsewhere governs custom HTML too, so what's allowed in one place is allowed in another — and nothing unsafe slips through. Style and script custom headers on the page level let implementers add page-specific CSS and JavaScript for truly bespoke presentation, within the platform's security model.
Small ergonomic touches make day-to-day authoring reasonable. Copy and paste of blocks (including entire nested subtrees) speeds up iterative work — lay out one card, copy it, and use the copy as the starting point for the next. Dark-mode awareness ensures blocks render correctly in both themes without per-block configuration. Template inheritance allows a base layout to define the shared shell of many pages, with individual pages overriding only the parts they need to change.
There's a reasonable question about when to reach for canvas and when the existing view layouts are enough. The rough guideline: if you want the data of an existing view with a custom frame around it — a button bar, a filter strip, some extra content — view layouts are the lighter-weight tool. If you want a page that composes multiple pieces of content into something bespoke, canvas is the right answer. The two tools can coexist on the same tenant; the choice is about the right amount of ceremony for the page you're building, not about committing to one path forever.
Canvas forms — the form-building side of the same builder — have their own article, because they deserve the attention. Homepage widgets (the smaller canvas snippets that live on the dashboard) also have their own. Together with the expression language and automations, canvas is what lets an implementation go all the way from "track these things" to "here's a custom portal for our customers" without a code base on the side. That's the whole promise of the platform, and canvas is one of the places it becomes most visible.