Exodus Salesforce Docs
Admin Guide

Retention and Stress Governance

Admin and operator guide for safe data retention, stress-test datasets, cleanup manifests, and governance validation

Use this page before deleting operational data, generating stress data, or running governance checks in QA.

Retention Model

Retention is allowlisted and evidence-aware. The repo includes Data_Retention_Policy__mdt, Data_Retention_Run__c, OrgDataRetentionService, OrgDataRetentionBatch, and OrgDataRetentionScheduler.

Retention policies should identify:

Policy fieldMeaning
Policy_Key__cStable policy identifier.
Target_Object__cObject being scanned.
Retention_Days__cNormal retention window.
Failure_Retention_Days__cFailure/evidence retention window when supported.
Batch_Size__cBatch execution size.
Max_Records_Per_Run__cOperational safety cap.
Run_Order__cExecution ordering across policies.
Active__cWhether the policy is live.

Retention runs should leave Data_Retention_Run__c evidence with status, job id, scanned, updated, deleted, and failed counts.

Safe Candidates

Safe candidates are typically high-volume operational records that do not form customer, finance, payment, fulfillment, or audit evidence after their retention window.

Examples that can be considered with explicit policy:

CandidateNotes
API request/runtime logsKeep failure windows longer than success noise.
Runtime request historyKeep enough history for incident analysis.
Sync history past retention windowsPreserve failures and linked operational evidence.
Inventory and fulfillment snapshotsPreserve reporting windows and current state.
Duplicate overview snapshotsKeep enough trend history for admin reporting.
Sandbox generated dataUse run labels and manifests for cleanup.

Do Not Purge Without Separate Approval

Do not include these in general retention cleanup:

DataReason
Payment transactions, attempts, receipts, processor events, settlement linesFinancial and processor evidence.
Invoices and invoice linesAR, customer, tax, and accounting evidence.
Inventory transactions and PO receiptsStock and purchasing audit.
Sales order audit, delete audit, financial auditOperational and governance evidence.
Tracking and shipment evidenceCustomer service and fulfillment evidence.
Credit/RMA-related evidenceFinance and customer adjustment context.
GL account/default recordsAccounting configuration and posting readiness.

Stress Tooling

The repo uses local stress operator scripts rather than depending on an in-org Stress Lab runtime. Relevant scripts include:

node scripts/stress/salesforce-stress-preflight.mjs --target-org vesper
node scripts/stress/salesforce-stress-generate.mjs --target-org vesper
node scripts/stress/salesforce-stress-cleanup.mjs --target-org vesper --manifest path/to/manifest.json

Use stress data only in sandbox environments. Keep generated run labels, manifests, and cleanup commands with the test evidence.

Stress Preflight

Before generating stress data:

  1. Confirm target org is sandbox.
  2. Confirm Salesforce authentication.
  3. Confirm provider references or target warehouse assumptions.
  4. Confirm the run label.
  5. Confirm the expected record volume.
  6. Confirm cleanup manifest location.

If preflight fails, fix the environment before generating data.

Cleanup Rules

Cleanup should be manifest-backed. Do not rely on broad name matching if a manifest exists.

Cleanup evidence should include:

EvidenceWhy it matters
Target orgPrevents wrong-org assumptions.
Run labelTies generated records together.
Manifest pathMakes cleanup repeatable.
Deleted/failed countsShows what happened.
Failed record listDrives follow-up repair.

Governance Commands

Use focused validation for the slice you changed, then broader governance when risk justifies it.

Common commands:

npm run permissions:audit
npm run permissions:policy
npm run architecture:retirement:audit
npm run verify:governance:full

For docs-only changes, Salesforce governance commands are normally unnecessary. For Salesforce metadata, permission sets, payment, 3PL, warehouse, or RMA boundary changes, run focused tests plus governance checks before claiming readiness.

Last updated on

On this page