Configure entity behaviour and actions

Where: Entities → select an entity → Behaviour. Behaviour defines permitted record actions and lifecycle logic in addition to the entity's field schema.

The Behaviour tab exposes the current definition and its editing tools.

Start from the current definition#

Open Behaviour and inspect the existing source or visual representation. Use the current editor's mode switch when available. Keep a saved valid definition as the starting point; do not replace an existing business policy with a generic example.

Define actions with names that describe an actual task, such as approving an order. Configure the action's required inputs and record/state conditions using the editor's current controls. Validate the definition and inspect errors before saving.

Keep schema and action inputs aligned#

An action's inputs refer to the entity's actual properties and types. Check property API names in Schema. For a state-based action, test a record in the allowed state and another in a disallowed state.

The generated record capability/preview information describes what the current caller can do. Seeing an action name in a definition is not proof that every user can execute it on every record.

Expose actions to an app#

Bind the entity to the app and configure the named actions the app can call. Read-only entity access cannot enable new mutation actions. Review the app's Actions configuration and the user's resource permissions before testing.

Verify the outcome#

Use a synthetic record, inspect the action preview/availability, execute the authorized action, and reload the record. Compare the new values and any action execution result with the intended business rule. Check the denied path too.

Behaviour and active versions affect the runtime contract. Follow Versions when releasing a changed definition and Sharing when granting access to it. Offline writes have additional eligibility restrictions for entities with behaviour; review Offline apps.