Skip to main content
An app never writes to an entity directly. When a viewer clicks a button that changes data, the app invokes an Action—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. This page covers the app side.

​
Kinds

An Action is one of three kinds, matching the binding mode the app needs: 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 that authorizes the write, then checks the binding mode, the Action’s grants and guards, and row-level security.
  4. The write lands as an overlay on the entity’s source data (see 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, 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 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.