Configuring Object-Level Security involves declaring permissions per profile and per permission set, then validating the effective access. The steps below cover the standard workflow.
- Identify the object and user population
Determine which users need access to which objects with what level. Document the matrix before configuring.
- Edit the profile
Setup > Profiles > select profile > Object Settings. For each object, set the CRUD permissions and View All/Modify All if needed.
- Create permission sets for variants
For access needs that vary among users with the same profile, create permission sets. Assign to specific users.
- Test with a sample user
Login As. Confirm the user can access the object as expected. Test create, edit, delete operations to verify CRUD permissions.
- Cross-check sharing
Object access shows records exist; sharing determines specific record visibility. Confirm sharing rules align with object access intent.
- Document the matrix
Maintain a documented profile/permission set matrix showing object access per user population. Future admins will need this.
- Audit quarterly
Review permissions periodically. View All and Modify All assignments are particularly worth verifying; over-assignment is a security risk.
View existing records. The baseline access permission.
Insert new records.
Update existing records. Implies Read.
Remove records. Implies Edit.
Override sharing to see/edit all records of the object.
- Object access without sharing shows no records. The user knows the object exists but sees an empty list view.
- Modify All bypasses sharing entirely for that object. Sensitive permission; audit assignments.
- New custom objects default to no access. Admins must explicitly add permissions; the default is intentional safety.
- Permission sets are additive. A user gets the most permissive grant across their profile and all permission sets.
- Apex "without sharing" still typically respects CRUD and FLS. The bypass is specifically for record sharing, not all security layers.