> ## Documentation Index
> Fetch the complete documentation index at: https://netter.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Actions

> Apps write to entities by invoking Actions. An Action is the admin-approved, governed write a viewer triggers from a button—never a raw edit.

An **app never writes to an entity directly.** When a viewer clicks a button that changes data, the app invokes an [Action](/docs/ontology/actions)—a named, admin-authored write contract on that entity. The Action decides what can change, who can do it, and under what conditions. This is what makes a viewer-facing app a safe write surface instead of a free-for-all.

For the full Action model—field writes, parameters, guards, grants, and multi-entity effects—see [Ontology → Actions](/docs/ontology/actions). This page covers the app side.

## Kinds

An Action is one of three kinds, matching the [binding](/docs/applications/bindings) mode the app needs:

| Kind     | Effect                             | Required binding mode  |
| -------- | ---------------------------------- | ---------------------- |
| `create` | Add a new row to the entity.       | `write` or `readwrite` |
| `modify` | Update columns on an existing row. | `write` or `readwrite` |
| `delete` | Remove a row.                      | `write` or `readwrite` |

A `read` binding rejects every write. The check is server-side.

## How an action flows

1. A viewer clicks a button in the app—say "Mark as resolved" on a ticket.
2. The app invokes the Action for that entity and kind, with any parameters the viewer supplied.
3. The platform resolves a **named, active [Action](/docs/ontology/actions)** that authorizes the write, then checks the [binding](/docs/applications/bindings) mode, the Action's grants and guards, and [row-level security](/docs/permissions/row-level-security).
4. The write lands as an overlay on the entity's source data (see [Edit rows](/docs/ontology/edit-rows)).
5. The next read—from any app, dashboard, or query—sees the change, and the invocation is recorded in the Action's audit trail.

If no Action authorizes the write, it's refused. Binding mode alone is not enough—there's no default write path.

## Why the viewer can write here

Apps are an **admin-approved write surface**. An admin authored the entity's [Actions](/docs/ontology/actions), set the bindings, and the architect generated the UI; viewers act inside those boundaries. Direct ontology row edits still require admin or owner. The Action is the one path where a viewer's write is intentionally allowed—and only exactly as the Action permits.

## Missing an action?

If you build an app that needs to write an entity and no Action covers it, the [assistant](/docs/assistant/overview) flags the gap and offers a **Create Action** card. An admin reviews and saves it; the app's button works on the next invocation, no re-wiring required. See [Ontology → Actions](/docs/ontology/actions#create-action-from-chat).