HRIS sandboxes: check copied data, connections and refresh rules

Who needs this buying test?

This guide is for an HR team changing an HRIS that connects to payroll, identity or recruiting systems. It is especially relevant when a supplier quotes a separate sandbox module or implementation testing service.

Your team needs to be able to repeat a test after a configuration change or refresh. A second environment has limited value if only one consultant knows how to prepare it, refresh it or interpret the results.

A replica may copy the sensitive parts too

HiBob’s published sandbox terms, labelled August 2022 and inspected on 2 October 2026, describe copying employee data and permission-based access. They also require connected integrations to remain sandbox-to-sandbox because a connection to production can affect live data.

The same terms say sandbox changes cannot be copied back to production and describe a maximum 60-day retention period unless data is refreshed or replaced. Confirm the current contracted behaviour; these public terms are not a substitute for your service schedule.

The buying implication: ask who prepares the data, approves access, reconnects test systems and reproduces approved changes in production. Those are work items, even when the software module is included.

Email masking is not complete anonymisation

SAP’s instance-refresh instructions distinguish employee/candidate email masking from options to anonymise other supported fields. They also warn that completed refresh changes cannot be reverted in the target instance.

Ask which fields, attachments, free-text notes and identifiers remain after your proposed preparation process. Do not infer that changing an email address makes the whole employee record fictional.

For a workflow that does not need real history, we would start with fictional records. Where a representative copy is necessary, have the appropriate data owner agree its scope and access before testing begins.

Map every connection to its receiving system

Ask the implementation team to complete this map using actual environment identifiers. “Test” in a display name is not enough: verify the receiving system and account.

If a receiving supplier has no test environment, agree a supported simulation or blocked-output test. Record what remains untested. Do not quietly substitute a live payroll or directory connection.

Recheck connections and permissions after a refresh

SAP’s refresh considerations identify settings that need attention, including identity configuration and timesheet integration URLs.

Freeze ongoing test changes, preserve the evidence you need, then record which configuration was copied, retained or restored. Recheck destinations and permissions before reopening access to testers.

Record any refresh during acceptance testing. Otherwise you may be unable to tell whether a changed result came from the copied data, configuration or software.

Test access, offboarding, refresh and release

This is a proposed supplier-led exercise using fictional people. It is not a record of hands-on product testing.

1. Restricted viewer: give a fictional manager the intended role. Show which test employee records and fields they can see, including the ones they should not.
2. Controlled leaver: run an approved test offboarding event. Produce evidence from the receiving test directory, not just a successful HRIS task.
3. Refresh and repeat: preserve the first result, refresh through the agreed process, recheck connections and rerun. Explain any difference.
4. Release handover: identify one approved configuration change. Show whether it is transferred, rebuilt or separately configured in production, and how the team will check it afterwards.

Hold the purchase if nobody owns the receiving-system setup or the release handover. Buying an environment does not buy those responsibilities automatically.

Include test preparation and production changes in the quote

Request separate scope for the environment, preparation or masking, test-system connections, refresh allowance, support and production handover. These are quote headings, not claims that every provider charges separately for them.

Compare two proposals using the same four proofs. A more expensive module may need less implementation effort; a cheaper one may still be the right choice when your team can own the work. Neither conclusion follows from the licence line alone.

Keep the accepted results, environment details and unresolved limitations with the project decision. Give payroll the cases, receiving-system results and any steps that remain untested.

Questions buyers ask