Protection and Privacy Options for Custom Settings
Manage the visibility and permissions of custom settings.
Required Editions
| Available in: Salesforce Classic and Lightning Experience. |
Available in: Group, Professional, Developer, Enterprise, Performance, Unlimited, and Database.com Editions. Packages aren’t available in Database.com. |
Packages
Only custom settings definitions are included in packages, not data. To include data, populate the custom settings using a standard Apex or API script run by the subscribing organization after they install the package.
When a custom setting is contained in a managed package, and the visibility is set to Protected, access is allowed only through the Apex code that is part of that managed package. Subscriber organizations can’t directly access, read, or modify the protected custom settings.
Protected custom settings in an unmanaged package behave like public custom settings. Make sure that secrets, personally identifying information, or any private data are stored in protected custom metadata types that are installed as part of a managed package. Outside of a managed package, use named credentials or encrypted custom fields to store secrets like OAuth tokens, passwords, and other confidential material.
Visibility
You can create protected custom settings in developer and scratch orgs. The options for custom settings are.
- Protected—Custom settings in a managed package are visible through Apex and formulas within the same package and namespace. However, they are not visible to subscribing organizations through Apex and API. Custom settings contained in an unmanaged package behave like public custom settings and don’t provide protection.
- Public—Regardless of the type of package (managed or unmanaged), the
following have access:
- Apex
- Formulas
- Flows
- API for users with Customize Application permission or permissions granted through profiles or permission sets.
Schema Settings
The schema setting options for custom settings are.
- Restrict access to custom settings—This org-wide preference is enabled by default and limits access to custom setting values. Admins with Customize Application permission can grant Read access to users through profiles and permission sets using the Custom Setting Definitions or View All Custom Settings permissions.
- Enable SOSL on custom settings—Custom settings values are not returned in Salesforce Object Search language (SOSL) queries. If your Apex operations require this functionality, enable this option.
Grant Permissions on Profiles or Permission Sets
The Restrict access to custom settings org-wide preference is enabled by default and Read access to custom settings must be explicitly granted.
Admins with Customize Application permission can grant Read permission through profiles and permission sets to users without the Customize Application permission.
- To grant permission to specific custom settings, use the Custom Setting Definitions permission.
- To grant permission to all custom settings, use the View All Custom Settings permission.
Behavior of Apex, Visualforce, and Aura
There are different execution code modes within Salesforce that affect the accessibility of custom settings.
Apex code that is run in system mode ignores user permissions and your Apex code is given access to all objects and fields. Object permissions, field-level security, and sharing rules aren't applied for the current user. Running in system mode ensures that the code doesn’t fail because of hidden fields or objects for a user.
In user mode, functionality such as Visualforce Components, Visualforce Email templates, and Aura, is run with respect to the user's permissions and sharing of records.
with sharing modifier in the Apex class, doesn’t
affect query behavior such as, isAccessible() and isCreatable(). If a field value is retrieved in Apex and assigned to a
non-sObject variable, the behavior is the same whether the preference is enabled or
not.When functionality is run in user mode, such as Visualforce Components, Visualforce
Email templates, and Aura, you must have permission to access the custom settings.
For example, without permission, the fields on Visualforce pages that you don't have
access to aren’t displayed. The $Setup
global variable (available in Visualforce and formulas) continues to load values by
direct reference (meaning, data that is assigned to an sObject type) regardless of
the running user.
Consider the following scenario:
- Apex loads a record that is a row included in a variable such as
MySetting__c. - What Visualforce displays is
MySetting__c.MyPath__c. - Access checks are run when the page is loaded.
- However, the checks are not run in system mode, which is the standard Visualforce behavior. Users without permission to the custom settings can’t display the Visualforce page because Visualforce is reinitiating the access check.
In this scenario, if a user isn’t allowed permission to the custom setting, there are
two workarounds. You can create a string for each object, which can be passed
through, or create a wrapper class. Use these options instead of assigning a
variable such as MySetting__c, then
rendering mySetting.Path__c mySetting.Name.
For example,
class DataHolder{
public string path {get;set;}
public boolean active {get;set;}
}When you load the rows into a collection, the Visualforce checks are bypassed because the type is a data type instead of an sObject.
Here’s an example that includes the @AuraEnabled annotation for an Aura or Lightning components
controller.
class with sharing MyController {
@AuraEnabled
public static List<My__mdt> thisWillNotWork() {
return [select developername from my__mdt];
}
@AuraEnabled
public static List<String> thisWill() {
List<String> retVal = new List<String>();
for(My__mdt config: [select developername from my__mdt]) {
retVal.add(config.DeveloperName);
}
return retVal;
}
}