> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.cloudraker.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cloudraker.com/_mcp/server.

# Record types overview

A **record type** is the shape you define for a kind of data a project collects — for example *Invoice*, *Vendor*, *Patient*, or *Claim*. It says which details every entry of that kind carries: an invoice number, a total amount, a due date, a status, and so on.

Think of a record type as a reusable form template. One filled-in entry is a **record** — one specific invoice. People enter records by hand, or Florent writes them automatically when it extracts data from documents.

Records always come from a person or get approved by one before they become real data. Florent drafts records; you review and approve them. See [Reviewing AI work](/work/reviewing-ai-work).

## What a record type is made of

Every record type has a few defining parts:

* A **name**, in both singular and plural form (*Invoice* / *Invoices*).
* An **icon** that marks it in tables and lists.
* An ordered list of **fields** — the individual details to capture, each with its own type (Text, Number, Currency, Date, Select, and so on).

The fields and settings live in the visual schema editor. Building that schema — adding fields, choosing field types, picking the title field — is covered in [Build a record type](/record-types/build-a-record-type).

## The three scopes: where a record type lives

The same record-type concept exists in three places, each for a different job. This matters because **the three are independent copies** — editing one never changes the others.

The reusable master definition for your whole organization — a catalogue you build once and reuse.

**Where to find it:** the **Building Blocks** group in the sidebar, then **Record types**.

A library record type is a template, not a place data lives. It **holds no records**. You add it to projects and project templates, where it starts collecting data.

A record type baked into a [project template](/projects/project-templates) so every project started from that template gets it automatically.

**Where to find it:** inside a project template's setup.

Like the library version, a template record type is a definition only — it **holds no records**.

The working record type that actually collects data inside one project.

**Where to find it:** open a project, then the **Record types** tab.

This is the only scope that **holds records**. Records attach here and nowhere else.

**Records only live in live projects.** Library and template record types are blueprints — they never hold data. To collect records, you need a record type inside an actual project.

## How copies flow

Whenever a record type moves from one scope to another, it becomes a fully independent copy:

* Adding a library record type to a **template** makes its own copy on the template.
* Adding a library record type to a **project** makes its own copy in that project.
* Creating a project **from a template** copies every template record type into the new project automatically.
* A project created from scratch (not from a template) starts with **no record types** — you add them in the project's **Record types** tab.

After any copy, the project's version is entirely its own. Editing a project's record type never touches the template or the library, and editing the library never reaches projects that already exist.

There is no "update from library" sync. Changing a library record type does **not** flow into projects or templates that already use it. Update each copy where you need the change.

## Where record types appear in the app

You'll come across record types in a few places, depending on what you're doing:

The organization's master library. A table lists every record type with its **Name**, its field count, and a description. Builders and Admins create and edit them here. This is the catalogue you reuse across projects.

Each project lists the record types it tracks, with a field count for each. Clicking one opens its **records table** — the rows of data this project has collected. Working with records and saved views is covered in [Project data](/projects/data).

Form, Document, and AI tasks can read from or write to a record type — for example a **Document** task where Florent extracts invoices into records. See [Task types](/playbooks/task-types) for which tasks touch records.

An extract action points its output at a record type so the values it pulls from documents land as records. See [Extract data](/actions/extract-data).

## Who can work with record types

What you can do depends on your role:

* **Builders** and **Admins** create and edit record types in the org library and in projects.
* **Managers** add and edit record types inside projects they can access, and work with the records.
* **Members** can view record types and work with records, but can't change a record type's shape.

For the full breakdown of who can do what, see [Roles and permissions](/admin/roles-and-permissions).

If you lack access, you'll see a banner reading *"You don't have access to record types. Ask an admin if you need it."*

## Where to go next

Add fields, choose field types, and set the title field in the schema editor.

Enter records, work with the records table, and save views inside a project.

See which playbook tasks read from and write to record types.

Build an action that pulls values from documents into records.