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 the warehouses they cover — not all warehouses in the organization. |
| Own work only | A sales rep only sees the quotations and orders they created themselves. |
| Assigned work only | A technician only sees the jobs the record says are assigned to them. |
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 warehouses the user covers
- Resource attribute: the record’s warehouse
- Match type: the record’s warehouse must be in the warehouses the user covers
There are three things a rule can read about a person, and the picker offers exactly those: that it is them, the warehouses they cover, and the storage locations they cover. The last two come from where the person sits in the organization chart — a unit can stand for a warehouse or for a storage location, and covering that unit is what puts the place on their list (Hierarchy and delegations). Anything else about a person — their department, a clearance level — is not something a rule can be written against.
If the record’s warehouse is not in the user’s list, they cannot see it — and “see” means everywhere the record can be reached: it disappears from lists, its detail page answers “not found”, and any action on it (closing a cash session, reading its reports, confirming a document) is refused the same way.
A user with no value for the subject attribute sees nothing. Rules only ever narrow access, so covering no warehouse means an empty list to match against — not an exemption from the rule. A new team member covered by a warehouse-scoping rule sees no stock at all until someone places them in the hierarchy; if they should see everything instead, leave them out of the rule’s role.
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 Settings → Row Access to create and manage rules. Each rule specifies:
| Field | Description |
|---|---|
| Name | What you will recognise the rule by in the list. |
| Resource type | Which kind of record the rule applies to — stock, products, partners, warehouses. |
| Filter attribute | What the rule reads on the record: its warehouse, its storage location, who created it, or the record itself. You pick from a list. |
| Subject attribute | What the rule reads about the person: the warehouses they cover, the storage locations they cover, or that it is them. |
| Match type | How the two are compared — exactly equal, one of a set, or anywhere under a unit of the hierarchy. |
| Roles | Which role the rule binds. Leave it on All roles and the rule applies to everyone. |
| Active | Switch a rule off without deleting it while you work out whether it is doing what you meant. |
The list narrows on its filter button by Resource type, what the rule reads on the record, Match type and Active (Working with lists).
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 Stock”; a row access rule scopes that to “only the warehouses this person covers”. 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.