Data Retention

Overview

OrgGuard stores several kinds of records to do its job — scan runs, findings, notifications, diagnostic logs. Without limits, these accumulate forever and consume your org’s data storage.

The Data Retention subsystem automatically purges records that are older than a configurable threshold. Each tracked object has its own retention config record (Data_Retention_Config__mdt), so you can independently tune how long scan runs vs. logs vs. notifications stick around.

The retention batch runs daily. You change retention by editing the Custom Metadata records in Setup — no code, no deploy required.

Who this page is for

Admins balancing storage costs against audit-trail needs, or compliance teams that need to prove retention policies for SOC 2 / ISO 27001 / GDPR.

---

What ships by default

OrgGuard ships four retention configs (Data_Retention_Config__mdt records):

Object	Retention_Days__c	Action__c	Date_Field__c	Effective behavior
Scan_Run__c	90	Delete	Started_At__c	Scan history older than 90 days is auto-deleted
Notification__c	90	Delete	(CreatedDate)	Notification records older than 90 days are auto-deleted
OrgGuard_Log__c	14	Delete	Timestamp__c	Diagnostic logs older than 14 days are auto-deleted
Finding__c	0	Keep	(CreatedDate)	Findings are kept indefinitely for compliance

Date_Field__c is optional; when it’s left blank OrgGuard measures retention from CreatedDate.

TrackedAsset__c is not in the retention config — assets are never auto-deleted. Use Status = Deprecated to retire assets while preserving finding history.

The retention batch (DataRetentionBatch) runs once per day via a scheduled Apex job. The scheduler runs only the configs where Is_Enabled__c = true, Action__c = Delete, and Retention_Days__c > 0, processing them one after another (each batch chains the next on completion). The Finding__c config (Action = Keep, Days = 0) is therefore skipped entirely.

---

What you’ll see

Data Retention has no dedicated Lightning page in OrgGuard Pro 1.0. Configuration happens in Setup:

1. Setup → Custom Metadata Types → Data Retention Config → Manage Records

Each record has these fields:

Field	Purpose	Typical value
Object_API_Name__c	Which object this config targets	e.g. Finding__c
Retention_Days__c	Records older than this (by the date field below) are purged	14 / 90 / 365 / 0
Action__c	What to do when records match	Delete, Archive, or Keep
Is_Enabled__c	Whether this config runs at all	true / false
Batch_Size__c	Records processed per batch scope	200
Date_Field__c	Which date field to measure retention from (optional)	e.g. Timestamp__c; blank → CreatedDate

When Action__c = Keep, the retention batch skips the object entirely. This is how Finding__c is retained indefinitely today.

---

Common tasks

Task: Review current retention settings

Who can do this: OrgGuard Admin with read access to Custom Metadata.

1. Setup → Custom Metadata Types → Data Retention Config → Manage Records.
2. For each of the four shipped records, open it and note Retention_Days__c, Action__c, and Is_Enabled__c.
3. Compare with the What ships by default table above.

Task: Change the retention period for an object

Use this when your compliance policy differs from the shipped defaults (e.g. you need 180 days of scan history instead of 90).

Who can do this: System Administrator or an admin with “Customize Application” permission.

1. Setup → Custom Metadata Types → Data Retention Config → Manage Records.
2. Click the label of the record you want to change (e.g. Scan Run).
3. Click Edit.
4. Update Retention_Days__c to your new value.
5. Click Save.
6. Expected result: the next retention batch run (up to 24h later) uses the new value.

Caution

Shortening retention destroys history that’s already been retained. Before reducing Retention_Days__c, export any records you want to preserve (Data Loader or a report).

Task: Preserve a specific object indefinitely

If your compliance program says “scan runs must be retained for 7 years”:

1. Option A — set Retention_Days__c = 2555 (7 × 365) on the Scan_Run record.
2. Option B — change Action__c to Keep. This disables any purge for that object regardless of Retention_Days__c.

Task: Temporarily disable a retention config

Useful when you’re running a special audit and need to freeze purges for a week.

1. Edit the relevant Data_Retention_Config__mdt record.
2. Set Is_Enabled__c = false.
3. Save.
4. Remember to re-enable it afterward — records will accumulate while disabled.

Task: Verify the retention job ran

1. Setup → Apex Jobs.
2. Filter by Job Type = Apex Batch and the class name DataRetentionBatch.
3. Check the most recent completions — you’ll see one DataRetentionBatch job per eligible config (the scheduler chains them sequentially, so they appear back-to-back):
   • Status = Completed
   • Failures = 0
4. For deeper insight (OrgGuard Admin only), filter the Diagnostic Logging viewer by Module = Scheduler and look for retention-run entries.

Task: Force an immediate retention run

Not exposed in the UI in OrgGuard Pro 1.0. To trigger manually, a System Admin can execute anonymous Apex.

The simplest supported way is to invoke the scheduler’s execute directly — it applies the same eligibility rules (enabled, Action__c = Delete, Retention_Days__c > 0) and chains the eligible configs sequentially, exactly like the daily run:

new DataRetentionScheduler().execute(null);

DataRetentionBatch requires a Data_Retention_Config__mdt record — there is no zero-argument constructor. To run a single config on demand instead, query it and pass it to the batch:

Data_Retention_Config__mdt config = [
  SELECT Object_API_Name__c, Retention_Days__c, Batch_Size__c, Date_Field__c
  FROM Data_Retention_Config__mdt
  WHERE Object_API_Name__c = 'Scan_Run__c'
  LIMIT 1
];
DataRetentionBatch batch = new DataRetentionBatch(config);
Database.executeBatch(batch, batch.getBatchSize());

Only run these during a maintenance window — retention batches can be long-running on large orgs.

---

Action reference

Action__c	Meaning	Reversible?
Delete	Hard-delete records older than Retention_Days__c	No (records gone from org)
Keep	Skip this config entirely — no purge	N/A
Archive	(Placeholder) intended to move records to an archive surface	Not implemented in OrgGuard Pro 1.0

---

Troubleshooting

Symptom	Likely cause	Fix
Diagnostic logs disappearing unexpectedly	Retention period is 14 days (default)	Expected; to keep longer, raise Retention_Days__c on the OrgGuard_Log record.
Scan history missing past quarter	90-day default retention	Raise Retention_Days__c on the Scan_Run record.
Findings getting deleted	Someone changed Finding’s Action__c from Keep to Delete	Edit the Finding record back to Action__c = Keep.
Retention batch never runs	Scheduled job missing or aborted	Setup → Scheduled Jobs → check for OrgGuard Data Retention; re-schedule via Setup Wizard or re-install the package.
Batch runs but purges nothing	Is_Enabled__c = false, or Retention_Days__c longer than the oldest record	Verify config. OrgGuard Admin: check the retention log in Diagnostic Logging. Others: email support@orgguard.com with the retention config values.
Custom Metadata Edit doesn’t take effect	Metadata deploy pending (rare)	Wait 1–2 minutes; for unlocked packages, a deploy confirmation appears in Setup → Deployments.
”Archive” setting doesn’t archive anything	Archive action is not implemented in OrgGuard Pro 1.0	Use Delete if records are truly disposable, or Keep if they’re audit-relevant.

---

FAQ

Why are findings kept indefinitely by default? Findings are compliance/audit evidence. Deleting them would remove the proof that OrgGuard detected, tracked, and resolved a risk. For very old Resolved findings, consider building a scheduled flow that archives to an external system before purging — but we don’t recommend just deleting.

Can I set different retention per severity level? Not in OrgGuard Pro 1.0 — retention is per-object, not per-record. A future enhancement could support WHERE-clause filters on the retention config.

Does retention affect storage counted against my Salesforce org? Yes. Fewer retained records → less data storage consumed. Retention is the primary lever to keep OrgGuard’s storage footprint predictable.

Will retention delete records in a sandbox refresh? The retention job runs on whatever org it’s scheduled in, including sandboxes. If a sandbox refresh carries over a scheduled retention job, it continues running against the sandbox data — typically fine, but worth knowing.

What happens to TrackedAsset__c records that haven’t been discovered in a year? Nothing automatic. Asset records are never auto-purged. They stay with their most recent status. If you want aged-out assets removed, build a scheduled flow or do it manually via a Deprecated-status list view.

Can I add retention for custom objects I’ve added alongside OrgGuard? Yes — create a new Data_Retention_Config__mdt record with your object’s API name, retention days, and Action__c = Delete. Optionally set Date_Field__c (it defaults to CreatedDate). The scheduler picks it up on its next daily run as long as it’s enabled with Retention_Days__c > 0.

---

Related

• Diagnostic Logging — retention target with the shortest default (14 days)
• Findings — why the shipped Finding config uses Keep
• Scan Management — retention target for scan history
• Scheduled Jobs — the job that runs the retention batch
• Permission Sets — who can edit Custom Metadata records