Skip to content
SmartFACT HelpHandbooksWatch and practise
Handbooks: ToolCustody

Allow a WorkSteps tool-readiness check

Record the exact approved task, receiving site and actor-to-borrower mappings, then withdraw deliberately when required.

Review edition · 25 October 2026 · For Owner

On this page

A readiness permission lets a named WorkSteps site check an approved ToolCustody task for explicitly mapped people. It grants neither a tool loan nor permission for a person to use an unsuitable tool. Agree the task and borrower mappings with the production team before entering them.

Gather source-owned facts

As ToolCustody Owner, open Team & stations and Manage WorkSteps tool readiness permissions. This Owner page does not list tools, loans or qualification results. Ask the responsible Supervisor for the existing active borrower IDs and approved task code. An Accounts actor reference identifies the signed-in WorkSteps person; a borrower name or badge is a different value.

The permission keeps this source organisation and production or practice environment. Obtain the exact Receiving WorkSteps site ID. Do not use a production site to stand in for a practice site.

Save the bounded permission

Under Allow an approved task, enter Receiving WorkSteps site ID, Approved task code and Maximum use in seconds. The source accepts 1 to 43,200 seconds, but a required-step permission usable in WorkSteps needs at least 60 seconds.

Add Explicit actor to borrower mappings. Supply each person's exact Accounts actor reference and Existing borrower ID. There must be 1 to 100 mappings with no repeated actor. Each borrower must currently exist at this ToolCustody site, be active and not be a service-provider contact. Do not create another actor identity to represent the same person's badge.

Give a Reason for permission of 1 to 500 Unicode characters without control characters. Complete recent Accounts verification and choose Save readiness permission. The task must exist in the active approved release; a draft task is insufficient.

Inspect Permission history for the receiving site, task, interval and mappings. Keep the Permission ID and Permission hash with the ToolCustody site ID, and hand those exact values to the WorkSteps Owner. That Owner must register and verify them at the receiving site before an Author can use the retained reference in a required step. See the WorkSteps handbook.

Understand what was authorised

The permission binds the approved task and source recovery generation. A saved permission does not enable an evidence connection that is switched off. The separately configured source/receiver connection must also be available.

Every operational readiness check still evaluates the exact asset and loan, mapped borrower, task suitability, current condition/holds, qualifications and whole requested use interval. An Owner permission cannot turn an expired qualification or missing physical loan into a ready result.

If the task or source recovery state changes, arrange a current reviewed permission and receiving configuration. Earlier recovery-generation entries remain visible as history, not automatic current authority.

Withdraw without losing the record

Open the intended history entry, check its exact receiving site and task, and choose Withdraw this permission. Supply the Withdrawal reason and Confirm withdrawal. Read the retained withdrawal after the response.

Withdrawal stops new use of that permission for readiness reads. It does not physically stop equipment, return an asset or resolve an existing custody incident. Tell the WorkSteps team promptly so guarded work is controlled through its own hold and review procedure.

Keep an interrupted permission change together

If the reply is unavailable, retain the page and use Check original receipt. The page blocks other changes while the request remains unresolved. Retry the same request is offered when that original receipt is missing. The private mappings remain in memory rather than browser storage, so do not refresh an unresolved request merely to remove its pending display.

For a definite refusal, check the exact task, current release, receiving scope, borrower status and repeated actor mappings. Correct the source fact through its proper owner before preparing a new intended permission.