assess.one – AI-powered business operations platform

Workflow Template

Key register and issue / return Workflow

Tracks issuance of physical keys to holders: captures key details on an intake form, requires the holder to acknowledge responsibility before the key is marked Issued, then manages the return process including lost/stolen escalation, rekeying decisions, and final closure — with a status field tracked throughout for reporting.

Organisations issuing physical keys to staff, contractors or tenants need a consistent, auditable way to track who holds each key, confirm they have accepted responsibility, and manage its safe return or loss. This workflow covers the full lifecycle of a key record, from intake and holder acknowledgement through to return, lost/stolen escalation, rekey decisions and final closure. It involves the key holder, the key administrator, the security manager and, where rekeying is required, the locksmith, with each stage reflected in the record's status and timeline.

Business Outcomes

  • Supports consistent tracking of every key from issue through to return or closure
  • Helps reduce the risk of keys being issued without documented holder acknowledgement
  • Makes it easier to identify lost or stolen keys quickly and route them for a rekey decision
  • Improves visibility of outstanding keys and overdue returns through status-based reporting
  • Provides a clear timeline of decisions and actions taken on each key record

Workflow Steps

Steps

  1. 1
    Create key recordcreate record

    Registers the key issuance submission as a key record.

  2. 2
    Set status to Awaiting Acknowledgementupdate record

    Sets the key status to Awaiting Acknowledgement immediately after issuance is recorded.

  3. 3
    Send acknowledgement form to holderrequest external input

    Emails the holder a form showing the key details and requires them to accept responsibility before the key is confirmed issued.

  4. 4
    Set status to Issuedupdate record

    Updates the key status to Issued once the holder has acknowledged responsibility.

  5. 5
    Key administrator: record returncreate task

    Assigns the key administrator a task with no due date to record when the key is returned and its outcome.

  6. 6
    Save return details to recordupdate record

    Persists the recorded return date and outcome onto the key record.

  7. 7
    Route on return outcome

    Branches based on whether the key was returned or lost/stolen.

    return_outcome: "Returned"→Set status to Returned
    return_outcome: "Lost or stolen"→Set status to Lost
    Default→End
  8. 8
    Set status to Returnedupdate record

    Updates the key status to Returned.

  9. 9
    Email holder return confirmationsend email

    Sends the holder a confirmation email that their key return has been processed.

  10. 10
    Set status to Lostupdate record

    Updates the key status to Lost following a lost or stolen report.

  11. 11
    Security manager: rekey decisioncreate task

    Assigns the security manager a task due in 2 days to decide whether locks must be rekeyed and record the action taken.

  12. 12
    Save rekey decision to recordupdate record

    Persists the security manager's rekey decision and action taken onto the key record.

  13. 13
    Route on rekey decision

    Branches based on whether the locks need to be rekeyed.

    rekey_decision: "Rekey needed"→Set status to Rekey Required
    rekey_decision: "No rekey needed"→Set status to Lost - Closed
    Default→End
  14. 14
    Set status to Rekey Requiredupdate record

    Updates the key status to Rekey Required.

  15. 15
    Locksmith: rekey lockscreate task

    Assigns the locksmith a task due in 3 days to rekey the affected locks and record completion.

  16. 16
    Save rekey completion to recordupdate record

    Persists confirmation that the locks have been rekeyed onto the key record.

  17. 17
    Set status to Lost - Rekeyedupdate record

    Updates the key status to Lost - Rekeyed once the locksmith confirms rekeying is complete.

  18. 18
    Set status to Lost - Closedupdate record

    Updates the key status to Lost - Closed when no rekeying is required.

Fields

  • Key Number*
  • Holder Name*
  • Holder Email*
  • Holder Mobile*
  • Company*
  • Areas the Key Opens*
  • +9 more fields

Forms

Key Issue Form

9 fields

Data Views

Key Register

key_number, holder_name, company, date_issued +2 more

Dashboard Widgets

Keys by Key Status

Recommended integrations

Setup the following integrations to extend workflow capability.

  • Send email in the workflow

    AWS SES logoAWS SES
key register and issue / returnlocksmith and access controltradetrades

Similar Workflows

Similar Categories

FAQs

What does this workflow record for each key issued?

Each key issuance becomes a record with a reference number, a status and a timeline of events. The record captures the intake form details such as key number, holder, company and areas the key opens, plus the holder's acknowledgement, return details, and any rekey decision and completion recorded later in the process.

Who is involved in issuing and tracking a key?

The key holder submits acknowledgement through an emailed form before the key is confirmed issued. The key administrator records the return outcome, the security manager decides on rekeying if a key is lost or stolen, and the locksmith is assigned the task of rekeying affected locks when required.

What happens if a key is reported lost or stolen?

When the return outcome is recorded as lost or stolen, the record's status updates to Lost and a rekey decision task is assigned to the security manager with a two-day due date. The security manager's recorded decision and action taken then determine whether the process routes to a rekey step or closes the record.

How does the workflow handle the holder's acknowledgement?

After a key record is created, its status is set to Awaiting Acknowledgement and an email is sent to the holder with the key details and a form asking them to accept responsibility. The key status only moves to Issued once the holder submits this acknowledgement, and their response is saved on the record.

How do we change what information is collected or who is assigned tasks?

A workspace can change the workflow by describing the desired change in plain English or by editing the steps directly in the workflow editor, such as adjusting the intake form fields or reassigning the rekey or return tasks. Earlier versions of the workflow are kept, so changes can be reviewed over time.

What is recorded when a key is returned?

The key administrator's task waits for the date returned and outcome to be entered, and these details are saved onto the key record. Depending on the outcome, the record then routes to a Returned status with a confirmation email to the holder, or to the Lost status for further handling.

How is the rekey decision and completion tracked?

The security manager's rekey decision and action taken are saved onto the record, and the status updates to Rekey Required if rekeying is chosen. Once the locksmith confirms the locks have been rekeyed, that confirmation is saved on the record and the status updates to Lost - Rekeyed, or Lost - Closed if no rekeying was needed.

How can we see the current state of all keys in the register?

Table views and dashboards display key records grouped by status, such as Awaiting Acknowledgement, Issued, Returned or Lost, making it straightforward to see outstanding keys at a glance. Each record's individual timeline also shows the sequence of statuses and actions taken for that specific key.

Does this workflow make our key management process compliant with regulations?

The workflow records statuses, the values staff and holders enter, and a timeline of actions taken on each key record, which supports internal oversight and reporting. Each business should confirm its own regulatory or insurance obligations regarding key control separately.

Ready to use this workflow?

Create a free account and customise this workflow for your business.

Key register and issue / return Workflow | assess.one