User context (own records)
A support agent or teammate may view or edit only the records they own. The check is relationship-based: owner equals current user, or the record belongs to the same tenant or team.
Guide
Field-Level Permissions: Real Examples and Design Patterns
A field-level permission is a control on a specific field or attribute, not a blanket rule for an entire resource. It is often the difference between a role that is mostly correct and a role that is safe in practice.
Common field-level patterns
Org / tenant scoping
A user may view all invoices in their org, but only update fields for records within their assigned tenant. The allowed scope narrows the decision, not just the role.
Time-based
An approver may edit a high-risk field only during a defined review window or before a contract is finalized. The rule changes based on a time condition.
Approval status
A manager can edit a field only when the record is in draft or awaiting approval. Once approved, the field becomes read-only for that role.
Manager / hierarchy
A manager may edit the cost field for their team, but a senior admin can override the same field when a different org or hierarchy is involved. The relationship to the record matters.
Geographic or risk-based
A regional admin may only see sensitive fields for locations in their region, or a risk team may view compliance data with a higher sensitivity threshold than a general ops manager.
Real examples
- Salesforce own-accounts: a rep can edit their own account notes but not another rep’s billing data
- Healthcare org + consent: a clinician can view patient status but only a consent owner can edit sensitive consent fields
- Ecommerce vendor products: a vendor sees their own catalog fields, but not competitor pricing or internal margin data
- Banking approval limit: a manager can approve up to their threshold, while a senior approver handles larger limits
- Auditor date window: a compliance reviewer can view historical records only within an approved audit period
Design guidance
Field-level permissions should narrow access with clear conditions, not turn every role into an unmanageable custom policy. Start with role and scope, then add the field-specific exception only where it is needed. That keeps the model reviewable and preventable from becoming a full ABAC product.