An archive rule moves cold rows of one entity out of the operational database and into an archive table in the analytics warehouse, on a schedule you define. The trade is deliberate: the working system stays lean and fast, while the history remains queryable for analytics — archive tables can be used as sources in data models.
A run does three things in order, and stops at the first one that does not add up:
- Copies every row older than the cutoff to the archive table — a real table, so it keeps the rows after they leave the live data.
- Checks the copy by counting what actually landed. If that does not match the number of rows that were due, the run fails and the live data is untouched.
- Marks the rows deleted at the source. They stay in the database, still covered by its own point-in-time backup, but they stop appearing in lists, reports over live data, API queries, data models, datasets and dashboards.
Because step 3 is a soft delete, an archive run is recoverable — but recovering it is a database operation, not a button, so still treat activating a rule as a production change and estimate its impact first. When the rule runs offers two other modes: marking the rows deleted without copying them (for data the warehouse already holds), and deleting them permanently, which is what every rule did before 2026-09-08 and cannot be undone short of a database restore.
Prerequisites
- The archive administration capability (
setup.metadata.archive.manage) — it also gates the Archive Rules entry in Setup navigation. - A provisioned, reachable analytics warehouse for your organization — runs fail cleanly when it is unreachable, copying and deleting nothing. Only the permanent-delete mode works without it.
- Certainty about which entity, which date field, and which cutoff define "cold" for your data — the rule will act on exactly what you specify.
Procedure
- 1
Source Entity and Date Field pick the records and the timestamp the cutoff is compared against; the field list fills after the entity is chosen.
- 2
Target Warehouse Table is where the rows move to; a bare name lands in the silver schema, and the table is created on the first run.
- 3
Cutoff Formula (required) resolves to a date — rows whose date field is before it qualify.
- 4
Condition Formula is an optional guard ANDed in, such as Status = 'Closed'.
- 5
Schedule is a five-field cron expression evaluated in UTC; blank means manual runs only.
- 6
Active off keeps the rule from being scheduled while you estimate its impact.
Step 1 — Create the rule
Open Setup → Process Studio → Archive Rules and choose New Archive Rule. Fill in Label and Name (a descriptive display label and a stable internal name), Source Entity, and Date Field — the field list fills once the entity is chosen, and the field to pick is the one that represents business age, not merely the most convenient timestamp. When the rule runs decides what happens to the rows, and leaving it on the default is the safe choice; Archive table says where the copy lands, and empty means silver.<Entity>Archive. Then Cutoff Formula and, optionally, Condition Formula, each with an Open … formula builder button, plus Schedule and the Active checkbox. Leave Active off while defining formulas and estimating impact, then press Create. Before saving, verify the source/date pair against a real record so the cutoff measures what the business means by “cold.”
The list shows Label, Source Entity, Date Field, Target Warehouse Table, Active and Updated; each row offers Run, History, Edit, Clone Archive Rule and Delete.
Step 2 — Define what qualifies
Two expressions decide which rows are archived, and both are evaluated against the entity's real data:
- Cutoff formula (required) — an expression that resolves to a date, for example
DATEADD(year, -2, GETUTCDATE()). Rows whose date field falls before the cutoff qualify. - Condition formula (optional) — a predicate ANDed in, for example
Status = 'Closed', so only rows in a safe state qualify regardless of age.
Both fields offer a formula builder that can reference the selected entity's fields. Be precise here: a typo fails the run visibly, but a wrong-yet-valid condition archives the wrong rows silently.
Step 3 — Set the target table
Enter the Target Warehouse Table, such as silver.orders_archive. A bare table name without a schema lands in the silver schema. Neither the schema nor the table needs to exist — both are created on the first run, with the source entity's columns.
Step 4 — Estimate the impact before activating
Save the rule inactive and confirm the list reports it that way. Reproduce its exact predicate in a filtered list or report: selected date field before the evaluated cutoff, AND the optional condition. Record the total and inspect samples near both sides of the boundary, including linked records that must stay operational. If anything surprises you, correct the rule and repeat the estimate; an inactive rule can accumulate a large backlog, so never activate using an old count.
Step 5 — Activate and run once manually
Activate the rule, then use the row's Run action for a first supervised run. A run proceeds in a fixed order: check that the source entity and date field still exist (a rule whose field was renamed or removed refuses to start), resolve the cutoff, skip if an identical window was already archived, verify warehouse connectivity (an unreachable warehouse fails the run before anything is touched), bulk-copy every qualifying row into the target table, and only then delete those rows from the operational database.
Step 6 — Verify the run
Open History — the newest 50 attempts, each with Started, Completed, Status (Pending, Running, Succeeded, Failed, Canceled or Skipped duplicate), Archived Rows, Duration and Error — and inspect the newest attempt. Success should be close to the immediately preceding estimate; explain any difference caused by records changing in between. Spot-check that qualifying rows disappeared from operational lists and arrived in the named warehouse table with their key fields intact. A zero count is valid only when the same predicate now finds zero eligible rows.
Expected result
The first supervised run is Success, its archived count reconciles with a fresh estimate, qualifying rows are absent from operational queries and present in the intended warehouse table, and non-qualifying boundary records remain. History records the run, and the active UTC schedule is either intentionally populated or intentionally left manual-only.
Step 7 — Schedule it
Set the schedule as a five-field cron expression, evaluated in UTC — 0 2 * * 0 runs weekly at 02:00 UTC. The scheduler queues a run for every active rule whose schedule is due. The schedule is checked about once a minute, a run is queued only for occurrences after the rule's last run (the first occurrence is not back-filled), and archive runs send no notification on success or failure — History is the only record. Three things silently prevent scheduled runs: an inactive rule, an empty schedule (manual-only is a valid choice), and an invalid cron expression, which is skipped without any error — so if a rule "never runs", check those three before anything else.
Common problems
The run failed. Read the error on the newest history entry. The usual causes are a SQL error in the cutoff or condition formula (fix the formula and run again), a date field that was renamed or removed since the rule was written (the run refuses to start), or warehouse connectivity — in which case nothing was copied or deleted, and the run can simply be retried later.
The run says success but archived zero rows. Usually correct behavior: nothing qualified, or an earlier run already archived the identical window — repeat runs over the same rule, cutoff, target and condition are skipped as duplicates rather than re-archived.
Other records now show empty lookups. Records in other entities that referenced the archived rows keep dangling references — the same effect a hard delete has. If active documents still point at the rows you archived, your condition formula was too broad; tighten it so only truly closed history qualifies.
Common questions
Can archived records be restored?
Not from within the product. Archiving is a move, not a copy — the rows exist only in the warehouse table afterwards, and recovery means copying them back into the operational database manually, which is an operator-level task. This is the sharpest difference from the recycle bin, where restore is self-service. Before activating a rule, apply the same discipline as before a bulk delete: estimate, and be sure.
Is this the same archive the recycle bin uses?
No, and the distinction matters. The data lifecycle archive holds deleted records after their recycle-bin retention window, as a recovery of last resort. Archive rules act on live records that were never deleted — they offload cold history to the warehouse for performance and analytics. One is about undoing deletes; the other is about keeping the working set small.
Do reports still see archived data?
Reports and lists over live data do not — the rows are no longer in the operational database. The archived rows are available to the analytics side instead: an archive table in the warehouse can be a source in a data model, which lets datasets combine current operational data with archived history in one analysis.
How many rows did a rule archive in total?
Sum the archived-row counts of its successful runs in the run history. Run entries are per-attempt and append-only — failed attempts appear too, and a skipped-duplicate entry repeats the count of the run it duplicated rather than adding to it — so totalling every row of the history overcounts.