The Non-Production Environment

Every change in this category eventually reaches a payslip. A place to try things first is not a luxury, and vendors sometimes charge for it.

What it is for

Rule changes, before they affect a live period.

Vendor releases, where a preview window exists.

Integration changes, including the payroll export format.

Training, so nobody learns on production data.

Reproducing an incident without disturbing the period being closed.

What makes it useful

Refreshed from production periodically, or it stops representing anything. A sandbox with six-month-old configuration tests nothing.

Comparable volume, at least for the cases you test. A rule that works on twelve people can behave differently on twelve hundred.

The same integrations, pointed somewhere safe. An export that goes nowhere is not a test of the export.

Clearly marked, so nobody confuses it with production. This sounds trivial and is the source of real accidents.

The data question

Refreshing from production copies personal data into a second environment, which extends the processing rather than being exempt from it.

Options: anonymise on refresh, subset to volunteers, or treat the sandbox with the same controls as production.

The third is the honest default for a system where the awkward cases are the point and anonymisation would remove them.

Restrict access to it as tightly as production, which people rarely do because it feels like a test system.

Include it in retention, or it accumulates copies of records past their deletion date.

In the contract

At least one non-production environment included, rather than priced separately at the first upgrade.

Refresh capability, self-service where possible.

Preview access to releases before they reach production.

Ask during evaluation, not after. Environments become expensive once you need them.

Using it in the routine

Rule change: configure in sandbox, run a period, compare against the previous calculation, then apply.

Release: run the export diff and a recalculation of a known period before it reaches production.

Incident: reproduce there rather than experimenting on a period being closed.

Keep a short record of what was tested, because "we tested it" is the claim an auditor will ask you to support.

Keep a record of what was tested

Short, and it is what an auditor asks you to support.

What was changed, tested where, compared against what, applied when.

Two lines per change.

Kept with the configuration history.

"We tested it" is a claim; a dated line naming the period compared is evidence, and the difference matters when a calculation is questioned two years later.

Keep sensitive modes inside the test boundary

Any less-visible capture mode needs an explicit policy and controlled review. Before configuration, review this feature page and test access, notifications and retention without using live employee data.