> 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.

# Actions overview

An **action** is a reusable, single-purpose automation. You set it up once, test it, and then reuse it — either on its own across many files or records at once, or as a single step inside a [playbook](/playbooks/overview).

Think of an action as a small, dependable tool: it does one job (reads documents, generates documents, or fills a form), and it does that same job everywhere you point it. Florent and your playbooks lean on actions to do the repetitive heavy lifting — but, as always, **AI drafts and a person approves** before anything becomes committed data.

## Two families of actions

Actions split into two groups, and the [Actions library](#the-actions-library) shows them separately.

Ready-made steps that ship with RakerOne. You can't edit them, and they're only meant to be used as steps inside a playbook — not run on their own.

Actions someone on your team builds, tests, and activates. These are the ones you create, run across many items, and reuse in playbooks.

### Built-in actions

Built-in actions appear in the **Building blocks** section of the Actions library. They're the everyday plumbing a playbook uses to move work along. Each one has an info button that explains what it does; there's no editor, because you can't change them.

| Built-in action       | What it does                                                        |
| --------------------- | ------------------------------------------------------------------- |
| **Add a record**      | Adds a new record of a chosen type when a run reaches this step.    |
| **Update a record**   | Changes fields on an existing record.                               |
| **Find records**      | Finds records that match your criteria so later steps can use them. |
| **Florent comment**   | Posts a comment on the run for everyone to see.                     |
| **Send notification** | Sends an in-app notification to a person or role.                   |
| **Wait**              | Pauses the run until a delay or set time has passed.                |

Built-in actions only work as playbook steps. You can't run one across many items — that's reserved for custom actions. See [task types](/playbooks/task-types) for how an **Action** task uses one inside a playbook.

### Custom actions

A custom action is one of three kinds, chosen when you create it. The kind decides what the action reads, what it produces, and which page owns the how-to.

AI reads files and pulls structured values into fields your team reviews. Produces **records** (or inline fields).

Fills a Word template with record data. Produces **Word or PDF documents** in the project's files.

Fills a blank PDF or image form with record data. Produces **filled documents** in the project's files.

Read documents actions run over **files**. Generate and Fill actions run over **records**. You don't pick which — RakerOne swaps the input picker to match the action's kind when you run it. See [batch action runs](/actions/batch-runs).

## The Actions library

The Actions library is where every action lives. Open it from **Actions** under the **Building Blocks** group in the sidebar.

The page is split into two parts: your team's custom actions on top, and the read-only built-in actions below.

### Your actions

The **Your actions** table lists every custom action your team has built. Each row shows:

* **Name** — opens the action's editor.
* **Status** — a badge: **Draft**, **Published**, or **Archived** (see [the action lifecycle](#the-action-lifecycle)).
* **Output** — what the action produces: the record type's name, **Inline fields**, **Generated documents**, or **Filled forms**.
* **Used by** — how many playbooks reference this action (for example, **Not in use** or **1 playbook**).

If no custom actions exist yet, you'll see **No actions yet** with a prompt to define one. If you don't have permission to create actions, it reads "Actions will show up here once someone on your team creates one."

### Building blocks

Below your actions, the **Building blocks** section lists the built-in actions described above. Each row has an info button that opens a short description. There are no links here — built-ins have no editor.

Anyone signed in can browse the library, but creating, editing, and activating actions requires a builder or admin role. Without it, you won't see the **New action** button, and opening an editor link directly shows "You don't have access to actions." See [roles and permissions](/admin/roles-and-permissions).

## Create an action

Creating an action only names it and picks its kind — you build out the details afterward in the editor.

From the Actions library, click **New action** in the top-right. (You'll only see this button if you have permission to create actions.)

Under **What should it do?**, pick one of the three kinds:

* **Read documents** — "AI reads files and fills in fields your team review."
* **Generate documents** — "Fill a Word template with record data to create PDF or Word files."
* **Fill forms** — "Fill a blank PDF or image form with record data to create finished documents."

Give the action a clear **Name** (required) and an optional **Description** — the description shows in the actions list, so make it say what the action does. Then click **Create action**.

You land straight in the editor with a new **Draft** action. From here, fill in its output and instructions, then activate it. The steps differ by kind — follow the page for the kind you chose.

Set the output fields, instructions, and model, then prove it on sample files before activating.

Point it at a Word template or blank form, set the output format, and activate.

## The action lifecycle

Every custom action moves through three states, shown as a status badge in the library.

| Status        | What it means                                                        |
| ------------- | -------------------------------------------------------------------- |
| **Draft**     | Being built. Not yet runnable.                                       |
| **Published** | Active and runnable — both across many items and as a playbook step. |
| **Archived**  | Retired. Can't be edited, tested, or run.                            |

A new action starts as a **Draft**. When it's complete and valid, you **activate** it, which turns it **Published** and makes it runnable. To retire one, you **archive** it — there's no delete. Unarchiving returns an action to **Draft** so you can edit it again.

An action must be **Published** to run. Draft and Archived actions don't appear in the run launcher's action list. If you can't find your action when starting a run, check that it's been activated.

Each action carries a version number. Changing its output or how it runs bumps that version. If a playbook was built against an older version, re-activate the action so the playbook can adopt the change.

You can rename an action at any time, but its underlying identity is fixed when it's created. Renaming changes the label everywhere; it doesn't break any playbook that already uses it.

There's no way to delete an action — archiving is how you remove one from use. Archived actions can't be edited, tested, or run. Unarchive to bring one back to **Draft**.

## Where to go next

Build and test an action that reads files into reviewable records.

Set up a template and the action that fills it.

Process many files or records at once and review every result in a grid.

Add an action as a step inside a multi-step process.