Workflow Template

Software Access Request Workflow

Captures software access requests, routes them through manager and system owner approval, adds security review for privileged access, provisions access via IT, verifies the access works with the requester's user, and tracks status through to completion.

Someone needs access to a new tool, and suddenly there's an email chain between the requester, their manager, the system owner, and IT, with no one quite sure what's been approved or granted. This workflow captures the request on a simple form, routes it through manager and system owner approval, adds a security review step for privileged access, and hands off to IT for provisioning, then checks with the actual user that access is working before marking it complete. Every step, decision, and comment is saved to the record, so the team can see exactly where any request stands without chasing anyone down.

Business Outcomes

Fewer access requests lost in email threads or forgotten follow-ups
Clear visibility into where each request sits, from submission to completion
Privileged access gets an extra security check without slowing down standard requests
IT provisioning and verification are tracked in one place instead of scattered messages
Requesters and users get automatic updates without staff having to write status emails

Workflow Steps

Steps

1
Create Access Request Recordcreate record
Creates the access request record from the submitted form.
2
Set Status to Submittedupdate record
Sets the access status to Submitted.
3
Send Acknowledgement Emailsend email
Emails the requester an acknowledgement with the reference number.
4
Manager Approvalrequest approval
Requests the requester's manager to approve or reject the access request.
5
Route Manager Decision
Routes based on the manager's approval decision.
approval_status: "approved"→System Owner Approval
approval_status: "rejected"→Set Status to Rejected (Manager)
Default→End
6
Set Status to Rejected (Manager)update record
Sets the access status to Rejected after manager rejection.
7
Email Requester - Rejected by Managersend email
Emails the requester that the request was not approved by their manager.
8
System Owner Approvalrequest approval
Requests the system owner to approve or reject the access request.
9
Route System Owner Decision
Routes based on the system owner's approval decision.
approval_status: "approved"→Route on Access Level
approval_status: "rejected"→Set Status to Rejected (Owner)
Default→End
10
Set Status to Rejected (Owner)update record
Sets the access status to Rejected after system owner rejection.
11
Email Requester - Rejected by System Ownersend email
Emails the requester that the request was not approved by the system owner.
12
Route on Access Level
Routes privileged requests to security review; standard requests go straight to provisioning.
access_level: "Privileged"→Security Team Review
access_level: "Standard"→Set Status to Provisioning
Default→Set Status to Provisioning
13
Security Team Reviewcreate task
Assigns the security team a task to review the privileged access request and record the outcome.
14
Save Security Review Resultupdate record
Saves the security team's review result and comments to the record.
15
Route Security Review Decision
Routes based on the security team's review result.
security_review_result: "Approved"→Set Status to Provisioning
security_review_result: "Declined"→Set Status to Rejected (Security)
Default→End
16
Set Status to Rejected (Security)update record
Sets the access status to Rejected after security team decline.
17
Email Requester - Declined by Securitysend email
Emails the requester the security team's comments explaining the decline.
18
Set Status to Provisioningupdate record
Sets the access status to Provisioning.
19
IT Grant Accesscreate task
Assigns IT a task to grant the access and record the username and date granted.
20
Save Provisioning Detailsupdate record
Saves the granted username and date granted to the record.
21
Set Status to Verifyingupdate record
Sets the access status to Verifying.
22
Request Access Verificationrequest external input
Emails the person needing access a form asking whether their access works and waits for their reply.
23
Route Verification Result
Routes based on whether the user confirms access is working.
access_working: "Working"→Set Status to Completed
access_working: "Not working"→Loop Back to IT to Fix Access
Default→End
24
Loop Back to IT to Fix Accessrestart from step
Restarts from the IT provisioning task so IT can fix the access, up to 3 times.
25
Set Status to Completedupdate record
Sets the access status to Completed.
26
Email Requester - Access Completesend email
Emails the requester confirming the access is in place.

Fields

Show all 15 fields

FormSoftware Access Request

Requester Name*· Text
Requester Email*· Email
Name of Person Needing Access*· Text
Email of Person Needing Access*· Email
Application*· Text
Access Needed*· Choice
What do you need it for?*· Long text
Business Justification*· Long text

TaskSecurity Team Review

Security Review Result*· Choice
Security Team Comments*· Long text

TaskIT Grant Access

Username Granted*· Text
Date Granted*· Date

Other fields

Access Status· Choice
Is your access working?*· Choice
Comments (optional)· Long text

Requester Name*
Requester Email*
Name of Person Needing Access*
Email of Person Needing Access*
Application*
Access Needed*

Forms

Software Access Request

8 fields

Data Views

Access Requests

user_name, application, access_level, access_status

Dashboard Widgets

Requests by Access Status

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

software access requestapplication accessaccess approvaluser provisioningIT request

Similar Workflows

User Access Request Workflow Employee Onboarding Workflow Document Review and Approval Workflow

Similar Categories

Cybersecurity & Privacy Human Resources

FAQs

Do I need to set up separate approval chains for managers and system owners?

No manual setup is needed beyond assigning who the manager and system owner approval tasks go to. The workflow requests manager approval first, then automatically routes to system owner approval if the manager approves, so both steps happen in order without anyone having to chase the next person.

Can my team customise which requests go to security review?

Yes. The workflow already routes based on the Access Needed field, sending anything marked Privileged to the security team and letting Standard requests go straight to provisioning. You can adjust this routing logic or the wording of the access levels by describing the change in plain English or editing the steps in the workflow editor.

Is this suitable for teams that don't have a dedicated security reviewer?

The security review step only triggers for requests marked Privileged, so teams that mostly handle standard access requests will see most requests skip straight to provisioning. If your workspace doesn't have a distinct security team, the review task can simply be assigned to whoever handles that responsibility.

What happens if a manager or system owner rejects the request?

If either the manager or the system owner rejects the request, the status is set to Rejected and the requester automatically receives an email explaining who declined it. The request record keeps a timeline of the decision, so there's a clear record of when and why it was turned down.

How does the workflow confirm access actually works?

After IT grants access and records the username and date, the person needing access is emailed a form asking whether their access is working. If they report it's not working, the workflow loops back to IT to fix the access, up to three times, before it's marked Completed.

Who is responsible for provisioning the access itself?

IT is assigned a task to grant the access and record the username granted and date granted, and the workflow waits until that task is completed before moving forward. Those details are then saved to the record so there's a clear log of what was provisioned and when.

Can the requester and the person needing access be different people?

Yes, the request form captures both the requester's details and the details of the person who actually needs the access. This means the requester (often a manager or team lead) can submit on someone else's behalf, while the access verification step goes directly to the person using the software.

How do I track the status of requests across the team?

Every request becomes a record with its own reference number, status, and timeline showing exactly what has happened at each step. Table views and dashboards let you see all requests by status, whether that's Submitted, Provisioning, Verifying, or Completed, without needing to ask anyone for an update.

Does the security team need a workspace account to review requests?

Anyone assigned the security review task needs to be a workspace member or admin, since it's an internal task with a result and comments recorded on the request. The requester and the person needing access, on the other hand, never need an account, they interact entirely through the request form and emailed verification form.

Ready to use this workflow?

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