Enforce Object and Field Permissions
Enforce User Mode
To enforce field-level security and object permissions of the current user, you can specify user mode access for database operations and SOQL queries. See Enforce User Mode for Database Operations.
Check Field-Level Permissions
You can also enforce object-level and field-level permissions in your code by explicitly calling the access control methods of the Schema.DescribeSObjectResult and the Schema.DescribeFieldResult classes. These methods check the current user's access permission levels so that you can perform a specific DML operation or a query only if the user has sufficient permissions.
For example, you can call the isAccessible, isCreateable, or isUpdateable methods of Schema.DescribeSObjectResult to verify whether the current user has read, create, or update access to an sObject, respectively. Similarly, Schema.DescribeFieldResult exposes these access control methods that you can call to check the current user's read, create, or update access for a field. In addition, you can call the isDeletable method provided by Schema.DescribeSObjectResult to check if the current user has permission to delete a specific sObject.
These examples call the access control methods.
if (Schema.sObjectType.Contact.fields.Email.isUpdateable()) {
// Update contact
}
if (Schema.sObjectType.Contact.fields.Email.isCreateable()) {
// Create new contact
}
if (Schema.sObjectType.Contact.fields.Email.isAccessible()) {
Contact c = [SELECT Email FROM Contact WHERE Id= :Id];
}
if (Schema.sObjectType.Contact.isDeletable()) {
// Delete contact
}
Considerations
- Object-level and field-level permissions are distinct from sharing rules, which enforce specific record access. They can coexist. If sharing rules are defined in Salesforce, you can enforce them at the class level by declaring the class with the with sharing keyword. See Use the with sharing, without sharing, and inherited sharing Keywords. If you call the Schema.DescribeSObjectResult and Schema.DescribeFieldResult access control methods, the verification of object and field-level permissions is performed in addition to the sharing rules that are in effect. Sometimes, the access level granted by a sharing rule can conflict with an object-level or field-level permission. In that case, object-level and field-level permissions take precedence over sharing rules.
- Orgs with Experience Cloud sites enabled provide various settings to hide a user's personal information from other users. See Manage Personal User Information Visibility and Share Personal Contact Information Within Experience Cloud Sites. These settings aren’t enforced in Apex, even with security features such as the WITH USER_MODE clause or the stripInaccessible method. To hide specific fields on the User object in Apex, follow the example code outlined in Comply with a User’s Personal Information Visibility Settings.
- Automated Process users can’t perform Object and FLS checks in custom code unless appropriate permission sets are explicitly applied to those users.