Output retention#

Retention governs how long a report's run history, its stored outputs and execution logs, is kept before older runs are removed automatically. It bounds storage growth while guaranteeing that pinned and policy-protected runs survive. This guide is for the administrator who sets those policies and understands what enforcement does.

When to use it. Whenever run-history volume must be controlled: set folder and report policies, pin what must survive, and let enforcement remove the rest.

How the policy resolves#

Retention is a per-report and per-folder value, measured in days. For any given run, the effective policy is resolved along a chain, and the first level that carries a value wins:

1. Output pin on the run itself, which means keep forever.
2. The report's own retention value.
3. The folder chain, starting at the report's folder and walking up to the root; the nearest ancestor folder with an explicit value wins.
4. The system default, which is 30 days.

The day value follows one convention throughout: no value means inherit from the next level up, 0 means keep forever, and a positive number means keep that many days. When a single output is produced from more than one source report, the more conservative (longest-keeping) policy wins, so no report loses an output early.

Set a retention policy on a folder or report#

1. Open the folder's or report's Properties, and find the Job output history section.
2. Use the Inherit retention / Set a custom period switch. Inherit uses the parent folder and then the system default. Set a custom period reveals Keep output history (days), with a minimum of 1 day.
3. Save. Every report beneath a folder inherits the folder's value unless it sets its own.

For example, set the "Finance Reports" folder to keep run history 365 days, and every report under it inherits that unless it overrides.

Pin a run to keep it forever#

Pinning is the only per-run exemption. A pinned run is kept forever regardless of any policy, and it is skipped by both enforcement and bulk delete.

1. Open the report's Run History.
2. On the run you want to protect, select Pin. Its effective label reads "Kept forever, pinned."

Use this for a final period-close run that must survive any future policy change.

Enforcement, what happens automatically#

There is no "Enforce" button. On-premises, a hosted service ("Enforce Job History Retentions") runs automatically every hour. It walks the reports, skips pinned runs, resolves each run's policy, skips keep-forever policies, and marks a run expired when it is older than the resolved number of days, measured from the run's creation time. Expired unpinned runs are soft-deleted and then immediately purged to reclaim storage.

The Run History detail bar shows each run's effective retention, for example "Kept forever," "Kept until {date}," "Kept for N day(s)," or "Kept forever, pinned," along with the source of the policy (the report policy, a folder name, or the system default).

Delete a run, and recover one before purge#

• Delete a run from Run History with Delete run…. This is a soft delete: the run leaves the active history list, but its output and artifacts remain on disk until they are purged.
• Recovering a soft-deleted run is possible only until it is permanently purged, and only as a Reportworq support task. There is no restore button on Run History (Run History offers Delete run… only), so if you need a soft-deleted run back, contact Reportworq support while it is still within the purge window. A run that has been hard-purged cannot be recovered.

The purge of soft-deleted items is a background store operation, not a button. Once purge removes a run, its payload, descriptor, and artifact files are gone for good.

Notes and limits#

• The day convention treats 0 as keep forever, not delete immediately.
• Enforcement and purge run as background services on-premises, so removal is not instantaneous when you change a policy; the sweep runs hourly.
• Pinning is the only per-run exemption from a policy.
• Log and audit retention (application log, audit log, backup, AI audit, MCP audit) are governed by separate settings and are not the same as run-output retention. See Server configuration.

Going deeper. To review the durable record of what jobs ran and when, see Audit logs.