Conditional access policies
How role-specific outcomes and tenant-wide blocks refine transaction-family permissions.
Access policies add context-sensitive rules to the normal role matrix. In the current product they apply only to:
- transactions;
- forward-dated transactions;
- standing orders.
Conditional access is planned to expand to more entities over time. Until an entity appears in the Entity Type selector, however, it is not supported and a policy cannot be configured for it. Treat the selector as the authoritative list of current coverage.
Configure policies under Access Control → Access Policies, or from a role's Access Policies tab when creating a role-specific conditional policy.
Policy types
| Type | Scope | Effect when its conditions match |
|---|---|---|
| Conditional Access | One role | Can override required approvals or the permitted submit/create, L1, L2, and L3 outcomes. |
| Validation Block | The tenant | Stops the action for non-L0 users and returns the configured validation message. |
A conditional policy refines an existing permission. The base role matrix is the gatekeeper: if the role does not have the entity/action permission, a conditional policy cannot grant it from nothing.
Conditions
At least one condition is required. Available fields depend on the selected entity type and include transaction values such as amount, currency, transaction code, booking branch, value date, involved accounts or products, and evaluated calendar/time context.
Conditions support comparisons including equals, not equals, greater or less than, list membership, and contains. Rows are joined with AND or OR. When the evaluated transaction does not supply a referenced field, that condition does not match.
For fields containing several values, such as the accounts or products used by lines, a positive equality or list check matches when any value matches. A negative check matches only when none of the values match.
Evaluation order
Only active policies are evaluated. remoteEaze orders them by the displayed evaluation order, then by creation time.
- L0 System Administrator bypass is resolved first.
- Data-access scope and the base role permission must pass.
- Matching tenant validation blocks are checked before conditional outcomes.
- The first matching conditional policy supplies its configured overrides.
- If none match, the role matrix result is used unchanged.
Because the first matching conditional policy wins, arrange more specific rules before broader fallback rules. For validation blocks, the first matching block supplies the message shown to the user.
Relationship to maker-checker
A conditional policy can change the number of approvals required for the matched submission and can allow or deny a decision outcome already present in the base matrix. It does not remove separation of duties, tenant boundaries, or data-access scope.
The transaction-family authorization scope remains the header Transaction Branch, even when policy conditions also inspect accounts, products, line currencies, or other transaction context.