Add policy conditions
Use the Console condition builder to compare caller and resource facts for one access decision. The builder accepts policy expressions; it does not infer a condition from a field label or role name.
Prerequisites
- Identify the caller fact, resource fact, and exact action the condition should govern.
- Confirm that the principal attributes and resource attributes used by the expression exist for the tested caller and resource.
- Confirm that a role alone can't express the rule you need.
Choose a match mode
| Console mode | Meaning |
|---|---|
| Single | One expression must be true. |
| All (AND) | Every expression must be true. |
| Any (OR) | At least one expression must be true. |
| None (NOT) | None of the expressions may be true. |
Use Add Expression to add another expression to All, Any, or None. Use Clear all only when the rule should have no condition; a blank expression is removed from the saved condition.
Write the expression
Use the full public shape first:
request.resource.attr.owner_id == request.principal.id
request.principal.roles contains caller roles. Principal attributes are under
request.principal.attr, while resource attributes are under
request.resource.attr. R and P are supported shorthand for the resource
and principal only after those full objects are understood.
Add and verify the condition
- In the target app's Policy Editor, open the policy in Form and locate the rule for the intended action.
- Choose Single, All (AND), Any (OR), or None (NOT) and add the smallest expression set that represents the decision.
- Inspect Matrix and Flow to ensure the condition applies only where intended, then save the complete policy definition.
- In Live Testing, run a matching attribute case that should be allowed.
- Run a nonmatching case that changes one fact and should be denied.
- Run a missing attribute case and verify it does not grant access.
Invalid expression syntax or incompatible value types prevents a valid Save or causes evaluation to deny. Do not weaken the expression to work around a validation failure; correct the source attribute or policy definition and rerun all three cases.
For a Database read condition, review Database policy filters before depending on operator or storage-model behavior.
Expected result
The condition remains attached to the intended action and produces the recorded allowed matching result plus denied nonmatching and missing-attribute results.
Conditions are not a substitute for authentication and do not replace a role when the access relationship should be explicit. Use a derived-role policy only when a condition should produce a reusable role.