Workflow Template
Key and Access Request Workflow
Manages facilities key and access requests from submission through manager approval, security vetting, issuance, and (for temporary access) return/revocation, with status tracking and notifications at each stage.
Someone needs a new key or building access — maybe a new starter, a contractor, or a manager covering another site — and normally that means emails back and forth between the requester, their manager, and security, with no easy way to see where things stand. This workflow takes the request from the initial form through manager approval, security vetting, issuance, and (for temporary access) collection or revocation, updating the record's status and notifying people automatically at each stage. Your team just works through the tasks assigned to them, while anyone can check a record's reference number and timeline to see exactly where a request is up to.
Business Outcomes
- Fewer status-check emails, since requesters get automatic updates at each stage
- Clearer accountability with approval and security tasks assigned to named people
- Faster turnaround from request to issuance with no manual chasing between steps
- Better visibility of temporary access that needs to be collected or revoked by an end date
- A full timeline per request showing approvals, security results and issuance details
Workflow Steps
Steps
- 1Create Request Recordcreate record
Registers the submitted key/access request as a record.
- 2Set Status to Submittedupdate record
Sets the record's access status to Submitted.
- 3Email Acknowledgementsend email
Emails the requester an acknowledgement with their reference number.
- 4Manager Approvalrequest approval
Manager reviews and approves or rejects the request.
- 5Route Manager Decision
Routes the workflow based on the manager's approval decision.
approval_status: "approved"→Security: Carry Out Checksapproval_status: "rejected"→Set Status to RejectedDefault→End - 6Set Status to Rejectedupdate record
Sets the access status to Rejected after manager rejection.
- 7Email Requester - Not Approvedsend email
Emails the requester that the request was not approved by the manager.
- 8Security: Carry Out Checkscreate task
Security carries out the required checks and records the result and notes.
- 9Save Security Check Resultupdate record
Persists the security check result and notes to the record.
- 10Route Security Check Result
Routes based on whether the security check cleared the key holder.
security_check_result: "Cleared"→Set Status to Clearedsecurity_check_result: "Not cleared"→Set Status to RejectedDefault→End - 11Set Status to Rejectedupdate record
Sets the access status to Rejected after failing security checks.
- 12Email Requester - Security Checks Not Passedsend email
Emails the requester that the security checks were not passed.
- 13Set Status to Clearedupdate record
Sets the access status to Cleared after passing security checks.
- 14Security: Issue Key or Accesscreate task
Security issues the key or access and records the key/card number and date issued.
- 15Save Issue Detailsupdate record
Persists the key/card number and date issued to the record.
- 16Email Key Holder - Conditions of Userequest external input
Emails the key holder a form showing the key/access issued and requires acceptance of the conditions of use.
- 17Set Status to Issuedupdate record
Sets the access status to Issued once the key holder has accepted the conditions.
- 18Email Requester - Access Issuedsend email
Emails the requester confirming that access has been issued.
- 19Route on Access Duration
Routes to the return/revoke process if the access is temporary.
access_duration: "Temporary"→Security: Collect Key / Revoke AccessDefault→End - 20Security: Collect Key / Revoke Accesscreate task
Security collects the key or revokes access on the end date and records the date returned.
- 21Save Return Detailsupdate record
Persists the date returned/revoked to the record.
- 22Set Status to Returnedupdate record
Sets the access status to Returned once the key/access is collected or revoked.
Fields
Show all 16 fieldsShow fewer fields
FormKey & Access Request Form
- Requester Name*· Text
- Requester Email*· Email
- Key Holder Name*· Text
- Key Holder Email*· Email
- Site*· Text
- Key or Access Level Needed*· Text
- Business Reason*· Long text
- Permanent or Temporary*· Choice
- End Date (if Temporary)· Date
TaskSecurity: Carry Out Checks
- Security Check Result*· Choice
- Security Check Notes· Long text
TaskSecurity: Issue Key or Access
- Key or Card Number Issued*· Text
- Date Issued*· Date
TaskSecurity: Collect Key / Revoke Access
- Date Returned / Revoked*· Date
Other fields
- Access Status· Choice
- I accept the conditions of use*· Checkbox
- Requester Name*
- Requester Email*
- Key Holder Name*
- Key Holder Email*
- Site*
- Key or Access Level Needed*
Forms
Key & Access Request Form
9 fields
Data Views
Key & Access Requests
key_holder_name, site, access_level, end_date +1 more
Dashboard Widgets
Recommended integrations
Setup the following integrations to extend workflow capability.
Send email in the workflow
AWS SES
Similar Workflows
Similar Categories
FAQs
Do I need to set this up for every site or key type separately?
No, one workflow handles requests across sites since the form captures Site and Key or Access Level Needed for each submission. Every request becomes its own record with its own reference number and status, so you can filter and track them by site or type in your table views.
Can my team customise the approval or security steps?
Yes, you can describe the change you want in plain English or edit the steps directly in the workflow editor, and earlier versions are kept so you can review what changed. For example, you could adjust who the manager approval task is assigned to, or change the wording in the emailed notifications.
Who actually approves or rejects a request?
A manager is assigned the approval task and decides whether to approve or reject the request. Depending on that decision, the workflow either moves the record forward to security checks or sets the status to Rejected and emails the requester that it wasn't approved.
What happens if security doesn't clear someone?
Security carries out the required checks and records the result and any notes directly on the record. If the result is Not cleared, the status is set to Rejected and the requester is emailed to let them know the security checks weren't passed; if cleared, the record moves on to issuance.
Does the key holder need to log in to accept the conditions of use?
No, the key holder receives an emailed form showing the key or access issued and confirms they accept the conditions of use, all without needing an account. Their response is saved to the record, and once accepted the status updates to Issued.
How does temporary access get returned or revoked?
If the request was marked Temporary on the original form, the workflow routes to a step where security collects the key or revokes access on the end date and records the date returned or revoked. That detail is saved to the record and the status updates to Returned, while permanent access requests skip this step entirely.
Is this suitable for tracking who currently holds which keys?
The workflow records each request's status, key or card number, and issue and return dates on the record's timeline, which gives you a running history of activity. Each business should confirm this level of tracking meets its own audit or compliance obligations, since requirements vary.
Can requesters submit this without creating an account?
Yes, requesters use a public request form to submit their details, and both the requester and key holder are kept updated by email at each stage without needing to log in anywhere. All they need is their reference number if they want to check progress.
Ready to use this workflow?
Create a free account and customise this workflow for your business.
