Approval Cover and the Sandbox Workspace

Value-based approval rules turn one Approve press on a requisition, a quotation award or a supplier bill into a chain of steps, and each step waits for either a named person or anyone holding a role. When the person a step waits for is on leave, the document stops. Out-of-office cover fixes that without changing the rule: open Settings, Security & Devices, Out of Office, choose who covers you under Covered by, set From and Until, add an optional note and click Set cover. The start cannot be in the past and you cannot choose yourself.

Nobody needs a special permission to set cover, and that is deliberate. A delegate can only sign what you could have signed, so cover never widens what the organization allows; it only moves who presses the button for a few days. The page lists your current and upcoming cover, and the bin button removes one if your plans change. Cover starts and ends on its dates by itself, so there is nothing to switch back on your first morning back. Creating cover is written to the audit log, and the same screen is in the mobile app.

In practice: the finance manager of a Nairobi distributor goes on two weeks of annual leave. On the Friday before, she sets cover to her deputy from Monday to the following Friday with the note “Annual leave, back on the 27th”. On Tuesday a supplier bill over the threshold reaches the finance-manager step; her deputy is notified alongside her, signs it, and the bill is approved that afternoon instead of waiting eleven days. When she returns, the bill’s trail shows her deputy signed on her behalf.

While cover runs, a step that names you can be signed by your delegate, and your roles count for your delegate on approval steps, so a step needing the Finance Manager role can be signed by the person covering a Finance Manager. When a step that waits for you becomes current, the delegate is notified as well as you, so the hand-over does not depend on anyone remembering to forward an email. Every decision made this way records on whose behalf it was made, so the trail shows the delegate signed for you rather than in their own right.

The chain’s own rules do not relax. One person signs at most one step of a document, so a delegate who already signed step one cannot also sign your step two. If the rule blocks self-approval, the people who raised the document still cannot sign it, whoever they are covering. And cover cannot be passed on: you cannot hand your approvals to someone who is away and has handed their own approvals to someone else, because that would turn one choice into a chain nobody chose.

In practice: a procurement officer raises a requisition and is also covering for the head of procurement this week. The rule blocks self-approval, so even though her cover would let her sign the head’s step, she cannot sign this document — it waits for another approver. On a different requisition raised by a colleague, she signs the head’s step on his behalf. If she tries to set her own cover to the head of procurement while he is away, the screen refuses and asks her to choose someone else.

A sandbox is a separate workspace holding a copy of your setup and none of your records, for trying a change before real people meet it. Open Settings, Security & Devices, Sandbox and click Create sandbox; each workspace has one at a time. It copies your roles with their permissions, your approval rules, your procurement defaults including budget control, and your AI settings. People are not copied, so an approval step that names a person becomes an Admin step, and a rule limited to one department applies to every department. Records, people, departments, integrations, API keys and audit streaming stay behind.

Click Open sandbox to step in. Nobody signs in to a sandbox directly: an administrator steps in from their own session as a sandbox user whose address can never receive a sign-in link, and a banner shows on every page with Back to my workspace. The sandbox sends no email — anything sent while it is the current workspace, or addressed to a sandbox user, is held back — so a test supplier or a test reminder never reaches a real inbox. Creating, entering and discarding the sandbox are written to your real workspace’s audit log, and viewing the page needs view-settings while every action needs edit-settings.

In practice: a school bursar wants a second approval step for requisitions over KES 500,000 and a hard budget block. In the real workspace that would change tomorrow’s approvals for twenty people, so she creates a sandbox, adds the rule and the block there, raises a test requisition for KES 650,000 and watches it stop at the new step and at the budget. Satisfied, she sets the same rule up in the real workspace. A month later, after roles have changed, she clicks Rebuild from current setup to start the next experiment from today’s configuration; changes never copy back on their own.