Configuring Field Security For Entities

Administrators can configure Field Security to restrict specified fields for certain security roles. Field-level security provides granular control over which users can view and edit individual fields, working in conjunction with entity-level permissions to create a comprehensive security model.

Before You Begin

Requirements

To configure Field Security for Entities, users must be assigned a security role with the following permissions:

• Administrator System Role

Understanding Field Security

Field security controls access to individual fields within an entity, independent of entity-level permissions. Even if a user has read or edit permission on an entity, field-level security can restrict access to specific fields.

Field Security Levels

Read: Users can view the field value on detail pages, edit pages, and in reports.

Edit: Users can modify the field value when creating or editing records.

How Field Security Works

Field security operates as an additional layer on top of entity permissions:

1. Entity Permission First: Users must have entity-level read or edit permission
2. Field Security Second: Among users with entity permission, field security determines who can see or edit specific fields
3. Most Restrictive Wins: If either entity or field permission denies access, the user cannot access the field

Common Use Cases

• Restricting sensitive fields (salary, social security numbers) to HR roles only
• Allowing sales reps to view but not edit approval fields
• Showing different fields to different user groups
• Protecting system fields from modification by non-administrators

Configuring Field Security

To configure field security:

1. In the Setup Home page:

   • If you want to configure field security for a Magentrix Entity, click Create > Entities.
   • If you want to configure field security for a Salesforce integrated Entity, click Extend > Salesforce.

2. Click the entity you want to configure.

3. Under the More Actions dropdown box, select Field Security.

4. In the dropdown menu at the top, select the security role you want to configure.

5. For each field, check the desired settings:

   • Read: Check to allow users in this role to read (view) the field
   • Edit: Check to allow users in this role to edit the field

6. Click Save Changes.

The field security settings are now applied to the selected security role. Repeat this process for each security role that needs field-level restrictions.

Field Security Behavior

Read Permission Behavior

When a user does NOT have Read permission on a field:

• The field does not appear on detail pages
• The field does not appear on edit pages
• The field does not appear in list views
• The field cannot be included in reports by that user
• The field value is not accessible via API calls
• Formula fields referencing the field may display as blank or error

Edit Permission Behavior

When a user has Read but NOT Edit permission on a field:

• The field appears on detail pages (read-only)
• The field appears on edit pages but is read-only (grayed out)
• The field can be included in reports
• The user cannot modify the field value
• API calls can read but not write to the field

Special Field Considerations

Required Fields: If a field is required but the user lacks Edit permission, they cannot create new records or may encounter errors. Ensure required fields are editable by roles that need to create records.

Formula Fields: Formula fields are always read-only. Edit permission is not applicable.

System Fields: Fields like Created By, Created Date, Modified By, and Modified Date are automatically read-only for all users.

Master-Detail Fields: Users need Edit permission to select or change the parent record when creating or editing child records.

Field Security by Role Examples

Example 1: Salary Information

Scenario: Only HR users should see and edit employee salary fields.

Configuration:

Example 2: Approval Fields

Scenario: Sales reps can view approval status but only managers can change it.

Configuration:

Result: Sales reps see the approval status as read-only. Managers can modify the approval status.

Example 3: Discount Authorization

Scenario: All sales users can see discount percentage, but only certain roles can modify it.

Configuration:

Example 4: Partner Portal Access

Scenario: Internal users see all opportunity fields, but partner portal users see limited information.

Configuration:

Combining Field Security with Entity Permissions

Field security and entity permissions work together to control data access:

Scenario: Sales Representative Access

Entity Permissions:

• Read: Private (can only see own records)
• Edit: Private (can only edit own records)

Field Security:

• Commission Rate: Read ✓, Edit ✗
• Manager Notes: Read ✗, Edit ✗

Result:

• Sales rep sees only their own opportunities
• They can view but not edit their commission rate
• They cannot see manager notes at all
• They can edit all other fields they have permission for

Scenario: Support Manager Access

Entity Permissions:

• Read: User and All Subordinates
• Edit: User and All Subordinates

Field Security:

• All fields: Read ✓, Edit ✓

Result:

• Manager sees cases for themselves and all team members
• Manager can edit all fields on these cases
• Full visibility and control within their hierarchy

Best Practices and Recommendations

• Start with entity permissions: Configure entity-level permissions first, then refine with field security.
• Document field restrictions: Maintain clear documentation of which fields are restricted and why.
• Test thoroughly: Log in as users in different roles to verify field visibility and editability.
• Consider required fields: Ensure roles that create records can edit all required fields.
• Use consistent patterns: Apply similar field security patterns across related entities.
• Review regularly: Audit field security settings periodically to ensure they align with current business needs.
• Balance security and usability: Overly restrictive field security can hinder productivity. Find the right balance.
• Communicate restrictions: Let users know if certain fields are intentionally hidden or read-only.
• Plan for reports: Consider how field restrictions affect reporting capabilities for different users.
• Coordinate with page layouts: Hide fields on page layouts if users lack read permission to avoid confusion.
• Protect sensitive data: Always restrict fields containing PII, financial data, or confidential information.
• Consider workflow implications: Ensure field security doesn't break business processes or automation.

Troubleshooting Tips

Issue: Users cannot see a field that should be visible.

Solution: Check both entity-level read permission and field-level read permission. Also verify that the field is included on the page layout assigned to the user's role.

Issue: Users see "Insufficient Privileges" when trying to save a record.

Solution: The user likely lacks Edit permission on a required field. Either grant Edit permission or make the field optional if appropriate.

Issue: Formula field showing errors for some users.

Solution: If the formula references a field the user cannot read, it may display as blank or error. Consider the fields referenced by formulas when setting field security.

Issue: Field appears but is read-only when it should be editable.

Solution: Verify that the user has Edit permission at both the entity and field level. Also check if the field itself is read-only (like formula fields or system fields).

Issue: Report missing data for certain users.

Solution: Users can only see data in fields they have Read permission for. Grant appropriate Read permissions or create separate reports for different security roles.

Issue: Changes to field security not taking effect.

Solution: Users may need to log out and log back in for field security changes to take effect. In some cases, cache clearing may be necessary.

Issue: Cannot configure field security for a specific field.

Solution: Some system fields cannot have their security configured as they are automatically managed by the system. This includes fields like Created By, Modified By, and certain system-level fields.

Issue: User can edit field directly but not through API.

Solution: Verify that API access respects field-level security. The user's API credentials must have both entity and field permissions.

Issue: Field security settings missing for a role.

Solution: Ensure you've selected the correct security role from the dropdown at the top of the field security configuration page. Settings are role-specific.

Issue: Required field causing errors for users who cannot edit it.

Solution: Either grant Edit permission to the field for that role, or remove the Required flag from the field. Consider using validation rules instead for conditional requirements.

Interaction with Other Security Features

Page Layouts

Page layouts determine which fields appear on the page. Field security determines whether users can see or edit those fields. For best results:

• Remove fields from page layouts if users lack Read permission
• This prevents users from seeing blank spaces where hidden fields would be

Validation Rules

Validation rules apply regardless of field security. Even if a user can edit a field, validation rules may prevent certain values from being saved.

Sharing Filters

Sharing filters control record-level access. Field security controls field-level access within those visible records.

Workflow and Automation

Automated processes (workflows, triggers, etc.) may need field access that differs from user access. Consider automation requirements when setting field security.

See Also

• Configuring Entity Permissions
• Managing Entity Fields
• Designing Page Layouts
• Configuring Security Role Permissions
• About Entity Management

Jump to Magentrix Entity Checklist

<< Configuring Entity Permissions | Configuring List Layouts >>