Model
Rules & Actions
A record can't reach a state the template disallows, and there's one controlled, named way to change it. No separate validation layer, no hand-built state machine — just two declarative primitives every write path already respects.
Rules keep every record valid
A rule is when [conditions] then [constraints], checked synchronously on every write — the entity form, the REST API, CSV import, and AI agents alike. Unlike a form-only validator, there's no door a record can slip through: a change that would leave it failing an active rule is rejected before it's ever stored.
Shared condition vocabulary
An empty when makes a rule unconditional — that's how a plain required
field is expressed: when: [] then: [is not empty]. There's no separate "required" flag hiding a second
evaluation path.
Actions are the guided way to change one
An action bundles a precondition that gates it, the fields it asks the operator for, and the presets it writes silently — into one atomic write. A status transition is nothing more than a precondition on the current status plus a preset for the new one; there's no separate workflow engine underneath it.
Walkthrough: closing out an incident
The Incident template from the Server Monitoring blueprint puts both
primitives to work on the same field.
- 1
An incident opens
A new Incident record is created with Incident Status set to Open. No rule applies yet — there's nothing to check on creation.
- 2
An operator starts investigating
The Start investigation action is available only while status is Open. It has no fields — its only effect is a preset that sets status to Investigating.
- 3
Closing it out is guided, not free-form
Resolve incident is available whenever the incident isn't already Resolved. It asks for a Description of what happened and what was done, then presets Incident Status to Resolved.
- 4
The rule backstops the action
Resolved incidents are documented fires whenever Incident Status equals Resolved, and requires Description to be non-empty. The action's own required field already satisfies it — the rule is what makes that guarantee hold everywhere, not just through this one action.
- 5
Two ways it can be refused
A 409 means the precondition no longer holds — someone else moved the record first. A 422 means a required field was missing or a rule was violated — the response names the exact attribute to fix.
Built for agents too
Because an action bundles a precondition, its required fields, and its side effects into one named operation, it maps directly onto an MCP tool call — an agent doesn't need to know the underlying attribute plumbing to run a safe, well-defined operation on a record.
List what can be done
list_entity_actions Every enabled action on the record's template, each already evaluated against its current values — available or not, and why.
Run it
execute_entity_action Send only the values the fields array asked for. Presets are applied silently, and the write passes through the same rules any other write does.
Apply it to many records
batch_execute_entity_action Up to 100 records per call, with the same per-record executed / precondition_failed / rule_violated / failed outcomes the bulk-selection UI shows.
Reacts into automations
An automation can trigger on a specific action running — useful for notifying a channel whenever, say, Resolve incident completes, regardless of who or what ran it.