Control field access with role-based permissions for enhanced security and team collaboration.
[Screenshot: Role Manager showing field permissions matrix]
Overview #
PloverCRM provides granular field-level permissions at three levels: Create, Read, and Update. Combined with ownership scopes, this enables:
- Protect sensitive data (contract values, internal notes)
- Control who can modify critical fields
- Give teams access to relevant fields only
- Maintain compliance and prevent accidental changes
Prerequisites: Super Admin role, understanding of PloverCRM roles
Permission Types #
Create Permission #
Controls: Setting field value when creating new contacts (UI, API, forms, imports)
Example: Sales rep can set “Lead Source” but not “Contract Value” on new contacts.
[Screenshot: Create contact form showing available fields based on permissions]
Read Permission #
Controls: Viewing field values (UI, API, exports, mobile app)
Example: Support agent sees email but not contract values.
Note: Without read permission, field is completely hidden.
[Screenshot: Contact view with some fields hidden based on permissions]
Update Permission #
Controls: Modifying field values on existing contacts (UI, API, bulk operations)
Example: Sales rep can update lead status but not contract terms.
Note: Update requires read permission to be useful. Fields appear disabled without update permission.
[Screenshot: Edit form with read-only fields grayed out]
Permissions + Ownership #
Both conditions must be met for field access:
To READ: Must have read permission + can view contact (view scope) To UPDATE: Must have update permission + can update contact (update scope) To CREATE: Must have create permission
Example Scenarios:
Sales Rep (Vi<span class="hljs-symbol">ew:</span> Owned, Upda<span class="hljs-symbol">te:</span> Owned)
+ Contract <span class="hljs-built_in">Value</span> (Re<span class="hljs-symbol">ad:</span> ✓, Upda<span class="hljs-symbol">te:</span> ✗)
= Can see Contract <span class="hljs-built_in">Value</span> on own contacts, cannot edit
Sales Manager (Vi<span class="hljs-symbol">ew:</span> All, Upda<span class="hljs-symbol">te:</span> All)
+ Contract <span class="hljs-built_in">Value</span> (Re<span class="hljs-symbol">ad:</span> ✓, Upda<span class="hljs-symbol">te:</span> ✓)
= Can see <span class="hljs-built_in">and</span> edit Contract <span class="hljs-built_in">Value</span> on all contacts
Support Agent (Vi<span class="hljs-symbol">ew:</span> All, Upda<span class="hljs-symbol">te:</span> All)
+ Contract <span class="hljs-built_in">Value</span> (Re<span class="hljs-symbol">ad:</span> ✗)
= Cannot see Contract <span class="hljs-built_in">Value</span> on any contact
[Screenshot: Permission decision flowchart]
Configuring Permissions #
Access Role Manager #
- PloverCRM → Settings → Role Manager
- Click Create New Role or edit existing role
- Configure basic settings (name, scopes, delete permission)
- Set field permissions using checkboxes
- Save role
[Screenshot: Role Manager interface with permission checkboxes]
Permission Matrix #
Columns: Field name, Create, Read, Update Rows: One per field (standard fields first, then custom fields) Bulk Actions: Select All, Deselect All, Column Toggle
Common Permission Patterns #
Full Access: Create ✓, Read ✓, Update ✓ Read-Only: Create ✗, Read ✓, Update ✗ Create Once: Create ✓, Read ✓, Update ✗ No Access: Create ✗, Read ✗, Update ✗
[Screenshot: Permission patterns examples in Role Manager]
Common Scenarios #
Sales Representative #
View: Owned | Update: Owned | Delete: No
Standard fields: Full access to email, name, phone, company Custom fields:
- Lead Source: Create ✓, Read ✓, Update ✗ (set once)
- Lead Status: Full access
- Lead Score: Read-only
- Contract Value: No access (hidden)
- Sales Notes: Full access
Sales Manager #
View: All | Update: All | Delete: Yes
All fields: Full access
Support Agent #
View: All | Update: All | Delete: No
Standard fields: Read-only Custom fields:
- Support Tier, Last Support Date, Support Notes: Full access
- Contract Value: No access (hidden)
- Lead Status: Read-only
Marketing Team #
View: All | Update: All | Delete: No
Standard fields: Email read-only, lists/tags full access Custom fields:
- Marketing Opt-in, Engagement Score, Last Campaign: Full access
- Lead Status: Read-only
- Contract Value: No access (hidden)
[Screenshot: Example role configuration for Sales Representative]
Read-Only Fields #
Field-Level Read-Only: Set on field itself, applies to ALL roles (except Super Admin). Use for calculated/system fields.
Permission-Based Read-Only: Set per role in Role Manager. Use for business logic restrictions.
Example:
Field: Lead <span class="hljs-keyword">Score</span>
Option 1 - Field readonly: true → <span class="hljs-keyword">No</span> <span class="hljs-keyword">one</span> can <span class="hljs-keyword">edit</span>
Option 2 - Permission-based → Sales reps <span class="hljs-keyword">read</span>-only, managers can <span class="hljs-keyword">edit</span>
Super Admin Role #
- Bypasses ALL permission checks
- Implicit full access to all fields
- Cannot be restricted or deleted
- Use for: System admins, business owners, CRM managers
- Limit to 1-3 trusted users
New Fields & Roles #
New Custom Fields: Have NO permissions by default. After creating, edit each role to grant permissions.
New Roles: Start with no permissions. Use “Select All” then uncheck sensitive fields.
Tip: Take screenshot of existing role’s permissions when creating similar roles.
[Screenshot: New field with no permissions warning]
Best Practices #
Design Principles:
- Principle of least privilege (grant minimum needed)
- Role-based, not user-based
- Separate concerns by team
- Progressive access (junior → senior)
Security:
- Protect sensitive data (financial, personal, internal)
- Quarterly permission audits
- Proper onboarding/offboarding process
- Compliance documentation (GDPR, HIPAA)
Testing:
- Create test user with new role
- Test create, read, update operations
- Verify scope restrictions
- Test API access
- Document results before deploying
[Screenshot: Permission testing checklist]
Troubleshooting #
Field Not Visible: Check read permission, verify role assignment, check view scope, verify field is active
Field Read-Only: Check update permission, verify update scope, check field-level readonly setting
Cannot Create with Field: Check create permission, verify field not read-only
API Permission Denied: Verify API user has role, check field permissions, ensure can access contact
Changes Not Taking Effect: User refresh/logout, verify correct role edited, check if Super Admin
Mobile App #
Permissions apply to mobile app identically. Restricted fields not downloaded to device. Offline edits respect cached permissions.
Related Documentation #
Last updated: February 3, 2026
