SfSkills Domains Docs GitHub

Home / security / salesforce-shield-deployment

salesforce-shield-deployment

Roll out Shield (Platform Encryption + Event Monitoring + Field Audit Trail) end-to-end, sequencing feature enablement to avoid data lockout. NOT for Classic Encryption or general PE design — use architect/salesforce-shield-architecture.

Open the skill folder on GitHub

Salesforce Shield Deployment

Shield is three separately-operated capabilities sold under one name:

"Salesforce Shield is a trio of security tools that helps you build extra levels of trust, compliance, and governance right into your business-critical apps. It includes Shield Platform Encryption, Event Monitoring, and Field Audit Trail." — Salesforce Security Guide

They share nothing else. Different enablement paths, different permissions, different failure modes, different rollback stories. Field Audit Trail is not even self-service: "For information about enabling Field Audit Trail, contact your Salesforce representative."

Deploying "Shield" as one project is the root cause of most bad Shield rollouts, because each capability then interferes with the diagnosis of the others.

Before Starting

  1. Confirm which of the three the compliance requirement actually needs. They

    answer different questions: encryption at rest, forensic history, and detection. A programme that needs one and buys three still has to operate three.

  2. Validate the field scope against what can be tracked and encrypted. Formula,

    roll-up, auto-number, long text, and multi-select fields cannot be history-tracked at all. Encryption has its own eligibility list. A scope written from a data dictionary will contain fields neither capability can cover.

  3. Establish the retention obligation's direction. A minimum ("retain for

    seven years") is nearly free with Field Audit Trail. A maximum ("do not retain beyond seven years") requires a deletion process you build and schedule, because nothing deletes on your behalf.

  4. Name the log destination and the analyst. Event Monitoring without a consumer

    and a person with the right permissions is a cost, not a capability.

Core Concepts

The three phases and why the order is what it is

PHASE 1  Field Audit Trail       lowest risk; value is TIME-DEPENDENT
PHASE 2  Event Monitoring        read-only; the instrument for phase 3
PHASE 3  Platform Encryption     one object at a time; changes behaviour

FAT first because history not collected today cannot be bought later. Event Monitoring second because it shows you what phase three changed. Encryption last because it is the only capability that alters query semantics.

Field Audit Trail retention is a mechanism, not a number

Without FATWith FAT
"retains field history data for up to 18 months, and up to 24 months via the API""retains archived field history data until you delete it"
20 tracked fields per object200 tracked fields per object

The policy is Metadata API, not Setup:

<historyRetentionPolicy>
    <archiveAfterMonths>18</archiveAfterMonths>   <!-- min 1, max 18, default 18 -->
    <archiveRetentionYears>7</archiveRetentionYears> <!-- a REMINDER; deletes nothing -->
    <gracePeriodDays>30</gracePeriodDays>          <!-- first archive only -->
    <description>Owner and requirement</description>
</historyRetentionPolicy>

Requires the RetainFieldHistory permission. Defaults when you deploy nothing: 18 months in production, one month in sandboxes, retained until deleted — and "Salesforce doesn't include the default retention policy when you retrieve the object's definition through Metadata API," so an empty retrieve is not evidence of no policy.

Storage: "Field history tracking data and Field Audit Trail data don't count against your data storage limits."

The monitoring surfaces are not interchangeable

SurfaceShapePermission (login example)
Event Log FileCSV per event type per dayView Event Log Files
Event Log ObjectsSOQL-queryableView Real-Time Event Monitoring Data
Real-Time Event MonitoringStreaming (LoginEvent, …)View Real-Time Event Monitoring Data
Login HistorySetup page and objectManage Users
Enhanced Transaction SecurityPolicies with actions—

Three different permissions for the same question. An analyst granted one cannot use the others.

Encryption is not retroactive

Enabling a policy encrypts subsequent writes. Existing records stay in plaintext until a re-encryption job runs and completes. Verify per object on Encryption Statistics.

The cross-capability interaction

"If you turn on Platform Encryption, the previously archived data remains unencrypted." History archived between phase one and phase three is permanently unencrypted. State that position; do not let it be discovered.

Common Patterns

Pattern A — three phases, three gates

Each phase closes on evidence, not on enablement. FAT closes when FieldHistoryArchive is populating and the policy is deployed; Event Monitoring closes when an incident rehearsal has produced a timeline; encryption closes per object when the query snapshot diff is clean.

Pattern B — the incident rehearsal

A scripted investigation — "user X may have exported customer data at 02:00 last Tuesday" — run end to end, recording how long each step took and what was missing. The list of what was missing is the deliverable. Full script in 0, Example 3.

Pattern C — per-object encryption gate

Inventory filters and matching keys → decide drop / deterministic / do-not-encrypt → snapshot expected results → enable → re-encrypt → verify → diff the snapshot. Example 4.

Pattern D — explicit retention policy on every in-scope object

Deploy historyRetentionPolicy even where the default is acceptable, so the policy is retrievable, reviewable, and diffable.

Decision Guidance

SituationApproach
Compliance needs forensic before/after valuesField Audit Trail, after validating the fields are trackable
Compliance names a formula or roll-up fieldTrack its inputs — those field types cannot be tracked
Change is made by a Flow or trigger in system contextField history may not record it — use Event Monitoring or a custom audit object
Requirement is "retain ≥ N years"Deploy the policy and do nothing else; retention is unbounded
Requirement is "do not retain beyond N years"Build and schedule a deletion process; nothing deletes on your behalf
Need detection within secondsReal-Time Event Monitoring
Need bulk historical analysisEvent Log Files into a SIEM or data lake
Need to block an action in flightEnhanced Transaction Security — and note the MFA action degrades to a block on mobile, Lightning Experience, and API
Field appears in a filter or matching keyDo not encrypt probabilistically — see security/platform-encryption
Data subject deletionDelete the record and FieldHistoryArchive separately
  1. Scope and validate: confirm which capabilities the requirement needs, and

    check every named field against the trackability and encryption eligibility constraints before committing to it.

  2. Phase 1 — Field Audit Trail: request enablement through your Salesforce

    representative, deploy an explicit historyRetentionPolicy per in-scope object, and gate on FieldHistoryArchive populating.

  3. Phase 2 — Event Monitoring: onboard the log destination with a named retention

    period and alert conditions, define the analyst persona with all three permissions, and gate on a completed incident rehearsal.

  4. Phase 3 — Platform Encryption, one object at a time: inventory filters and

    matching keys, snapshot expected query and report results, enable the policy for that object, run re-encryption to completion, verify on Encryption Statistics, and diff the snapshot before moving on.

  5. Record the cross-capability position: that history archived before the

    encryption date is unencrypted, where it lives, and what compensating control covers it.

  6. Hand over the operational commitments: the deletion process for a maximum

    retention obligation, the analyst persona and its permissions, and the re-encryption step that must accompany every future policy change.

Review Checklist

Salesforce-Specific Gotchas

Full detail with quotes in 0.

  1. "Shield" is three products, not one switch — and FAT is not self-service.
  2. FAT retention is "until you delete it," not ten years.
  3. archiveAfterMonths caps at 18 months.
  4. The default retention policy is invisible to Metadata retrieve — and the

    sandbox default is one month, not 18.

  5. Whole field categories cannot be history-tracked, and >255-character fields

    are tracked without values.

  6. FAT data does not count against storage — costing it as storage is a category

    error.

  7. Deleting a record does not delete its archived history.
  8. Enabling encryption does not encrypt already-archived history.
  9. The same question has three homes with three different permissions.
  10. Transaction Security's MFA action silently becomes a block on mobile,

    Lightning Experience, and API.

Output Artifacts

ArtifactDescription
Phased rollout runbookThree phases with the evidence each gate requires, and the owner of each
Validated field scopeEvery in-scope field checked against trackability and encryption eligibility, with the substitution where it failed
Retention policy metadataExplicit historyRetentionPolicy per object, plus the deletion process if the obligation is a maximum
Monitoring onboarding recordDestination, retention, alert conditions, recipient, analyst persona and its three permissions
Incident rehearsal reportThe timeline produced, the elapsed time per step, and the list of what was missing
Per-object encryption evidenceFilter inventory, before/after query snapshot diff, and Encryption Statistics confirmation
Stated compliance positionsUnencrypted pre-encryption archive; any field the scope named that could not be covered

Package files