Shaping the experience

In one line. Studio ▸ Experience — the pillar where you configure exactly what your end-users see in the consumer app. You’ll be able to. Brand the runtime, design the pages your users land on, set the chat’s default questions and behaviour, tune search, and define the saved Views your users switch between. Where this lives. Studio ▸ Experience — Setup (General, Appearance), Designer (Pages, Packs, Cards), Channels (Search, Chat). Views live under Studio ▸ Data ▸ Views.

Why it matters

The builder pages before this one taught you to define the work — collections, agents, pipelines. This page is the other half: shaping what the people doing the work actually see. The same project can feel like a polished invoice cockpit or an unbranded data dump depending on this pillar; a builder who skips it ships a working-but-confusing app.

The mental model is simple: you configure here; your users consume there. A saved View is the dropdown your reviewers pick from in The document workspace. A chat Default Question is the clickable starter in Chat & search. A page you compose under Designer is the screen your users land on (Pages & cards). You’ll want Core concepts and a project with at least one collection (Collections & schema) before working through this.

The Experience pillar

Experience is one of Studio’s four pillars — Agents, Data, Experience, Governance — named across the top of Studio. Clicking Experience lands you on General. The list beneath it is broken into three sections by small, non-clickable headings:

Studio ▸ Experience
  Setup       General        the project's basic settings
              Appearance     branding, theme, and how the runtime is laid out
  Designer    Pages          compose a screen from cards
              Packs          bundle pages into one journey
              Cards          browse the card library
  Channels    Search         how search behaves for end-users
              Chat           how chat behaves for end-users

Watch out. If a teammate can’t see a tab or an entry, it is usually the access they hold rather than a fault. Check Studio ▸ Governance ▸ Users & Access — the People view for their access, the Personas view for the project’s own workflow roles (Access & roles). A small red dot on a tab label means unsaved changes; navigating away warns you.

General

Where: Studio ▸ Experience ▸ Setup ▸ General. (This is the page previously called Project Overview — old links and old notes still land here.)

Your project’s identity and its foundational settings. It’s a thin tab-bar shell: pick a tab, fill the shared form, Save.

Tab	What it configures
Project Overview	The project’s top-level identity (name, description, the basics that label it everywhere).
Landing Page	What the consumer app opens to — the first thing a user sees on entering the project.
Universal Template	A shared template applied across the project’s documents.
Concept Settings	Project-level concept/extraction configuration.
Ingestion Settings	Project-wide ingestion defaults (complements per-connector settings — see Ingestion & connectors).
Global Variables	Named values reusable across the project’s configuration.

Watch out. Which tabs appear depends on the access you hold; a missing tab may be hidden for you rather than absent. The set above is the full default.

Behaviours to know:

The active tab is remembered in the address. Switch tabs and the address updates, so a refresh or a shared link reopens the same tab — handy for sending a teammate straight to “Global Variables”.
Unsaved-change guard. A dirty tab shows a red dot and leaving the page warns you. Switching to a different project clears the dirty state.
Inline help. The info bubble on each tab is keyed to that tab — context help on click.

Appearance

Where: Studio ▸ Experience ▸ Setup ▸ Appearance.

Where General sets what the project is, Appearance sets how the runtime looks — branding, theme, logos, and the layout of the document page, navigation, and panes your users see.

Tab	What it configures
`<Collection>` Page	The document page — its theme, logos, branding. The label takes your collection’s name, e.g. “Invoice Page” or “Contract Page”.
Navigation Menu	The consumer app’s left navigation.
Summary Pane	The summary panel beside a document.
Action Pane	The action panel (its own dedicated editor).
Document List	How the document list and grid render — the icons on each row, and which view, filter and action options your users get.
Label Categories	Grouping of labels for display. Always visible.

Behaviours to know:

Tabs load on first open. Each tab’s body only builds the first time you open it, then stays put — switching back is instant and in-progress edits survive the switch. Expect a brief load the first time.
The dynamic first tab reflects your collection’s name — rename it to “Claim” and you get “Claim Page”.
Same red-dot and address behaviour as General, including the Action Pane’s separate dirty flag.

Tip. Logos and theme set here are also what a published Solution can carry forward — get the branding right before you package the project in Hubs & distribution.

Designer — Pages, Packs and Cards

Where: Studio ▸ Experience ▸ Designer ▸ Pages, Studio ▸ Experience ▸ Designer ▸ Packs, Studio ▸ Experience ▸ Designer ▸ Cards.

This is today’s primary way a builder shapes what users see. General and Appearance dress the screens the platform already gives you; Designer is where you build screens of your own — a lending review workbench, a vendor scorecard, a team’s landing page — by composing cards.

Entry	What it is
Pages	The no-code page designer: choose a layout, drop in cards, configure each card against a collection, preview, publish. A card has its own filter/column settings — there is no “point this card at a View” control; see Views below.
Packs	A bundle of pages wired into one journey — a click on a record in one page opens its detail page — with a walkthrough preview before you hand it to users.
Cards	The browsable card library: every card type you can place, what it shows, what it needs, and a jump straight into the designer.

Dashboards live here too: charts, counts and breakdowns are card types you place on a page. The consumer side of that is Dashboards & inbox; the full treatment of cards, layouts and packs is Pages & cards.

Watch out. Pages, Packs and Cards can be switched off for a workspace — they disappear together, and Packs additionally needs Pages to be on. All three are on by default; if you don’t see them, ask your administrator.

Search

Where: Studio ▸ Experience ▸ Channels ▸ Search.

Search settings configure the Search experience from Chat & search. Three tabs: General (how search behaves for end-users), Audit (a read log of search activity, which loads on first open), and Feedback (that same table filtered to the thumbs-up/down users leave on search results).

General is where you actually tune results:

Control	What it does
Show Titles / Redirect to the source url	Whether a result shows its document title, and whether clicking it opens the original source instead of the in-app document.
Full Text Indexing	The master switch for full-text search. Re-ranking, custom boosting and the prompt choices below stay greyed out until it is on — the page tells you so.
Use ReRanking	Reorders the first pass of results by how well each one really answers the query.
Use Custom Boosting	Turns on the weights below, so you decide what counts most.
Category Boost / Title Boost / Content Boost	The weights themselves — push title matches above body matches, or the reverse.
Text Classification Prompt / Query Understanding Prompt / Search Summarization Prompt	Which instruction set is used to classify text, interpret the user’s query, and write the summarised answer. Each is set to Default until you pick your own.

Tune one thing at a time and re-run the same query — boosting is much easier to judge by comparing two result lists than by reasoning about the numbers.

Watch out. These Audit and Feedback tabs are search-specific. The project-wide record of who did what is a different page — Studio ▸ Governance ▸ Audit & Usage (Access & roles) — and it is where people hunting for “the audit page” usually mean to go.

Watch out. Views are not a tab here. They live at Studio ▸ Data ▸ Views, described below. This is the single most common wrong turn on this surface.

Chat

Where: Studio ▸ Experience ▸ Channels ▸ Chat.

Chat settings configure the Chat experience from Chat & search. It mirrors Search: General, Audit (a read log of chat activity), Feedback (that table filtered to user feedback). General is the big one:

Control	What it does
Default Questions	A reorderable list of starter prompts shown in the chat. Drag to reorder, add a question after any row, blank rows are dropped on save. Pin default questions keeps them visible. These are the clickable starters your users see in Chat & search.
Chat Greeting Text / Tagline Text / Placeholder / Disclaimer	The opening greeting, the short tagline under the chat (hideable), the grey hint text inside the message box, and the disclaimer line.
Disable Chat Questions	Hide the default questions entirely.
Enable Question Preview	Preview a suggested question before sending.
Hide Chat References / Tagline	Toggle the citations panel and tagline off.
Project / Document Prompt	The prompt template used for project-wide vs single-document chat.

Saving clears the unsaved-changes dot.

Tip. Good default questions are the cheapest UX win on the platform. Write three or four that match what your users actually ask (“What’s overdue?”, “Summarise this contract’s risks”) — they double as documentation and as a demo script.

Views — define what your end-users browse

Where: Studio ▸ Data ▸ Views. Views sit under Data, not under Search — opening Views does not show the Search tab bar, and there is no Views tab on the Search page.

A View is a saved, named, filtered slice of a collection’s documents, with chosen columns — exactly the dropdown your reviewers switch between in The document workspace (“All Invoices” vs “Overdue Invoices” vs “My Queue”). Each View is either a Project template (shared, role-scoped) or a User template (personal). The Views table lists what exists; empty, it reads “No views to show / Please create a view to see the details”:

Column	What it tells you
Name	The View’s display name — what users see in the View dropdown.
Description	A short note (truncated past ~50 chars, full text on hover).
Created By	The email of whoever created it.
Has Dashboards	Green Yes / red No — whether the View has dashboards attached.
Type	Project (shared) or User (personal) chip.
Allowed roles	Colour-coded chips — who may see this View (“-” if unrestricted).
Action	An info icon (tooltip “Check what does each view contains”) opening a View Details side-popup from which you can open or delete the View.

Watch out. Delete is permanent and asks “Are you sure you want to delete <name>?” first. The Action column only appears if your access includes managing Views — a gate, not a missing feature.

Walkthrough — defining a Project View. Studio ▸ Data ▸ Views is a reader, not a builder — it lists, inspects and deletes the Views that already exist, with no “+ View” of its own. You build one from the Documents surface — the collection’s own consumer-facing list (The document workspace), reached from Studio ▸ Data ▸ Collections (Collections & schema) or straight from the project:

Open the collection’s Documents surface and shape it exactly how you want the View to look: pick columns (which extracted Labels show, in what order) and set filters — e.g. a Due Date range ending today, or Invoice Total over 10,000.
Options ▸ Save View as and name it (this becomes the dropdown label); Save Under chooses My Views (a personal User View) or Project Views (shared — needs admin/creator access); add a Help Message as its description.
Back in Options, use Allowed Roles to scope a Project View to the right people.
Save. The View now appears as its own tab on the Documents surface, and as a row in the Studio ▸ Data ▸ Views table above — where you can re-open its details or delete it, but not where you made it.

To put the same slice on a page instead of a tab, place a DocList card and set its own Label columns (not the fixed Columns list — that offers only built-ins like title, stage, assigned and updated, never your extracted Labels) and its own Label filter. A card has no setting that binds it to a saved View by name, so you rebuild the filter rather than point at it (Pages & cards) — and not every View filter can be rebuilt there, as Try it yourself below shows.

A good View still pays off in several places: it’s what your end-users switch between on the Documents surface, it scopes the Select a view picker in Search (Chat & search), and it’s what agents and hub imports rebind to — a card on a page just has to recreate its filter by hand rather than referencing it.

Try it yourself

A small, real end-to-end: give your invoice reviewers an Overdue Invoices View and a chat starter question that matches it.

Part A — define the View:

Open your invoices collection’s Documents surface — not Studio ▸ Data ▸ Views, which has no “+ View” of its own.
Add columns: Vendor, Invoice Total, Due Date, Status.
Add a filter on your Due Date Label. This surface filters a date Label as a date range — set the range to end today, and leave the start empty or far enough back to cover your oldest invoice. There is no Overdue to filter Status on: a document’s Status is its lifecycle stage, and the seeded Four-Eyes flow has no such stage. “Overdue” is a fact about the Due Date value, so that is the Label the filter has to name. One trap before you save: the range you set is the range it keeps. Overdue Invoices is pinned to the date you typed and drifts tomorrow, so say in the Help Message who re-saves it and when.
Options ▸ Save View as → name it Overdue Invoices; Save Under = Project Views; Help Message Invoices past their due date, awaiting action. Save.
Back in Options ▸ Allowed Roles, set it to Reviewer.
Confirm Overdue Invoices appears in the Studio ▸ Data ▸ Views table with Type = Project and the Reviewer chip — that page shows it now; it isn’t where you built it.

Part B — add the matching chat starter:

Go to Studio ▸ Experience ▸ Channels ▸ Chat ▸ General.
Under Default Questions, add Which invoices are overdue? and tick Pin default questions. Save — the red dot should clear on save.

Verify as a consumer: open the project’s consumer app as a Reviewer. The View dropdown now offers Overdue Invoices; the chat opens with “Which invoices are overdue?” as a clickable starter. You just configured, end to end, something your users consume.

Bonus — and the one thing a View does that a card can’t. In Studio ▸ Experience ▸ Designer ▸ Pages (if page design is switched on for your workspace), add a DocList card and set its own Label columns — one repeater row per Label — to Vendor, Invoice Total, Due Date. Add Stage separately, from the card’s built-in Columns list: the lifecycle stage is a built-in column, not a Label, so it doesn’t belong in the Label-columns repeater. (It is the same thing the Documents surface labels Status.)

Now the filter, and the lesson. A card’s Label filter row has no date operator. Its four comparison operators — Less than, Greater than and their or equal pair — read the value as a number, so a date never matches one; Equals, Contains and their Not pair match text, and Is blank / Is not blank test for an empty value. Your Overdue Invoices slice is a date range, so the card cannot reproduce it. Two honest ways forward: filter the card on something the row can answer (Invoice Total · Greater than · 10000 works), or leave the overdue slice to the View and give the page a link to it. This is exactly where a saved View earns its keep.

The card’s other filter is for stages — Default stage filter, which picks workflow stages rather than Label values. Reach for that one when the slice you want really is “everything sitting in review”. The card has no setting at all that references a saved View by name (Pages & cards).

Where to go next

Access & roles — Studio ▸ Governance: Users & Access (people, personas, effective policy), APIs, History, Snapshots, Configuration lock, and Audit & Usage.
Pages & cards — the Designer group in full: layouts, the card library, and packs.
Hubs & distribution — package this whole experience (branding, Views, pages) as a publishable Solution.
Embed & share — putting these surfaces in front of users outside the app: share links and embeds.
Dashboards & inbox — revisit the consumer side now that you’ve seen the controls.