---
title: "Row Access Rules"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](roles-and-permissions.html) 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](roles-and-permissions.html) and [policies](policies.html).

## 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](hierarchy-and-delegations.html)). 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](hierarchy-and-delegations.html); if they should see everything instead, leave them out of the rule's role.

Rules are evaluated alongside [policies](policies.html) and [roles](roles-and-permissions.html). 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](../getting-started/working-with-lists.html#narrowing-the-list)).

## 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.

Source: https://docs.beelocity.com/en/access-control/row-access-rules/index.mdx