Objects and Fields¶

Standards for the data model: objects, fields, validation rules, record types, and picklists, including naming and descriptions.

Naming¶

A name is read far more often than it is written, by every person who builds a report, writes a formula, or reads the code, so it says what the thing is, and it says it the same way as the names beside it.

• Every object name and field name starts with a capital letter, and so does every label; so does the name of a Flow, which the same rules read. A custom field, custom object, or Flow whose API name starts with a lower-case letter blocks the pull request (severity 2), because a name is hard to change once the component is referenced; a label that starts with one is reported at severity 3, because a label can be changed at any time. Both rules take the metadata types they read from a property, so an organisation adds a type to cover it. A name with a namespace prefix belongs to a managed package and is not reported, because an org cannot change it. Enforced by MetadataNameStartsWithCapital and MetadataLabelStartsWithCapital.
• A field's API name is its label with each space as an underscore, each word capitalised: Sales_Tax_State__c for the label Sales Tax (State). This is the name Salesforce makes from a label, and these standards keep it. Some organisations prefer a name with no underscores, in Pascal case; the one exception here is an object whose fields already use that form, where a new field follows the object. No rule checks the convention. Reviewers do.
• Similar fields are named the same way, and the name need not mirror the label. The labels State Sales Tax and City Sales Tax can carry the names Sales_Tax_State__c and Sales_Tax_City__c, so that the fields sort together, or the labels can be Sales Tax (State) and Sales Tax (City). Either way, there is no field labelled State Sales Tax beside one labelled Sales Tax (County). No rule checks this. Reviewers do.
• A checkbox field, which holds a Boolean value, has a name that starts with Is, so that the name reads as a yes-or-no question about the record: Is_Active__c, Is_Primary_Contact__c. The name never starts with IsNot, in any case and with or without underscores, because a negative name turns every check of the field into a double negative: Is_Not_Active__c = false means that the record is active. A custom checkbox field whose name does not start with Is, or that starts with IsNot, is reported at severity 3. Enforced by CheckboxFieldNamePrefix.

Descriptions¶

Every component carries a description of what it is for (Readability). The description is the one place a reader finds the purpose of a field without reading everything that uses it, so it says something: a description must have at least 10 characters, to ensure that it is meaningful.

• Every custom object and every custom field carries a description of more than 10 characters. A missing description, or one of 10 characters or fewer once trimmed, blocks the pull request (severity 2). Enforced by MetadataDescriptionCustomObject and MetadataDescriptionCustomField.
• A standard field that the org uses in its own way carries a description too, which the API can set. A standard field with none, or with one of 10 characters or fewer, is reported at severity 4. Enforced by MetadataDescriptionStandardField.
• The same holds for the other components these standards govern: a Flow, with its Flow tests, Flow categories, and Flow value maps, and a permission set, profile, custom permission, permission set group, muting permission set, or user access policy, each carries a description of more than 10 characters, and a missing or short one blocks the pull request (severity 2). Enforced by MetadataDescriptionFlow and MetadataDescriptionPermission.
• Every other component in the tables below carries a description of more than 10 characters, so that a reader learns its purpose without reading everything that uses it. A missing description, or one of 10 characters or fewer once trimmed, is reported at severity 3. The types are split among {N} rules by area, so that an organisation can give an area a severity of its own, and each table names the rule that reads it. Each rule takes the metadata types it reads from a property, so an organisation adds or removes a type, and a type whose feature the org does not use is never found. Sharing rules and matching rules have no file of their own, so their rules read each one inside the file of its object. Where the platform already requires a description, the rules add the 10-character minimum. Enforced by MetadataDescriptionUserInterface, MetadataDescriptionCore, MetadataDescriptionData, MetadataDescriptionSharing, MetadataDescriptionIntegration, MetadataDescriptionEinstein, and MetadataDescriptionComponent.
• Reports, dashboards, and CRM Analytics and Tableau Next assets are often made by users in production, so these standards do not require a description on one. An organisation that keeps them in version control can ask for one: an analytics asset without a description of more than 10 characters is reported at severity 4. Enforced by MetadataDescriptionAnalytics.
• A field whose use or purpose is not clear from its name has help text that says what the field does. The description is for the people who build and maintain the org; the help text is what a user sees beside the field on a record page, so it explains the field to the people who fill it in. No rule checks this. Reviewers do.

The metadata types that each rule reads by default, by area:

User interface and code¶

Read by MetadataDescriptionUserInterface.

Data model and process¶

Read by MetadataDescriptionCore.

Metadata type	Component	Platform requires a description
BusinessProcess	Business process
RecordType	Record type
WebLink	Custom button or link
ValidationRule	Validation rule
FieldSet	Field set
GlobalValueSet	Global value set
DataCategoryGroup	Data category group
ReportType	Custom report type
ApprovalProcess	Approval process
ActionPlanTemplate	Action plan template
CustomNotificationType	Custom notification type

Data quality¶

Read by MetadataDescriptionData.

Metadata type	Component	Platform requires a description
DuplicateRule	Duplicate rule
MatchingRule	Matching rule, in the object's MatchingRules file

Access and sharing¶

Read by MetadataDescriptionSharing.

Metadata type	Component	Platform requires a description
Group	Public group
SharingOwnerRule, SharingCriteriaRule, SharingTerritoryRule, SharingGuestRule, and any other kind	Every sharing rule in an object's SharingRules file
AccountRelationshipShareRule	Account relationship data sharing rule
SharingSet	Sharing set
RestrictionRule	Restriction rule
FieldRestrictionRule	Field restriction rule
TransactionSecurityPolicy	Transaction security policy

Integration¶

Read by MetadataDescriptionIntegration.

Metadata type	Component	Platform requires a description
CspTrustedSite	Trusted URL
RemoteSiteSetting	Remote site setting
NamedCredential	Named Credential
ExternalCredential	External Credential
ExternalClientApplication	External Client App
ConnectedApp	Connected App
ExternalAuthIdentityProvider	External auth identity provider
ExternalServiceRegistration	External Service
RegisteredExternalService	Registered external service
CatalogedApi	Cataloged API
CatalogedApiVersion	Cataloged API version
IntegrationProviderDef	Integration definition
InboundNetworkConnection	Private Connect inbound connection
OutboundNetworkConnection	Private Connect outbound connection
PublicKeyCertificate	Public key certificate
PublicKeyCertificateSet	Public key certificate set
OauthCustomScope	OAuth custom scope
OauthTokenExchangeHandler	OAuth token exchange handler

Analytics¶

Read by MetadataDescriptionAnalytics.

Business rules¶

Read by MetadataDescriptionComponent.

Agents and Einstein¶

Read by MetadataDescriptionEinstein.

Service Cloud¶

Read by MetadataDescriptionComponent.

Collaboration¶

Read by MetadataDescriptionComponent.

Experience Cloud and sites¶

Read by MetadataDescriptionComponent.

Territories¶

Read by MetadataDescriptionComponent.

Data Cloud¶

Read by MetadataDescriptionComponent.

Industries and other products¶

Read by MetadataDescriptionComponent.

Secrets in Fields¶

A value in a field is read by every user who has the field, in a report, and through the API. A secret does not belong there.

• No credential is kept in a field of a standard or custom object, a custom metadata type, or a custom setting. A credential is kept in an External Credential (Settings: Custom Settings and Custom Metadata Types). Outside a managed package, a protected custom metadata type behaves like a public one, so its protection does not keep a secret (Access Rules When Packaging Custom Metadata Types and Records). A field of a custom object whose name suggests a credential, such as Api_Token__c, blocks the pull request (severity 2), and so does such a field on a custom metadata type or a custom setting whose visibility is public. Enforced by ProtectSensitiveData. The rule reports a field of a custom object only: it reads the object's name and reports the field when that name ends in __c, so a custom field on a standard object, such as Api_Token__c on Account, is never reported (DetectSecretsInCustomObjects.java). Ideally the rule would check custom fields on standard objects too. The Java rule NoCredentialNamedField does: it reports a custom field whose name suggests a credential on any object, standard or custom, and on any custom metadata type or custom setting, whatever its visibility, and blocks the pull request (severity 2). Enforced by the Java rule NoCredentialNamedField.

The rule is a screen, and it has false alarms. It reads only the name of the field, and it reports every name that contains one of its words, among them key, sign, pass, cred, auth, access, private, and public. So it also reports Assigned_To__c and Credit_Limit__c. The owning team accepts a report of that kind (Fixing a Blocking Violation).

Secrets in Metadata¶

A secret written into a metadata file is read by everyone who can read the repository, and it stays in the history after the file is corrected (Security).

• No secret is written into a metadata file, in a value or in a description. A secret is kept in an External Credential or a Named Credential, and read from there.

Each kind of secret has a form of its own, so the reference rulesets hold one sample rule for one form, the Salesforce session ID, and an organisation copies the rule once for each vendor whose keys its org uses, such as a payment provider or a messaging service. Each copy is named for its vendor, such as AvoidHardcodedSecretStripe, and its secretPattern property holds the form of that vendor's keys.

In this project's example, a Salesforce session ID in a metadata file blocks the pull request (severity 2). Enforced by AvoidHardcodedSecretSalesforce. The secret scanner of the Secret Scanning standard reads every file too; these rules add a check to the code scan, for the vendors that the organisation names.

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.