Configuring Entity Permissions
Administrators can configure Read, Create, Edit, and Delete permissions for entities based on security roles. Administrators can use hierarchy permissions to allow users access to entities owned by or shared with users below them in the role hierarchy. For more information regarding role hierarchy, see About Manager Hierarchy.
Before You Begin
Requirements
To configure entity permissions, users must be assigned a security role with the following permissions:
- Administrator System Role
Understanding Entity Permissions
Entity permissions control which records users can view, create, modify, and delete within an entity. These permissions work in conjunction with field-level security and sharing rules to provide comprehensive access control.
Permission Types
Read: Determines which records users can view Create: Determines whether users can create new records Edit: Determines which records users can modify Delete: Determines which records users can delete
Permission Levels
Entity permissions can be set to different levels that control the scope of access:
None or No: Users have no permissions for this action.
All: Users have permissions for this action on all objects in the entity.
User and Direct Subordinates: Users have permissions for personally created or owned records, as well as the records of Users one hierarchical level below.
User and All Subordinates: Users have permissions for personally created or owned records, as well as the records of all Users below their hierarchical level.
Team: Users have permissions for personally created or owned records, as well as the records of their Manager and those on an equal hierarchical level.
Team and Direct Subordinates: Users have permissions for personally created or owned records, as well as the records of their Manager, equal-level Users, and Users of one hierarchical level below.
Team and All Subordinates: Users have permissions for personally created or owned records, as well as the records of their Manager, equal-level Users, and Users of all hierarchical levels below.
Private: Users only have permissions for this action on objects they personally created or own.
Controlled By Parent: User permissions for this Entity are determined by a parent Entity. This option is available for child entities in a Master-Detail relationship.
Important: Depending on the security role, not all options described above are selectable. Some permission levels require specific role hierarchy settings to be available.
Using Hierarchy Permissions
Hierarchy permissions leverage the organization's role hierarchy to grant access to records owned by or shared with users in subordinate positions. When the "Use Hierarchy" option is enabled, users can access records based on their position in the hierarchy.
How Hierarchy Permissions Work
When hierarchy permissions are enabled:
- Users can access their own records (based on the permission level)
- Users can access records owned by users below them in the hierarchy (based on the permission level)
- The specific access depends on the permission level selected (Direct Subordinates vs All Subordinates)
When to Use Hierarchy Permissions
Use hierarchy permissions when:
- Managers need visibility into their team's records
- Directors need to see all records within their department
- The organization has a clear management structure
- You want to simplify sharing rules by leveraging organizational hierarchy
Configuring Entity Permissions
To configure entity permissions:
In the Setup Home page, click Create > Entities.
Click the entity you want to configure.
In the More Actions dropdown box, select Permissions.
Select a setting for Read, Create, Edit, and Delete permissions for each security role:
For Read permissions, choose from:
- None
- Private
- User and Direct Subordinates
- User and All Subordinates
- Team
- Team and Direct Subordinates
- Team and All Subordinates
- All
- Controlled By Parent (for child entities)
For Create permissions, choose from:
For Edit permissions, choose from:
- None
- Private
- User and Direct Subordinates
- User and All Subordinates
- Team
- Team and Direct Subordinates
- Team and All Subordinates
- All
- Controlled By Parent (for child entities)
For Delete permissions, choose from:
- None
- Private
- User and Direct Subordinates
- User and All Subordinates
- Team
- Team and Direct Subordinates
- Team and All Subordinates
- All
- Controlled By Parent (for child entities)
If you would like to use hierarchy permissions, check the Use Hierarchy box.
Click Save.
Alternative Method: You may also change Entity permissions directly in the Security Role menu. See Configuring Security Role Permissions.
Understanding Controlled By Parent
The "Controlled By Parent" permission setting is available for child entities in a Master-Detail relationship. When this option is selected:
- The child entity's permissions are determined by the parent entity's permissions
- If a user can read the parent record, they can read the child records
- If a user can edit the parent record, they can edit the child records
- This simplifies permission management for tightly related entities
Example Scenario
Entities: Order (parent) and Order Line Item (child with Master-Detail to Order)
Configuration:
- Order Read: Team and All Subordinates
- Order Line Item Read: Controlled By Parent
Result: Users who can read Orders based on team hierarchy automatically have read access to the Order's Line Items, without needing separate permission configuration.
Permission Levels in Practice
Example 1: Sales Organization
Scenario: Sales representatives should see their own opportunities, managers should see their team's opportunities, and directors should see all opportunities in their division.
Configuration:
Sales Rep Role:
- Read: Private
- Edit: Private
- Delete: None
- Use Hierarchy: Checked
Sales Manager Role:
- Read: User and Direct Subordinates
- Edit: User and Direct Subordinates
- Delete: Private
- Use Hierarchy: Checked
Sales Director Role:
- Read: User and All Subordinates
- Edit: User and All Subordinates
- Delete: User and Direct Subordinates
- Use Hierarchy: Checked
Example 2: Support Case Management
Scenario: Support agents should see all cases, but only edit their own. Supervisors should be able to edit any case.
Configuration:
Support Agent Role:
- Read: All
- Create: Yes
- Edit: Private
- Delete: None
Support Supervisor Role:
- Read: All
- Create: Yes
- Edit: All
- Delete: Private
Example 3: Project and Tasks
Scenario: Project records control access to their related Task records.
Configuration:
Result: Task access automatically follows Project access without separate configuration.
Interaction with Other Security Features
Entity permissions work together with other security features:
Field-Level Security
Even if a user has Read access to an entity, field-level security can restrict specific fields. Users must have both entity permissions and field permissions to view or edit data.
Sharing Filters
Sharing filters provide additional record-level restrictions beyond entity permissions. A user might have "All" read permission on an entity, but sharing filters can restrict access to specific records based on criteria.
Page Layout Assignments
Different security roles can be assigned different page layouts, controlling which fields and sections users see even if they have underlying permissions.
Validation Rules
Validation rules apply regardless of permission levels. All users must satisfy validation rules when creating or editing records.
Best Practices and Recommendations
- Start restrictive: Begin with minimal permissions and expand as needed. It's easier to grant access than to restrict it later.
- Use hierarchy when appropriate: Leverage organizational hierarchy for natural access patterns rather than creating complex sharing rules.
- Document permission strategy: Maintain clear documentation of why each role has specific permission levels.
- Test with actual users: Log in as users in different roles to verify permissions work as intended.
- Review permissions regularly: Audit entity permissions periodically to ensure they align with current business needs.
- Consider the full security model: Remember that entity permissions work with field security, sharing filters, and other controls.
- Use Controlled By Parent strategically: For tightly coupled entities, this simplifies management significantly.
- Plan for exceptions: Use sharing rules to grant additional access for specific scenarios beyond base permissions.
- Align Create and Edit permissions: Users who can create records typically need to edit them as well.
- Be cautious with Delete permissions: Deletion is permanent. Restrict delete permissions more than edit permissions.
- Communicate changes: Notify users when permissions change, especially if access is being restricted.
Troubleshooting Tips
Issue: Users cannot see any records in an entity.
Solution: Verify that the user's security role has at least Private read permission. Also check that field-level security allows the user to read key fields like Name.
Issue: Users can see records but cannot edit them.
Solution: Check both entity-level edit permissions and field-level security. Users need edit permission at both levels to modify records.
Issue: Manager cannot see subordinate records despite hierarchy permissions.
Solution: Verify that "Use Hierarchy" is checked and that the manager is properly configured in the user hierarchy. Check that the manager role has appropriate permission levels (User and Direct/All Subordinates).
Issue: Controlled By Parent not working as expected.
Solution: Verify that a Master-Detail relationship exists between the entities. Controlled By Parent only works with Master-Detail, not Lookup relationships.
Issue: Users see "Insufficient Privileges" error.
Solution: This typically means the user lacks Read permission on the entity or a related entity required by the operation. Check permissions on the entity and any related entities referenced in lookups or master-detail fields.
Issue: Delete permission not working even though set to All.
Solution: Check if there are validation rules or triggers preventing deletion. Also verify that the user has delete permission on any child records in Master-Detail relationships.
Issue: Hierarchy permissions applying too broadly.
Solution: Review the permission level selected. "User and All Subordinates" grants access to all levels below, which may be broader than intended. Use "User and Direct Subordinates" for more limited access.
Issue: Users can create records but cannot view them after creation.
Solution: Users need Read permission to view records, even those they create. Ensure Create permission is paired with at least Private read permission.
Issue: Permission changes not taking effect.
Solution: Users may need to log out and log back in for permission changes to take effect. In some cases, it may take a few minutes for changes to propagate.
Issue: Cannot set specific permission level for a role.
Solution: Some permission levels are only available for certain role types or hierarchy positions. Review the role configuration and hierarchy setup.
See Also
Jump to Magentrix Entity Checklist
<< Configuring Magentrix Entity Picklists | Configuring Field Security For Entities >>