Salesforce Object Permissions: Complete Guide | SalesforceTutorial

Salesforce object permissions control what users can do with standard and custom objects in your org. These permissions determine whether users can create, read, update, or delete records, and they work alongside field-level security to create a comprehensive data protection model.

Object permissions are assigned through profiles and permission sets, forming the foundation of Salesforce’s security architecture. Understanding how to configure these permissions correctly is essential for maintaining data integrity while enabling users to perform their job functions.

What is a Salesforce Object?

A Salesforce object is a database table that stores specific types of data in your org. Objects contain fields (columns) and records (rows), similar to tables in a traditional database.

Standard objects come pre-built with Salesforce and include:

• Account – Companies and organizations
• Contact – Individual people
• Opportunity – Sales deals and prospects
• Lead – Potential customers
• Case – Customer service requests
• Product – Items your company sells

Custom objects are created by administrators to store data specific to your business needs. They always end with “__c” (like “Property__c” or “Invoice__c”).

Understanding Object Permissions in Salesforce

Object permissions define the baseline access users have to objects. These permissions are binary – users either have them or they don’t. The four core object permissions are:

Additional permissions include:

• View All – See all records regardless of sharing rules
• Modify All – Edit and delete all records regardless of sharing rules

How to Create Object Permissions in Salesforce

Object permissions are configured in two places: profiles and permission sets. Here’s how to set them up:

Setting Permissions in Profiles

1. Navigate to Setup → Users → Profiles
2. Select the profile you want to modify
3. Click Object Settings or scroll to Standard Object Permissions / Custom Object Permissions
4. Find your target object and click Edit
5. Check the appropriate permission boxes (Read, Create, Edit, Delete)
6. Configure field-level security if needed
7. Click Save

Setting Permissions in Permission Sets

1. Go to Setup → Users → Permission Sets
2. Select an existing permission set or create a new one
3. Click Object Settings
4. Choose your object and click Edit
5. Enable the required permissions
6. Save your changes
7. Assign the permission set to users

Salesforce Profile Permissions Best Practices

When configuring profile permissions, follow these production-tested guidelines:

Principle of Least Privilege

Grant users only the minimum permissions needed to perform their job functions. Start with restrictive permissions and add access as needed rather than starting with broad access and removing it.

Use Permission Sets for Exceptions

Keep profiles focused on job roles and use permission sets for:

• Temporary access grants
• Cross-functional responsibilities
• Project-specific permissions
• Integration user access

Standard vs Custom Object Considerations

Standard objects often have dependencies. For example:

• Contact permissions require Account read access
• Opportunity permissions need Account read access
• Case permissions may require Contact and Account access

Custom objects have fewer built-in dependencies but may have lookup relationships that require read access to parent objects.

Data Loader and Object Permissions

When an administrator plans to use Data Loader to mass import new records to a custom object from a new API, they need specific permissions:

Required Object Permissions

• Read permission on the target custom object
• Create permission on the target custom object
• Edit permission if updating existing records

Additional Requirements

• API Enabled permission in the user profile
• Field-level security set to “Visible” and “Editable” for all fields being imported
• Read access to any parent objects referenced in lookup fields
• Bulk API permissions if using Bulk API mode

Integration User Setup

For API integrations, create a dedicated integration user with:

// Example permission set for Data Loader integration
{
  "objectPermissions": {
    "CustomObject__c": {
      "read": true,
      "create": true,
      "edit": true,
      "delete": false
    }
  },
  "systemPermissions": [
    "ApiEnabled",
    "BulkApiHardDelete"
  ]
}

Salesforce Object Relationship Types and Permissions

Object relationships affect how permissions cascade through your data model:

Lookup Relationships

Lookup relationships are loosely coupled. Users need:

• Read permission on both parent and child objects
• Create/Edit permission on child object to create relationships
• No automatic permission inheritance

Master-Detail Relationships

Master-detail relationships are tightly coupled:

• Child records inherit sharing from parent records
• Users need Read permission on master object to see detail records
• Delete permission on master object allows deletion of detail records
• Detail records cannot exist without a master record

Hierarchical Relationships

Available only on User object:

• Used for manager-subordinate relationships
• Affects role hierarchy and sharing rules
• No special permission requirements beyond standard User object access

Common Object Permission Scenarios

Sales Team Configuration

// Sales Representative Profile
Account: Read, Create, Edit
Contact: Read, Create, Edit  
Opportunity: Read, Create, Edit, Delete
Lead: Read, Create, Edit, Delete
Product: Read
Pricebook: Read

Customer Service Configuration

// Service Agent Profile
Account: Read, Edit
Contact: Read, Create, Edit
Case: Read, Create, Edit, Delete
Solution: Read
Product: Read

Marketing Team Configuration

// Marketing User Profile
Lead: Read, Create, Edit, Delete
Campaign: Read, Create, Edit, Delete
Account: Read
Contact: Read, Create, Edit
Opportunity: Read

Troubleshooting Object Permission Issues

Common Error Messages

“Insufficient Privileges” – User lacks required object permission or field-level security access.

“Unable to Lock Row” – Record is being edited by another user or process. Not a permission issue.

“Field is Not Writable” – Field-level security prevents editing, even with object Edit permission.

Permission Debugging Steps

1. Check the user’s profile object permissions
2. Review assigned permission sets
3. Verify field-level security settings
4. Confirm sharing rule access
5. Test with “View Setup and Configuration” permission to see effective permissions

Security Best Practices

Regular Permission Audits

Conduct quarterly reviews of:

• Profile assignments and permissions
• Permission set assignments
• Inactive user access
• Integration user permissions

Documentation Standards

Maintain documentation for:

• Profile purpose and intended users
• Permission set business justification
• Custom object permission requirements
• Integration user access patterns

Testing Procedures

Before deploying permission changes:

• Test in a sandbox environment
• Verify with actual user accounts
• Check integration functionality
• Document rollback procedures