Field Visibility and Editability
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.
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 Access Control > Field Visibility Rules to create and manage rules. Each rule specifies:
| Field | Description |
|---|---|
| Resource | Which record type this rule applies to (e.g., Product, Partner, Purchase Order). |
| Field | The specific field to hide (e.g., “cost_price”, “credit_limit”). |
| Role | Which role this rule applies to — users with this role will have the field hidden. |
| Redaction value | Optionally, what to show in place of the hidden value (e.g., “***” or “RESTRICTED”). If not set, the field is simply not displayed. |
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.
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 Access Control > Field Editability Rules to create and manage rules. Each rule specifies:
| Field | Description |
|---|---|
| Resource | Which record type (e.g., Product, Purchase Order, Partner). |
| Field | Which specific field to make read-only. |
| Role | Which role this rule applies to — users with this role will see the field as read-only. |
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).