Validation and Workflows

VoidQL conditions can refer to incoming data and contextual values, allowing authorization to depend on the requested mutation.

Payload references

Use $data.<table>.<field> in policy expressions where the engine expects a resolved value. The repository examples also exercise contextual tokens for user and trigger-stage data.

{
  if: {
    when: {
      left_value: "$data.orders.status",
      operator: "=",
      value: "approved"
    },
    do: {
      field: "orders.status",
      operator: "=",
      value: "submitted"
    },
    else: false
  }
}

This represents a transition rule: requesting approved is allowed only when the existing row is submitted.

Recommended workflow design

1. Enumerate allowed transitions explicitly.
2. Compare the proposed value with $data.
3. Constrain the current row using a column condition.
4. Scope the row to its tenant or owner.
5. Reject the default branch.
6. Test stale-state and concurrent-update behavior against the actual database.

Validation errors

The current code returns generic thrown errors rather than a stable, typed error taxonomy. Applications should avoid exposing raw error messages to untrusted clients and should map failures to their own API error contract.

Important

VoidQL policy checks complement database constraints; they do not replace NOT NULL, unique, foreign-key, check constraints, or transaction isolation appropriate to the domain.

← Authorization Patterns · Triggers & Extensibility →