Row Access Rules
Row access rules control which records a user can see, as opposed to whether they can see a resource type at all (that is the role’s job).
For example, a role might grant “View Stock”. A row access rule narrows that to “View stock only in Warehouse A and Warehouse B”. The user sees a filtered view and has no indication that other records exist — from their perspective, the filtered results are the complete dataset.
This is Beelocity’s third layer of access control, sitting on top of roles and policies.
Use Cases
Row access rules are valuable when different people in the same role should see different data:
| Scenario | Rule |
|---|---|
| Warehouse-scoped access | A warehouse supervisor only sees stock, movements, and adjustments for their assigned warehouses — not all warehouses in the organization. |
| Category-based filtering | A product manager responsible for electronics only sees products in the “Electronics” category tree. |
| Regional restrictions | A regional sales rep only sees partners and orders in their assigned geographic area. |
| Department isolation | Users in the marketing department cannot see records belonging to the finance department. |
How It Works
A row access rule defines a filter that is automatically applied every time a user queries a resource. The filter is invisible to the user — they simply see fewer results, as if the filtered-out records do not exist at all.
The rule works by comparing an attribute of the user (the “subject”) with an attribute of the record (the “resource”). For example:
- Subject attribute: the user’s assigned warehouses
- Resource attribute: the record’s warehouse
- Match type: the record’s warehouse must be in the user’s assigned warehouses
If the record’s warehouse is not in the user’s list, they cannot see it.
Rules are evaluated alongside policies and roles. The user must have the role-level permission and pass the row access filter to see a record. All layers must agree.
Managing Rules
Go to Access Control > Row Access Rules to create and manage rules. Each rule specifies:
| Field | Description |
|---|---|
| Resource | Which type of record the rule applies to (e.g., Stock, Products, Partners, Warehouses). |
| Subject attribute | The user-side attribute to match against (e.g., assigned warehouses, assigned categories, department). |
| Filter attribute | The record-side attribute to compare with (e.g., warehouse_id, category_id). |
| Match type | How to compare the two attributes — exact match, set membership (“in”), contains, etc. |
| Role | Which role this rule applies to. The rule only affects users with this role. |
| Priority | Evaluation order when multiple rules apply to the same resource. |
Tips
- Row access rules are invisible to users — they will not see an error or a “permission denied” message. They simply see fewer records. This is by design: it prevents users from even knowing about data they should not access.
- Combine with roles for best results — a role grants the ability to “View Products”; a row access rule scopes that to “only products in categories X, Y, Z”. Use both together.
- Be careful with broad rules — a rule that filters too aggressively might hide records that users legitimately need. Start specific and widen if needed.
- Test from the user’s perspective — after setting up a rule, check what an affected user actually sees to make sure the filter is correct.