Even when a user has access to a record, you may want to control which fields they can see or modify. Field-level rules provide this granularity — they are the most fine-grained layer of Beelocity’s access control, operating at the individual column level.
This layer sits on top of roles, policies, and row access rules. A user must pass all four layers to see and edit a specific field on a specific record.
Field Visibility Rules
A visibility rule hides a specific field from certain users. When a visibility rule is active, the field does not appear in the interface at all — the user cannot see its value, and they have no indication that the field exists.
Hidden means hidden, and saving does not disturb it. The field is on no list, no record page and no form for that user. If they edit the record and save, the hidden field keeps the value it had — a save cannot blank out a figure they were never shown.
A redacted field behaves the same way for writing: the user sees the marker in place of the value and cannot change it.
Common Examples
| Hidden field | Who it is hidden from | Why |
|---|---|---|
| Cost price | Sales staff | They only need the selling price. Seeing cost margins could affect how they negotiate. |
| Supplier details | Users outside the procurement team | Supplier relationships are managed by procurement; other teams do not need to see who supplies what. |
| Credit limit | Warehouse workers | Financial data is irrelevant to warehouse operations and should not be visible unnecessarily. |
| Salary information | Non-HR staff | Sensitive personal data that only HR should access. |
Managing Visibility Rules
Go to Settings → Field Visibility to create and manage rules. Each rule specifies:
| Field | Description |
|---|---|
| Resource type | Which kind of record this rule applies to — products, partners, purchase orders. |
| Field | The field to hide. You pick it from a list, by the name the screens give it — Cost, Tax identifier, Notes. |
| Visibility | Visible, hidden, or redacted. |
| Redaction value | What to show in place of the value when the rule redacts it (e.g., “***”). Leave it empty and the field is simply not displayed. |
| Roles | Which role the rule binds. Leave it on All roles and the field is hidden from everyone. |
| Active | Switch a rule off without deleting it. |
The list narrows on its filter button by Resource type, Field, Visibility and Active (Working with lists).
Field Editability Rules
An editability rule makes a field read-only for certain users. Unlike visibility rules, the user can still see the field’s value — they just cannot change it. The field appears in the interface but is greyed out or locked.
Read-only means read-only. The field is disabled in the forms Beelocity draws, and if an edit reaches the server carrying a new value for it anyway, the stored value is kept. The rest of the edit still saves — only the locked field is ignored.
One limit worth knowing: this applies to editing an existing record. It does not stop someone setting the field when the record is first created.
Common Examples
| Locked field | When / for whom | Why |
|---|---|---|
| SKU | After product creation | Preventing accidental changes to the primary product identifier once it is in use across inventory and orders. |
| Purchase order amount | After approval | Preventing post-approval tampering with the order value. |
| Partner code | After first transaction | The code is referenced in historical records and changing it could cause inconsistencies. |
| Approved quantities | For non-approvers | Only the approver should be able to modify approved figures. |
Managing Editability Rules
Go to Settings → Field Editability to create and manage rules. Each rule specifies:
| Field | Description |
|---|---|
| Resource type | Which kind of record — products, purchase orders, partners. |
| Field | Which field to lock. You pick it from a list, by the name the screens give it. |
| Editable | Off means read-only, which is what these rules are usually for; the list says Editable or Read-only rather than yes or no. |
| Roles | Which role the rule binds. Leave it on All roles and the field is locked for everyone. |
| Active | Switch a rule off without deleting it. |
The list narrows on its filter button by Resource type, Field, Editable and Active.
Choosing Between Visibility and Editability
| If you want to… | Use |
|---|---|
| Completely hide a field — the user should not know the value | Visibility rule |
| Show but lock a field — the user can see the value but not change it | Editability rule |
When in doubt, lean toward editability rules. They are less restrictive (the user can still see the data) and cause less confusion than hidden fields that users might expect to exist.
Tips
- Apply the principle of least surprise — if users expect a field to be there (like “Price” on a product), making it invisible can cause confusion. Consider making it read-only instead of hidden.
- Document your rules — keep a note of why each rule exists. Field rules are powerful but can be hard to troubleshoot if you forget why a field is hidden or locked for a particular role.
- Combine with row access for defense in depth — visibility rules hide fields on records the user can see. Row access rules hide entire records. Use both together for comprehensive data protection.
- Test after creating rules — sign in as a user with the affected role and verify that the field behaves as expected (hidden or read-only).