Actions overview
What actions are, and the difference between built-in and custom actions.
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.
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 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 actions only work as playbook steps. You can’t run one across many items — that’s reserved for custom actions. See 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.
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).
- 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.
Create an action
Creating an action only names it and picks its kind — you build out the details afterward in the editor.
Click New action
From the Actions library, click New action in the top-right. (You’ll only see this button if you have permission to create actions.)
Choose what it should do
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.”
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.
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.
Versions and playbooks
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.
Renaming vs. identity
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.
Archive, not delete
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.