Workflow Template

Patch Management Workflow

Manages IT patch requests end-to-end: intake, applicability/risk assessment, risk-based approval, deployment, rollback investigation with reattempt loop, and requester notifications at each stage.

Someone spots a vendor patch that needs applying, fills in a quick form, and then it's on IT to chase testing, approvals and deployment while keeping the requester in the loop. This workflow handles that whole journey automatically: it logs the request, assigns IT to test and assess risk, routes low-risk patches to the IT lead and high-risk ones to the change manager, and manages deployment with a built-in rollback investigation and reattempt loop. Requesters get an email update at every key stage, so IT isn't stuck answering 'what's the status' questions all week.

Business Outcomes

Fewer status-check emails thanks to automatic requester updates at each stage
Clearer accountability with risk-based routing to the right approver
Faster handling of failed deployments with a structured rollback and reattempt process
A complete timeline of testing, risk, approval and deployment decisions on every record
Less manual chasing between IT, approvers and requesters

Workflow Steps

Steps

1
Create Patch Request Recordcreate record
Registers the submitted patch request as a record.
2
Set Status: Submittedupdate record
Sets the record status to Submitted.
3
Email Acknowledgementsend email
Sends the requester an acknowledgement email with their reference number.
4
Set Status: Assessingupdate record
Sets the record status to Assessing.
5
IT: Review Applicability and Test Patchcreate task
Assigns IT a task to review applicability, test the patch, and record risk, deployment and rollback plans.
6
Save Assessment to Recordupdate record
Persists the applicability, test result, notes, risk, deployment plan and rollback plan to the record.
7
Route on Applicability
Routes based on whether the patch was found applicable.
applicability: "Not applicable"→Set Status: Not Applicable
applicability: "Applicable"→Route on Risk Level
Default→Route on Risk Level
8
Set Status: Not Applicableupdate record
Sets the record status to Not Applicable.
9
Email Requester: Not Applicablesend email
Notifies the requester that the patch was found not applicable, with IT's notes.
10
Route on Risk Level
Routes low-risk patches to the IT lead and high-risk patches to the change manager for approval.
risk: "Low risk"→IT Lead Approval
risk: "High risk"→Change Manager Approval
Default→IT Lead Approval
11
IT Lead Approvalrequest approvalrequires approval
Requests the IT lead's approval for the low-risk patch.
12
Route on IT Lead Decision
Routes based on the IT lead's approval decision.
approval_status: "approved"→Set Status: Deploying
approval_status: "rejected"→Set Status: Rejected
Default→End
13
Change Manager Approvalrequest approvalrequires approval
Requests the change manager's approval for the high-risk patch.
14
Route on Change Manager Decision
Routes based on the change manager's approval decision.
approval_status: "approved"→Set Status: Deploying
approval_status: "rejected"→Set Status: Rejected
Default→End
15
Set Status: Rejectedupdate record
Sets the record status to Rejected.
16
Email Requester: Rejectedsend email
Notifies the requester that the patch was not approved.
17
Set Status: Deployingupdate record
Sets the record status to Deploying.
18
IT: Schedule and Deploy Patchcreate task
Assigns IT a task to schedule and deploy the patch, recording the deployment date and result.
19
Save Deployment to Recordupdate record
Persists the deployment date and result to the record.
20
Route on Deployment Result
Routes based on whether the deployment succeeded or was rolled back.
deployment_result: "Successful"→Set Status: Deployed
deployment_result: "Failed and rolled back"→Set Status: Rolled Back
Default→End
21
Set Status: Deployedupdate record
Sets the record status to Deployed.
22
Email Requester: Deployedsend email
Notifies the requester that the patch was successfully deployed, with the deployment date.
23
Set Status: Rolled Backupdate record
Sets the record status to Rolled Back.
24
IT: Investigate Rollbackcreate task
Assigns IT a task to investigate the failed deployment and decide the next step.
25
Save Investigation to Recordupdate record
Persists the rollback cause, fix and next step decision to the record.
26
Route on Next Step Decision
Routes based on whether IT will reattempt deployment or abandon the patch.
next_step_decision: "Reattempt"→Loop Back to Deployment
next_step_decision: "Abandon"→Set Status: Abandoned
Default→End
27
Loop Back to Deploymentrestart from step
Restarts the workflow from the deployment stage to reattempt the patch, up to 2 times.
28
Set Status: Abandonedupdate record
Sets the record status to Abandoned.
29
Email Requester: Abandonedsend email
Notifies the requester that the patch was rolled back and will not be reattempted, with the cause.

Fields

Show all 21 fields

FormPatch Request Form

Requester Name*· Text
Requester Email*· Email
Patch Name*· Text
Patch Version*· Text
Vendor*· Text
Affected Systems*· Long text
Severity*· Choice
Known Vulnerability Fixed· Text
Release Notes· File upload

TaskIT: Review Applicability and Test Patch

Applicability*· Choice
Test Result· Long text
Assessment Notes· Long text
Risk*· Choice
Deployment Plan· Long text
Rollback Plan· Long text

TaskIT: Schedule and Deploy Patch

Deployment Date· Date
Deployment Result*· Choice

TaskIT: Investigate Rollback

Rollback Cause· Long text
Rollback Fix· Long text
Next Step*· Choice

Other fields

Patch Status· Choice

Requester Name*
Requester Email*
Patch Name*
Patch Version*
Vendor*
Affected Systems*

Forms

Patch Request Form

9 fields

Data Views

Patch Requests

patch_name, severity, affected_systems, risk +2 more

Dashboard Widgets

Patches by Status

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

patch managementsoftware patchingsecurity patchIT patch workflowvulnerability patching

Similar Workflows

Vulnerability Remediation Workflow IT Change Management Workflow Security Incident Response Workflow

Similar Categories

Information Technology Cybersecurity & Privacy

FAQs

Do I need any technical setup to start using this workflow?

No — this is a ready-to-use template, so your workspace can publish it and start running live patch requests within minutes. There's no installation or development project involved, so IT teams can get going straight away rather than waiting on a build.

Can my team customise the approval routing or the steps involved?

Yes, you can change the workflow at any time by describing the change in plain English or editing the steps directly in the workflow editor. For example, you could adjust who the low-risk or high-risk approvals go to, and previous versions of the workflow are kept so you can always see what changed.

Who is actually involved in reviewing and approving a patch?

IT is assigned a task to review applicability, test the patch, and record the risk, deployment plan and rollback plan. Depending on the risk level, the request is then routed to either the IT lead or the change manager for an approval decision, and both are workspace users who receive that task directly.

What happens if a patch is found not applicable?

If IT marks the patch as not applicable during their review, the record status is set to 'Not Applicable' and the requester automatically gets an email explaining this, including IT's notes. This closes out the request without it needing to go through approval or deployment.

Is this suitable for handling both low-risk and high-risk patches?

Yes — the workflow routes based on the risk level IT records during assessment, sending low-risk patches to the IT lead and high-risk patches to the change manager for approval. This means each patch gets an approval step suited to its risk, without extra manual triage.

What happens if a deployment fails and rolls back?

If the deployment result is recorded as failed and rolled back, the status updates to 'Rolled Back' and IT is assigned a task to investigate the cause, propose a fix, and decide the next step. IT can choose to reattempt deployment, which loops the workflow back to the deployment stage up to two times, or abandon the patch, which notifies the requester with the cause.

Can requesters track the status of their patch request without an account?

Yes — requesters take part through the public request form and receive email updates at each key stage, so they never need to create or log into an account. Each request also becomes a record with its own reference number and status, which is included in the acknowledgement email.

What information gets saved to the record versus staying with a task?

Because the workflow waits for the IT review, deployment and rollback investigation tasks, everything entered on those tasks — like applicability, risk, deployment plan, deployment result, and rollback cause and fix — is saved directly on the record. This gives you a full timeline of decisions and results for each patch request.

How many times will the workflow retry a failed deployment?

The workflow supports up to two reattempts when IT decides to loop back to the deployment stage after a rollback investigation. If the patch still fails after reattempts or IT decides to abandon it, the status is set to 'Abandoned' and the requester is notified with the cause.

Ready to use this workflow?

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