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 ▸ 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 ▸ 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 ▸ Pages, Studio ▸ Experience ▸ Packs, Studio ▸ Experience ▸ 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 or a View, preview, publish.
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 ▸ 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 ▸ 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. You can start from Studio ▸ Data ▸ Views, or from the collection itself at Studio ▸ Data ▸ Collections (Collections & schema) — starting from the collection puts its columns and filters in front of you:

Open Studio ▸ Data ▸ Views and start a new View.
Name it (this becomes the dropdown label) and add a one-line Description.
Pick columns — which extracted fields (Labels) show as columns, in what order.
Set filters — e.g. status = Overdue, amount > 10,000 — so the View only lists matching documents.
Choose Type: a Project View (shared) or a User View (just yours).
For a Project View, set Allowed roles so only the right people see it.
Save. The View now appears in the table above and in the consumer View dropdown.

The same Views feed the cards you place on pages (Pages & cards), scope the Select a view picker in Search (Chat & search), and are what agents and hub imports rebind to — a good View pays off in several places.

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 Studio ▸ Data ▸ Views and create a new View on your invoices collection.
Name it Overdue Invoices; description Invoices past their due date, awaiting action.
Add columns: Vendor, Invoice Total, Due Date, Status.
Add a filter: Status = Overdue (or Due Date < today, if you have that field).
Set Type = Project and Allowed roles = Reviewer. Save.
Confirm Overdue Invoices appears in the Views table with Type = Project and the Reviewer chip.

Part B — add the matching chat starter:

Go to Studio ▸ Experience ▸ 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. In Studio ▸ Experience ▸ Pages, add a card pointed at your new Overdue Invoices View — the same slice now renders as a tile on a page too (Pages & cards).

Where to go next

Access & roles — Studio ▸ Governance: Users & Access (people, personas, effective policy), APIs, History, Snapshots, Freeze, 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.