Shaping the experience

In one line. The four Studio surfaces — Project, Search, Chat, and Intelligence — where you configure exactly what your end-users see in the consumer app. You’ll be able to. Brand the runtime, define the saved Views your users switch between, set the chat’s default questions and behaviour, and configure the dashboards they read. Where this lives. Studio ▸ Project, Studio ▸ Search, Studio ▸ Chat, Studio ▸ Intelligence.

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 these four surfaces; a builder who skips them ships a working-but-confusing app.

The mental model is simple: you configure here; your users consume there. A saved View defined in Search settings is the dropdown your reviewers pick from in The document workspace. A chat Default Question is the clickable starter in Chat & search. A widget added in Intelligence is a tile on the dashboard in Dashboards & inbox. You’ll want Studio orientation and a project with at least one collection (Collections & schema) before working through this.

Flag-gated grouping (routes unchanged). With the studioRailV2 flag on, the rail regroups Project / Search / Chat / Intelligence under a single “Experience” section, and Search/Chat collapse into one leaf each with in-page tabs; with it off, the legacy rail lists every sub-item separately. The routes and controls are identical either way. The Experience section also carries the Pages · Packs · Cards leaves — the composable-page surfaces covered in Pages & cards — with Intelligence appearing as the Analytics leaf.

Under the hood. Almost every field on these screens is wrapped in a *botModulePermission gate, so a teammate who “can’t see a tab” is usually missing a role action, not hitting a bug — fix it in Access Roles (Security & governance). A small red dot on a tab label means unsaved changes; navigating away warns you.

Project ▸ Overview

Where: Studio ▸ Project ▸ Overview.

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 is filtered by your role’s visible-menu config; a missing tab may be hidden for your role rather than absent. The set above is the full default.

Behaviours to know:

The active tab is remembered in the URL. Switching tabs writes #activeTab=<id>, so a deep link or a refresh 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.

Project ▸ Appearance

Where: Studio ▸ Project ▸ Appearance.

Where Overview 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
`<Entity>` Page	The document page — its theme, logos, branding. The label is dynamic: it shows your project’s entity name, e.g. “Invoice Page” or “Contract Page”, not literally “Documents 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/grid renders. Card templates take `<<token>>` placeholders, including the uploader (`<<uploaded-by-name>>` / `<<uploaded-by-email>>` / `<<uploaded-by-id>>`) and `<<ingested-at>>` (formatted with the workspace’s date format).
Label Categories	Grouping of labels for display. Always visible, regardless of role config.

Behaviours to know:

Lazy-loaded tabs. Each tab’s body only mounts the first time you open it, then stays mounted (just hidden) — switching back is instant and in-progress edits survive the switch. Expect a brief load on first open of a tab.
The dynamic first tab reflects your configured entity name — rename the entity to “Claim” and you get “Claim Page”.
Same red-dot and URL-fragment behaviour as Overview, 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 & solutions.

Search settings

Where: Studio ▸ Search. Under studioRailV2 this is one rail leaf with in-page tabs; in the legacy rail the tabs are separate items.

Search settings configure the Search experience from Chat & search. Three visible tabs — General (how search behaves for end-users), Audit (a read log of search activity, lazy-loads on first open), Feedback (the same audit table, filtered to user feedback on search results) — plus Views, the most important thing here for a builder.

Under the hood. The tab bar only renders under studioRailV2; one component switches its body by route data.type (general / audit / feedback / views). The Views type is deliberately not in this tab bar — you reach it from the Data Model, described next.

Views — define what your end-users browse

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”). This screen is where a builder defines those Views. 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 role chips — which roles 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 itself only appears if your role has the “Action in Search views” permission — another role-gate, not a missing feature.

Walkthrough — defining a Project View. The Views table lives in Search settings, but the create/edit action is launched from the collection’s Data Model (Collections & schema) — that’s where the collection’s columns and filters are in front of you:

Open the collection in Studio ▸ Data Model 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 also feed the View Widget on dashboards (see Intelligence, below) and are the “View” that agents and hub imports rebind to — a good View pays off in several places.

Chat settings

Where: Studio ▸ Chat. Like Search, one rail leaf with in-page tabs under studioRailV2; legacy shows separate items.

Chat settings configure the Chat experience from Chat & search. It mirrors Search but with three tabs and no Views: 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.

Under the hood. Saving General clears the unsaved-change dot on its own (it emits a “saved” signal) — unlike Search settings, no lingering red dot after a successful save. Default questions are stored as DefaultChatQuestions; the pin toggle as PinDefaultChatQuestions.

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.

Intelligence ▸ Dashboards

Where: Studio ▸ Intelligence.

Where you configure the dashboards your end-users read in Dashboards & inbox. A menu + details split:

┌─ Intelligence ────────────────────────────────────────────────────────────┐
│  Dashboards (menu)      │   < selected dashboard's widgets >              │
│  Operations             │   Name           [ Overdue by Vendor ]          │
│  Quality                │   Description     …                             │
│  Overdue Watch < sel    │   UseCache [ on ]   EnableMaximize [ off ]      │
│  (empty: no dashboards) │   TemplateId [Query Widget]  ChartType [donut]  │
│                         │   [ Open live dashboard ]                       │
└───────────────────────────────────────────────────────────────────────────┘

Region	What it does
Dashboards menu (left)	Lists each dashboard by name + info message. Empty until you create one.
Details panel (right)	On selecting a dashboard, shows its first widget and lets you inspect each widget’s settings (Name, Description, UseCache, EnableMaximizeOption, TemplateId, ChartType, QuickActions).
Open live dashboard	Jumps to the running dashboard (`/_dashboard?did=<id>`) — the exact view your end-users get.

Adding widgets and charts

Building a dashboard is: add a widget, pick its template, optionally pick a chart type, point it at data, save. The catalog is 31 widget templates and roughly 20 chart types, in categories:

Category	Use it for	Examples
KPI / single-number	One headline metric	Documents Count, Label Instance Count, State, QC Widget, Error Metrics
Table / multi-row	A list of labels, stages, users, or rows	Multi Label View, Multi Stage, Multi User Stages, View Widget, Datasheet Widget
Query / analytics	An insight you draw as a chart	Query Widget, Dynamic Widget, Ingestion Summary, Sessions, Source / Source Instance
Agentic / AI	AI-built or conversational tiles	Agentic Widget, Chat Widget, Document Summary
Layout / content	Shape the dashboard itself or embed content	Filter Widget, Navigation, Multi Widgets, Rich Text Editor, Static HTML

Chart-capable widgets (notably Query Widget) offer a Chart Type picker: line, area, bar and stacked-bar variants, pie, donut/semidonut, gauge, meter, funnel, heatmap, map, and bubble — or none, to keep the raw table.

Tip. The Agentic Widget lets you describe a tile in plain language and have AI build it — the fastest way to a first chart when you’re not sure which template fits.

Not currently shipped. Two widgets are commented out in source — Users and Infra Cost Widget — so they won’t appear in the picker. Don’t promise them to end-users.

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 (Search/Data Model):

Open your invoices collection in Studio ▸ Data Model and create a new View.
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.
Open Studio ▸ Search ▸ Views (or the legacy Views item) and confirm Overdue Invoices appears with Type = Project and the Reviewer chip.

Part B — add the matching chat starter (Chat):

Go to Studio ▸ 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 ▸ Intelligence, add a View Widget pointed at your new Overdue Invoices View — the same slice shows up as a dashboard tile too.

Where to go next

Security & governance — the Access Roles that gate every field and tab you just touched, plus Users, Activity, Audit, and config freeze.
Hubs & solutions — package this whole experience (branding, Views, dashboards) 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.