Custom Field Permissions

April 23, 2026

Field-Level Permissions #

Control field access with role-based permissions for enhanced security and team collaboration.

Overview #

PloverCRM provides granular field-level permissions at three levels: Create, Read, and Update. Combined with ownership scopes, this enables:

  • Protecting sensitive data (contract values, internal notes)
  • Controlling who can modify critical fields
  • Giving teams access to relevant fields only
  • Maintaining compliance and preventing accidental changes

Prerequisites: Super Admin role, understanding of PloverCRM roles

Permission Types #

Create Permission

Controls: Setting a field value when creating new contacts (UI, API, forms, imports)

Example: A sales rep can set “Lead Source” but not “Contract Value” on new contacts.

Read Permission

Controls: Viewing field values (UI, API, exports, mobile app)

Example: A support agent sees email but not contract values.

Note: Without read permission, the field is completely hidden.

Update Permission

Controls: Modifying field values on existing contacts (UI, API, bulk operations)

Example: A sales rep can update lead status but not contract terms.

Note: Update requires read permission to be useful. Fields appear disabled without update permission.

Permissions + Ownership #

Both conditions must be met for field access:

  • To READ: Must have read permission + can view the contact (view scope)
  • To UPDATE: Must have update permission + can update the contact (update scope)
  • To CREATE: Must have create permission

Example Scenarios:

Sales Rep (View: Owned, Update: Owned)
+ Contract Value (Read: ✓, Update: ✗)
= Can see Contract Value on own contacts, cannot edit

Sales Manager (View: All, Update: All)
+ Contract Value (Read: ✓, Update: ✓)
= Can see and edit Contract Value on all contacts

Support Agent (View: All, Update: All)
+ Contract Value (Read: ✗)
= Cannot see Contract Value on any contact

Configuring Permissions #

Access Role Manager

  1. PloverCRM → Settings → Role Manager
  2. Click Create New Role or edit an existing role
  3. Configure basic settings (name, scopes, delete permission)
  4. Set field permissions using checkboxes
  5. Save role

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

PatternCreateReadUpdate
Full Access✓✓✓
Read-Only✗✓✗
Create Once✓✓✗
No Access✗✗✗

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)

Read-Only Fields #

Field-Level Read-Only: Set on the field itself; applies to all roles (except Super Admin). Use for calculated or system fields.

Permission-Based Read-Only: Set per role in Role Manager. Use for business logic restrictions.

Example:

Field: Lead Score
Option 1 - Field readonly: true → No one can edit
Option 2 - Permission-based → Sales reps read-only, managers can edit

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 a screenshot of an existing role’s permissions when creating similar roles.

Best Practices #

Design Principles:

  • Principle of least privilege (grant the 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:

  1. Create a test user with the new role
  2. Test create, read, and update operations
  3. Verify scope restrictions
  4. Test API access
  5. Document results before deploying

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 is not read-only.

API Permission Denied: Verify API user has a role, check field permissions, ensure user can access the contact.

Changes Not Taking Effect: Have user refresh or log out, verify the correct role was edited, check if user is Super Admin.

Mobile App #

Permissions apply to the mobile app identically. Restricted fields are not downloaded to the device, and offline edits respect cached permissions.

Last updated: February 3, 2026

Updated on April 23, 2026
What are your Feelings