Data Management¶

Standards for data management metadata: custom metadata types, duplicate and matching rules, and data classification, together with configuration data, which configures the org but is stored as records.

Configuration Data¶

Some records configure how the org behaves but are stored as data, not metadata. Salesforce does not expose them through the Metadata API, so a metadata deployment never touches them, and the metadata risk tiers, which classify deployed metadata only, do not cover them. Examples include permission set assignments, public group and queue memberships, Org-Wide Email Addresses, custom setting values, and the configuration records of managed packages. Configuration data follows this standard instead.

Every type of configuration data takes one of two routes, decided by a single question: should the records be the same in every org?

The Same in Every Org: Version-Controlled Data¶

• The records are stored in version control as data files, such as the output of sf data export tree, and change only through a reviewed PR.
• A pipeline data step loads them into each org after deployment. They are never loaded or edited by hand.
• Records are matched between orgs by external ID, never by Salesforce record ID, because record IDs differ from one org to the next.
• Review is proportionate to effect, as it is for metadata: records that grant access or change security behaviour get the same senior review as Tier 1 metadata.

Different in Each Org: Managed in the Org, Governed by Audit¶

• The records are created and changed directly in each org, only by the people authorised to do so.
• They are governed by auditing rather than by the pipeline: Setup Audit Trail and the org's continuous audit record every change, and the changes are reviewed regularly.
• Org-Wide Email Addresses belong here. Each address has to be verified by email in each org, so it could not be fully deployed in any case.

Permission set assignments need particular care, because they decide who can see what. Whichever route an org takes for them, assignments are audited regularly under the principle of least privilege.

Privacy Center¶

Privacy Center is Salesforce's tool for applying privacy policy to the data in the org. Since Winter '24 it runs on the Salesforce platform itself; the earlier Heroku-based version is now documented as Legacy Privacy Center. It covers:

• Right to Be Forgotten policies, which delete or anonymise a person's data on request.
• Retention and Data Management policies, which retain, de-identify or mask, or delete data on a schedule.
• Portability policies, which answer Data Subject Access Requests.
• Consent management, through the Global Consent Manager and preference forms.

The standard: retention, deletion, anonymisation, and data subject requests are carried out by declared policies rather than by one-off scripts or manual data changes. A policy is reviewable, repeatable, and auditable; a script run once against production is none of those.

Preventing Record Deletion¶

Permissions prevent most deletions: no permission set or permission set group grants Delete on an object whose records must be kept. A permission does not stop a user or a process that already holds Delete, so an organisation that must keep its records also stops deletion in its automation framework.

• In an organisation that keeps its records, every object that supports triggers has a trigger action in the before-delete context that stops the deletion. The action is activated or deactivated for each object in the framework's custom metadata, with the action's Bypass_Execution__c field, so that one object can allow deletion while the others do not. A user who holds the action's bypass permission can still delete a record when the organisation approves it. No rule checks this. Reviewers do.
• One class serves every object. addError works on any SObject, so the class takes the records as SObject, and no object needs a class of its own. One class, registered for each object, keeps the org free of a copy of the same code for every object.

/**
 * @description Trigger action that stops the deletion of a record. Register it in
 * the before delete context of each object whose records must not be deleted.
 */
public inherited sharing class TA_SObject_PreventDeletion implements TriggerAction.BeforeDelete {
    /**
     * @description Adds an error to each record, so that no record in the
     * operation is deleted.
     * @param oldList the records that the operation would delete
     */
    public void beforeDelete(List<SObject> oldList) {
        for (SObject record : oldList) {
            record.addError(System.Label.Record_Deletion_Not_Allowed);
        }
    }
}

Master-Detail Reparenting¶

A master-detail field either lets a child record move to another parent or does not. Which to choose is a decision for each organisation, and these standards do not make it. A field that does not allow reparenting locks every child record to the parent it was created under, so a data fix needs a delete and a re-create; a field that allows it needs field-level security and validation rules to control who may reparent.

A master-detail field that does not allow reparenting, or that leaves the setting out, which has the same effect, is reported at severity 3, which does not block, so that the choice is seen and made on purpose. Enforced by MasterDetailReparentable.

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.