Settings¶

Standards for org settings metadata: what is tracked, what is environment-specific, and how settings changes are reviewed.

Every settings file is Tier 1 metadata. One settings file changes the behaviour of the whole org, so the architect team reviews every change to one, whatever the setting.

Lightning Web Security¶

Lightning Web Security is switched on, and Lightning Locker is not used. Lightning Web Security is the security architecture for Lightning components that replaces Lightning Locker, and it keeps the components of one namespace from reaching the resources of another, which is the principle of least privilege (PLP) applied to components (Lightning Web Security). What a component does to work under it is on the Lightning Web Components and Aura page.

• The Security settings file does not switch Lightning Web Security off, and does not switch off the stricter Content Security Policy that it depends on. The settings are lockerServiceNext, which is one switch for both architectures (true is Lightning Web Security, false is Lightning Locker), and lockerServiceCSP, both in the session settings (SecuritySettings); a value of false in either is reported at severity 3. Enforced by LightningWebSecurityNotEnabled.
• Where an org uses Lightning Out, Lightning Out 2.0 is recommended, because it runs with Lightning Web Security; Lightning Out (beta) requires Lightning Locker, and Lightning Web Security is not supported with it (How Lightning Out 2.0 Compares to Lightning Out (Beta)). An organisation may allow the beta for a use that needs it, with a suppression and a documented reason. Lightning Out is not a setting: the beta shows in an Aura application that extends ltng:outApp and in a Visualforce page that uses apex:includeLightning, and both are reported and do not block (Aura, Lightning Out in Visualforce).
• An Aura component below API version 40.0 runs with Lightning Locker off, and the Aura standards hold it to 40.0 or later.
• After Lightning Web Security is switched on, data that components saved in the browser's local or session storage under Lightning Locker is unreadable, and the reverse: a component rewrites what it needs (Local Storage Limitations).

A settings file in version control is often partial, so a file that leaves the element out says nothing about the org, and the rule does not report it.

Lightning Out has three uses, and they differ in what they run and in the security architecture they need (How Lightning Out 2.0 Compares to Lightning Out (Beta), Use Components in Visualforce Pages):

Deploy Flows as Active¶

A production org deploys processes and Flows as active. The setting is Deploy processes and flows as active, on the Process Automation Settings page in Setup, and in metadata it is enableFlowDeployAsActiveEnabled in the Flow settings (FlowSettings). It is off by default in a production org, and on in a sandbox, a scratch org, and a Developer Edition org.

• The setting is switched on in production. While it is off, every process and Flow that a deployment brings arrives inactive, and someone activates each one by hand in Setup. With it on, the pipeline delivers a Flow in the state that the repository records, which is what the standard that a Flow is activated relies on.
• The Flow settings file does not switch the setting off. A value of false is reported at severity 3. Enforced by FlowDeployAsActiveNotEnabled. As with Lightning Web Security, a file that leaves the element out is not reported.

With the setting on, a deployment of an active process or Flow to production runs the Apex tests. If the tests do not launch the org's required percentage of its active processes and autolaunched Flows, the deployment is rolled back.

Custom Settings and Custom Metadata Types¶

A custom setting and a custom metadata type both hold values that Apex, Flows, formulas, and validation rules read. They differ in where the values live. The records of a custom metadata type are metadata: they are deployed from version control, like the type itself. The records of a custom setting are data, made in each org (Create Custom Settings). Each value goes in the one place that suits it.

• A secret, such as a password, a token, or a client secret, is kept in an External Credential, which holds how Salesforce authenticates to an external system; the Named Credential that uses it holds only the endpoint (Create Named Credentials and External Credentials). It is never kept in a custom setting, and never in a custom metadata type. Outside a managed package, a protected custom metadata type behaves like a public one, and a public one is readable for all profiles, including the guest user (Protection and Privacy Options for Custom Metadata Types). The one exception is an organisation that maintains its own security-focused managed package: a protected custom metadata type installed by that package may hold a secret. A field whose name suggests a credential is reported on any custom setting or custom metadata type, whatever its visibility, and blocks the pull request (severity 2). Enforced by the Java rule NoCredentialNamedField.
• An org-wide value that is not a secret is kept in a custom metadata type. Its records come from version control and change only through a reviewed PR, so every org gets the same values. A custom metadata type also has the best built-in access control: the Schema Settings option Restrict access to custom metadata types is on by default, and a user reads a type only when a profile or permission set grants it (Control Read Access to Custom Metadata Types).
• A hierarchy custom setting is used only for values that differ by user or by profile. A value that is the same for everyone goes in a custom metadata type. The records of a hierarchy custom setting are configuration data, and they follow the Configuration Data standard.
• No new list custom setting is created. Salesforce suggests a custom metadata type instead, because the records of a list custom setting cannot be migrated with packages or Metadata API tools (Create Custom Settings). An existing list custom setting is kept. The rule reports each list custom setting definition, an existing one too, and blocks the pull request (severity 2). Enforced by NoListCustomSetting.

Rules¶

The rules that this page mentions. The Standard column gives each rule's standard in one line, and the Section column links to the section that mentions the rule; "Not yet written" marks a rule of this page that no section mentions yet. Appendix F.6 holds the full cross-reference.