Pages & cards

In one line. Purpose-built screens without code: compose pages from cards in the experience designer, bundle them into packs, and let structured data render itself. Where this lives. Studio ▸ Experience ▸ Pages (designer), Studio ▸ Experience ▸ Packs, and Studio ▸ Experience ▸ Cards (the card library); rendered pages serve under the /x route tree.

Why pages exist

The workspace, chat and dashboards cover most operations out of the box. Pages are for the screens that are yours: a lending review workbench, a vendor scorecard, a landing page for one team’s slice of the work. Instead of waiting for custom UI development, you compose them.

The v2 experience renderer ships as a release flag (experienceRenderer, default on; off is the kill-switch). Packs have their own flag layered on top.

Cards — the unit of composition

A page is a layout of cards. Each card binds to platform data and renders it appropriately:

• Document cards — the document workbench family: cards that surface a document’s fields, summary, and actions on the document page itself, so a reviewer’s working view carries exactly the panels their process needs. The native summary-pane card supports the full review loop — inline edit, comments, formula fields — and takes a card-level skin so the same pane can be restyled per solution.
• Structured cards — point one at a Structured collection and it reads the schema and infers the right presentation: a few records with images become tiles, records with a dominant text field become rows, wide records become a table. You choose the collection; the card works out the shape.
• Chart and metric cards — counts and breakdowns over collections, the same data dashboards draw from.

The design principle across all of them: cards bind to the domain model, not to copies of it. A card shows the same records, fields and lifecycle stages the rest of the platform sees, live.

The card library

Studio ▸ Experience ▸ Cards is the browsable catalog of every card — ~44 cards in 7 categories, searchable, each with when-to-use guidance, a placement wireframe, its data lineage and configuration, and a Use this card jump straight into the Pages designer. It’s the same catalog the designer’s palette draws from, so it can never drift; start here when you’re not sure which card fits.

The designer

Studio ▸ Experience ▸ Pages is a no-code editor: add cards, arrange the layout, bind each card to its collection or view, preview, publish. Cards that take a skin get a skin gallery in the designer — click a skin for a live preview. Published pages render for consumers under /x/... — fast, native, and themed to your workspace branding (E7). On pages with side-by-side panes, the gap between panes is a draggable resizer: each user’s widths persist across visits, and a double-click resets to the authored layout.

Packs — pages that know each other

A single page is a screen; a pack is a journey. Studio ▸ Experience ▸ Packs bundles a curated set of pages and connects them — a click on a record in one page opens the detail page for it — then lets you walk the whole journey in a Try it preview before you hand it to users.

Use a pack when a team’s workflow spans screens: a queue page, a detail workbench, a summary dashboard, connected in the order the work actually flows.

When to use what

You need	Reach for
Browse and act on documents	The workspace — it’s already built
Numbers over everything	Dashboards
A screen shaped like one team’s process	A page of cards
A connected multi-screen journey	A pack
The same thing outside the app shell	Embed & share

Where to go next

• Branding and layout for what you build: E7 · Shaping the experience.
• The structured collections cards love: D2 · Collection types.
• Shipping an experience to another workspace: V4 · Hubs & distribution.