Policies (ABAC)
ABAC stands for Attribute-Based Access Control. While roles answer the question “can this user perform this action at all?”, ABAC policies add context-dependent conditions: “can this user perform this action given the current circumstances?”
For example, a role might grant “approve purchase orders”. A policy can refine that to “approve purchase orders only under 2,000,000 DA and only if the user did not create the order themselves”.
Policies are the second layer of Beelocity’s access control — they sit on top of roles and add conditional logic without requiring you to create dozens of highly specific roles.
When to Use Policies
Policies are entirely optional — many organizations run fine with just roles. Consider adding policies when you need rules that depend on context, not just identity:
| Need | Example policy |
|---|---|
| Monetary thresholds | Junior staff can only approve purchase orders under 500,000 DA |
| Segregation of duties | A user cannot approve their own purchase requests (the “four-eyes principle”) |
| Warehouse scoping | Users can only perform inventory adjustments in their assigned warehouses |
| Time restrictions | Certain operations are only allowed during business hours (Sun-Thu, 8:00-17:00) |
| IP-based rules | Sensitive financial actions restricted to corporate network access only |
If none of these apply to you, skip policies entirely and revisit them later if the need arises.
Policy Structure
Each policy is defined by five key fields:
| Field | What it does |
|---|---|
| Name | A human-readable label that explains the policy’s purpose (e.g., “PO approval limit — 2,000,000 DA”). Good names make the policy list self-documenting. |
| Target | Which permission, module, resource, or action this policy applies to. A policy only evaluates when the user attempts something that matches its target. |
| Condition | A logical expression that must evaluate to true for the policy’s effect to apply. This is where you define the “when” — the circumstances under which the rule kicks in. |
| Effect | Allow or Deny. Most policies are Deny rules (“deny approval if amount exceeds threshold”), but Allow rules are useful for granting exceptions. |
| Priority | A number that determines evaluation order. Higher-priority policies are evaluated first. Use priority to ensure critical deny rules are checked before less important allow rules. |
Evaluation Logic
When a user attempts an action, Beelocity evaluates all active policies that match:
- Find matching policies — all policies whose target matches the attempted action.
- Evaluate conditions — each matching policy’s condition is checked against the current context (who is doing it, what they are doing it to, when, from where).
- Apply the deny-override rule:
- If any matching policy denies the action, access is denied — regardless of what other policies say. Deny always wins.
- If at least one policy allows and none deny, access is granted.
- If no policies match at all, the decision falls through to role-based permissions. ABAC is purely optional refinement — it does not replace roles.
This “deny wins” approach means you can confidently add allow policies without worrying about accidentally overriding a critical security rule.
Condition Attributes
Conditions are expressions that reference attributes from four categories. These attributes are the building blocks of your rules:
| Category | What it provides | Example attributes |
|---|---|---|
| User (subject) | Information about who is performing the action | Roles, department, assigned warehouses, assigned categories, user ID |
| Resource | Information about the record being acted on | Type, warehouse, total amount, currency, status, who created it |
| Action | The operation being attempted | CREATE, UPDATE, DELETE, APPROVE, EXPORT |
| Environment | Contextual information about when and where | Current time, day of week, IP address |
Operators
Conditions support a range of operators for building expressions:
| Operator | Purpose | Example |
|---|---|---|
eq | Equals | resource.status eq "DRAFT" |
gt, gte, lt, lte | Numeric comparisons | resource.total_amount gt 2000000 |
in | Value is in a set | user.role in ["ADMIN", "OWNER"] |
contains | Set contains a value | user.assigned_warehouses contains resource.warehouse_id |
between | Value is within a range | environment.hour between 8 and 17 |
and, or, not | Logical operators | (resource.amount gt 1000000) and (user.role eq "JUNIOR") |
Creating a Policy
- Go to Access Control > Policies and click Create Policy.
- Set the target — choose which permission or module/resource/action combination this policy should evaluate against.
- Define the condition — describe when this policy should take effect.
- Choose the effect — Allow or Deny.
- Set the priority — higher numbers are evaluated first. Use this to control evaluation order when multiple policies could apply to the same action.
- Save.
Tips
- Start with deny rules — the most common use case is restricting what roles already allow. “Deny approval over X amount” or “Deny if user created the record” are typical first policies.
- Name policies descriptively — when you have 10 or 20 policies, clear names like “PO approval limit — junior staff — 500K DA” are much easier to manage than “Policy 7”.
- Test with a low-privilege user — after creating a policy, verify it works by checking what happens when the affected user attempts the restricted action.
- Use priority carefully — in most cases, the default priority works fine. Only adjust it when you have multiple policies on the same target and need to control which one is evaluated first.