Create and manage access policies

Access policies refine transaction-family access when runtime facts match configured conditions. In the current interface they support Transaction, Forward-Dated Transaction, and Standing Order only.

The policy model is intended to cover more business entities over time. Treat the Entity Type choices shown in the form as the supported release scope; do not model another entity through a Transaction policy as a workaround.

Open Organization → Access Control → Access Policies. A role-specific conditional policy can also be started from that role's Access Policies tab.

Access and lifecycle

• Read Access Policy shows the tab, list, and details.
• Create Access Policy shows Create Policy.
• Update Access Policy shows Edit on a policy and permits both policy definition and evaluation-order changes.
• Delete Access Policy removes a policy.

Access policies do not use maker-checker or amendments. Creation, editing, reordering, and deletion take effect immediately.

Because a policy can block processing or change approval outcomes immediately, create and order it using a controlled example of the transaction it is meant to match.

Choose a policy type

Select Create Policy and use the General tab.

Conditional Access

A Conditional Access policy applies to one role. It can override one or more of the following when its conditions match:

• required approval count;
• whether creation or submission is allowed;
• whether L1, L2, or L3 approval is allowed.

The role's base entity/action permission is still required. A policy can refine an allowed action; it cannot grant an entity permission that the role does not have.

Validation Block

A Validation Block applies tenant-wide and stops a matching action for non-L0 users. Enter the Validation Message that should explain the blocked condition to the user.

Define the policy

On General:

1. select the policy type;
2. select the role for Conditional Access;
3. enter the Policy Name;
4. select the Entity Type;
5. configure at least one outcome for Conditional Access, or the validation message for a Validation Block.

On Conditions, add at least one condition. Available fields depend on the entity and include values such as amount, currency, transaction code, header branch, value date, references, accounts, products, and evaluated calendar or time context.

Select the comparison operator and value for each row, then join multiple rows with AND or OR. Supported comparisons include equal, not equal, greater or less than, list membership, and contains. For a multi-value field such as accounts or products, positive matching succeeds when any supplied value matches; negative matching succeeds only when none match.

Select Create Policy to activate it.

Edit a policy

Open a policy and select Edit. You can change its name, conditions, validation message, and Conditional Access outcomes.

The company, policy type, role, entity type, and evaluation order cannot be changed in the edit form. They define how and where the policy is evaluated. Create a new policy if one of those values must differ, then remove the old policy after validating the replacement.

Saving checks that the policy has not changed since you opened it. If another administrator saved first, refresh the record, review their changes, and apply yours again.

Set evaluation order

Use the reorder control to arrange policies from most specific to broadest, then save the order. remoteEaze evaluates active policies in displayed order:

1. tenant Validation Blocks are checked before role-specific outcomes;
2. the first matching block supplies the rejection message;
3. the first matching Conditional Access policy supplies its configured overrides;
4. if no conditional policy matches, the role matrix result remains in force.

The normal tenant boundary, data-access scope, base permission, record state, and separation-of-duties checks still apply. Transaction-family authorization scope uses the header Transaction Branch, not every line or account branch.

Read Conditional access policies for evaluation details and Data-access scope for the shared booking-branch rule.