Collection types

In one line. The Category you pick at creation decides how a collection behaves for the rest of its life — Processing moves work, Knowledge grounds answers, Structured holds rows. You’ll be able to. Pick the right category on the first try, and know why the choice is permanent.

The decision that comes first

Studio ▸ Data Model ▸ Collections ▸ + Collection asks you one load-bearing question: Category. Everything else about a collection can evolve — schema, lifecycle, sources — but the category is fixed once created (the editor shows it as a read-only chip afterwards, and the server enforces it). Thirty seconds of thought here saves a rebuild later.

The three categories

Processing — work in flight

The default. Each document is a case: it arrives, gets worked by the crew, walks the lifecycle stage by stage, and ends settled. Everything the Workflow pattern needs lives here — schema to fill, stages to walk, confidence gates, review routing.

Choose it when the sentence is “each one of these must be handled.” Invoices, claims, applications, contracts under review, support tickets.

Knowledge — reference that answers

Documents become readable knowledge the moment they land. No lifecycle, no stages, no settling — a Knowledge collection is a library, not a queue. Attach it to an agent’s Knowledge tab and you get grounded, cited answers; this is the entire foundation of Agentic Search.

Choose it when the sentence is “people should be able to ask about these.” Policies, manuals, product docs, past decisions worth consulting.

Knowledge is a shipped release feature (knowledgeCollections, default on). If an environment has switched it off as a kill-switch, the Knowledge option won’t appear at creation.

Add a Knowledge schema when your users also ask counting questions — facts then land in a Datasheet and the agent can answer “how many policies mention retention?” with SQL rather than prose.

Structured — records, not pages

Rows with fields, not documents with pages: vendor masters, rate tables, reference lists, results produced by agents. Structured collections are what structured-source ingestion fills (each row of an imported sheet becomes a record, updated in place on re-import), and what structured display surfaces like Pages & cards render as tiles, rows and tables.

You don’t have to type the schema by hand: the create form’s schema designer has an Upload file mode — drop in a spreadsheet and it infers the fields from the columns, with a live preview (multi-sheet workbooks let you pick the sheet) and an optional “Import the data too” toggle to bring the rows in at the same time. Later imports into the grid preflight every row and show ready-vs-problem counts before anything is committed.

Choose it when the sentence is “this is really a table.”

Side by side

	Processing	Knowledge	Structured
Unit	Document as a case	Document as reference	Row as a record
Lifecycle	Yes — the point of it	No	No
Typical writer	Ingestion + extraction crew	Upload or connector	Sheet import or agents
Typical reader	Operators in the workspace	Agents answering in chat	Cards, dashboards, exports
Solution shape	Workflow	Search	Both, as supporting data

One system usually mixes all three: a lending build keeps applications in Processing, underwriting guidelines in Knowledge, and rate sheets in Structured — and its agents read across them.

(A fourth, flag-gated purpose also exists — Dataset (Evaluation): golden documents with verified expected outputs, used only by evaluations and excluded from product views.)

The special one you don’t create

The Inbox is a system-owned, human-kind collection: it holds the work routed to people by confidence gates and review rules. You’ll meet it in G2 · Human-in-the-loop; you can’t delete it, and you don’t need to manage it.

Where to go next

• Shape what’s inside: D1 · Collections & schema.
• Get documents flowing in: D4 · Ingestion & connectors.
• The stages Processing documents walk: D3 · Taxonomy, lifecycle, tags & events.