> For the complete documentation index, see [llms.txt](https://guides.noloco.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.noloco.io/nola/canvas.md). # Canvas A **Canvas** is custom, Nola-built functionality you can add to your app, just by describing what you want. When a standard [view](/pages/views.md), [record page](/record-pages/overview.md), or [dashboard](/pages/blank-pages.md) can't quite express the layout or interaction you have in mind, you can ask Nola for a Canvas instead. A Canvas comes in two forms: * A **Canvas page** — a full, standalone custom page. * A [**Canvas component**](/nola/canvas/canvas-components.md) — a custom section you add to an existing record page or blank page, to give a standard page a bit of dynamic functionality. Behind the scenes Nola writes and maintains the code for a Canvas, but you never see files, terminals, or build tooling. You describe what you want in plain language, watch it build, and refine it by chatting — exactly like every other conversation with Nola. **The speed and flexibility of AI, with the reliability of Noloco.** No code required, and nothing to rebuild — a Canvas is built on the data, permissions, and processes you already manage in your app, so it feels like a natural part of it from the moment it's created. {% hint style="info" %} A Canvas is generated and edited entirely through Nola. There's nothing to install and no code for you to manage — Nola owns the code, you own the outcome. {% endhint %} ## See it in action {% @arcade/embed url="" flowId="yrDwUAYoTdpxKtXy88hv" %} ## When to use a Canvas Noloco's standard no-code pages are the right choice most of the time, and they stay the fastest way to build the common patterns. Reach for a Canvas when you want something that config alone doesn't cover, such as: * A **custom dashboard** that combines stats, charts, and summaries in a bespoke layout * A **landing or overview page** with a designed, marketing-style structure * A **portal home** that mixes several data sources and call-to-action sections * A **mini-tool or calculator** — a small interactive utility like a link generator, proposal builder, or payment calculator * An **interactive view** with a layout or behaviour that goes beyond the built-in [display types](/views/display.md) Think of a Canvas as the "escape hatch" for the times when you'd otherwise wish you could hand a designer a sketch. You get the freedom of a custom build with the speed of describing it to Nola. ## What a Canvas can reuse Nola doesn't rebuild things Noloco already does well. When she generates a Canvas, she draws on the platform you already have: * **Your data** — Nola reads your [tables](/data/collections.md), fields, and [relationships](/data/collections/relationships.md) and fetches live records for the page * **Charts and visualizations** — bring your data to life with [charts](/views/display/charts.md) and custom visual summaries * **Your app's look and feel** — a Canvas inherits your app's [theme](/settings/theme-and-design.md), navigation, and chrome, so it feels native * **Your permissions** — a Canvas respects the same [user roles, spaces, and visibility rules](/nola/canvas/configuring-canvases.md) as any other page This means a Canvas slots into your app like a page you built by hand — same navigation, same access control, same styling. {% hint style="warning" %} **Not available in a Canvas yet.** Some of Noloco's most advanced components — [Kanban boards](/views/display/kanban-boards.md), [timelines](/views/display/timeline.md), and the [data grid](/views/display/tables.md) — aren't available inside a Canvas for now. If you need one of those, use a standard [view](/pages/views.md) instead. A Canvas also can't bring in third-party tools or libraries that Noloco doesn't already support. {% endhint %} ## How a Canvas fits alongside no-code pages A Canvas doesn't replace Noloco's no-code builder — it sits next to it. A single app can freely mix standard pages and Canvases. Nola will often suggest the standard, config-first approach first, and use a Canvas only when it's genuinely the better fit. You don't have to choose one or the other for a whole page, either: with a [Canvas component](/nola/canvas/canvas-components.md) you can keep a standard record page or blank page and drop a custom, dynamic section into just the part that needs it. {% hint style="success" %} **A good rule of thumb:** start with a standard page. If you find yourself fighting the layout to get a bespoke result, ask Nola to build it as a Canvas — a whole [Canvas page](/nola/canvas.md), or a single [Canvas component](/nola/canvas/canvas-components.md) on the page you already have. {% endhint %} ## Get started {% content-ref url="/pages/0R2msA13l8bSqOalCJKN" %} [Creating a Canvas](/nola/canvas/creating-canvases.md) {% endcontent-ref %} {% content-ref url="/pages/DZBcSGZN9soOyDFbboga" %} [Canvas components](/nola/canvas/canvas-components.md) {% endcontent-ref %} {% content-ref url="/pages/T3oRwEaHeuXCakVTGeqb" %} [Editing a Canvas](/nola/canvas/editing-canvases.md) {% endcontent-ref %} {% content-ref url="/pages/tPyvzlaISWStg0LRdl0O" %} [Configuring a Canvas](/nola/canvas/configuring-canvases.md) {% endcontent-ref %} {% content-ref url="/pages/XO0diqL1H6pd9QAcnv4n" %} [Troubleshooting a Canvas](/nola/canvas/troubleshooting-canvases.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guides.noloco.io/nola/canvas.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.