assess.one – AI-powered business operations platform

Workflow Template

Patch Management Workflow

Manages the end-to-end lifecycle of a software patch: intake from the requester, IT review and testing, risk-based change approval (IT lead for low risk, change manager for high risk/impact), scheduled deployment, outcome recording (successful or failed/rolled back with remediation), and requester notification.

It usually starts with an email or a chat message asking IT to patch something, and from there it's anyone's guess where the request goes or who's supposed to sign off on it. This workflow handles the whole journey automatically: logging the request, routing it through testing, sending it to the right approver based on risk level, tracking the deployment, and notifying the requester of the outcome. Your team gets a clear, auditable trail from 'someone asked for a patch' to 'patch is live and confirmed working,' without anyone needing to chase status updates.

Business Outcomes

  • Helps reduce time spent tracking down patch request status
  • Supports clearer accountability with risk-based approval routing
  • Makes it easier to catch failed tests before deployment
  • Improves visibility into pending, approved, and deployed patches
  • Helps create a documented approval and deployment trail for audits

Workflow Steps

Steps

  1. 1
    Create Patch Request Recordcreate record

    Registers the submitted patch request as a record.

  2. 2
    Set Status: Receivedupdate record

    Marks the patch request as received.

  3. 3
    Review Applicability and Test Patchcreate task

    IT reviews whether the patch applies to affected systems, tests it, and assesses risk.

  4. 4
    Set Status: Under Reviewupdate record

    Persists the review findings and updates status.

  5. 5
    Route on Test Result

    Only patches that pass testing proceed to approval.

    test_result: "Pass"→Set Status: Pending Approval
    test_result: "Fail"→Address Test Failure
    Default→Set Status: Pending Approval
  6. 6
    Address Test Failurecreate task

    Assigns a task to fix the patch or update it before retesting.

  7. 7
    Restart Review and Testrestart from step

    Sends the patch back through review and testing after remediation.

  8. 8
    Set Status: Pending Approvalupdate record

    Marks the patch as awaiting change approval.

  9. 9
    Route Approval by Risk

    Low-risk patches go to the IT lead; high-risk or high-impact patches go to the change manager.

    risk_level: "High"→Change Manager Approval
    high_impact: "true"→Change Manager Approval
    Default→IT Lead Approval
  10. 10
    IT Lead Approvalrequest approvalrequires approval

    IT lead reviews and approves or rejects the low-risk patch for deployment.

  11. 11
    Route IT Lead Approval Outcome

    Branches based on the IT lead's decision.

    approval_status: "approved"→Set Status: Approved
    approval_status: "rejected"→Set Status: Rejected
    Default→End
  12. 12
    Change Manager Approvalrequest approvalrequires approval

    Change manager reviews and approves or rejects the high-risk/high-impact patch for deployment.

  13. 13
    Route Change Manager Approval Outcome

    Branches based on the change manager's decision.

    approval_status: "approved"→Set Status: Approved
    approval_status: "rejected"→Set Status: Rejected
    Default→End
  14. 14
    Set Status: Rejectedupdate record

    Marks the patch request as rejected and notifies the requester.

  15. 15
    Notify Requester of Rejectionsend email

    Informs the requester that the patch was not approved for deployment.

  16. 16
    Set Status: Approvedupdate record

    Marks the patch as approved for deployment.

  17. 17
    Schedule and Deploy Patchcreate task

    IT schedules and deploys the patch, then records the outcome.

  18. 18
    Persist Deployment Detailsupdate record

    Records the deployment scheduling and outcome details on the patch record.

  19. 19
    Route on Deployment Outcome

    Branches on whether the deployment succeeded or failed and was rolled back.

    deployment_outcome: "Successful"→Set Status: Deployed
    deployment_outcome: "Failed and Rolled Back"→Set Status: Rolled Back
    Default→End
  20. 20
    Set Status: Deployedupdate record

    Marks the patch as successfully deployed.

  21. 21
    Notify Requester of Successful Deploymentsend email

    Informs the requester that the patch was successfully deployed.

  22. 22
    Set Status: Rolled Backupdate record

    Marks the patch deployment as failed and rolled back.

  23. 23
    Notify Requester of Rollbacksend email

    Informs the requester that the deployment failed and was rolled back.

  24. 24
    Set Status: Remediation In Progressupdate record

    Marks the patch as under remediation investigation.

  25. 25
    Investigate Deployment Failurecreate task

    Assigns a remediation task to investigate the failure before reattempting deployment.

  26. 26
    Persist Remediation Findingsupdate record

    Saves the remediation investigation findings to the record.

  27. 27
    Restart Deployment After Remediationrestart from step

    Sends the patch back to the deployment step to reattempt after remediation.

Fields

  • Requester Name*
  • Requester Email*
  • Patch Name / Identifier*
  • Patch Description*
  • Affected Systems*
  • Severity*
  • +12 more fields

Forms

Patch Request Intake

8 fields

Data Views

All Patch Requests

patch_name, severity, risk_level, patch_status +2 more

Dashboard Widgets

Patch Requests by StatusPatch Pipeline SummaryPatch Requests by Severity

Recommended integrations

Setup the following integrations to extend workflow capability.

  • Send email in the workflow

    AWS SES logoAWS SES
patch managementsoftware patchingsecurity patchIT patch workflowvulnerability patching

Similar Workflows

vulnerability remediationit change managementsecurity incident response

Similar Categories

information technologycybersecurity privacy

FAQs

Do I need IT or developer help to set this workflow up?

No — this is a ready-to-use template inside assess.one, so you publish it directly on the platform without any coding or external development work. You can adjust step names, approval logic, and notifications yourself using the built-in editor.

Can my team start using this the same day we publish it?

Yes, once you publish the workflow it's live immediately and your team can start submitting patch requests right away. There's no separate implementation phase — the workflow runs inside assess.one as soon as it's published.

Who needs access to this workflow?

Typically requesters, IT reviewers, the IT lead, and a change manager for higher-risk patches, since these are the roles referenced in the approval routing. You can set access and permissions for each role directly in assess.one so people only see the steps relevant to them.

How does the workflow decide who approves a patch?

The workflow routes approval based on risk level — low-risk patches go to the IT lead, while high-risk or high-impact patches are escalated to the change manager. You can adjust the risk criteria and routing rules to match how your organisation actually classifies risk.

What happens if a patch fails testing?

If testing fails, the workflow routes the request to a remediation step where the issue is addressed, then sends it back through review and testing again. This loop continues until the patch passes testing and is ready to move to approval, so nothing gets pushed forward untested.

What happens if a patch gets rejected during approval?

If either the IT lead or change manager rejects the patch, the status updates to reflect that and the requester is automatically notified of the rejection. This keeps requesters informed without someone having to manually follow up on every decision.

Can we customise the steps or add extra approval stages?

Yes, you can edit steps, add approval stages, change notification triggers, and adjust status labels directly inside assess.one. This is useful if your organisation needs additional sign-offs for certain systems or wants to add a security review step.

Is this suitable for smaller IT teams without a formal change management process?

It can work well even for smaller teams since the risk-based routing means low-risk patches don't need to go through a full change manager review. You can simplify the approval logic further if your team doesn't have a dedicated change manager role.

How does the workflow record what happened after deployment?

After deployment, the workflow captures the outcome details and routes based on whether the deployment succeeded or failed. Failed or rolled-back deployments can trigger remediation steps, while successful deployments update the status to deployed and notify relevant parties.

Do we need to integrate this with our existing IT ticketing system?

No integration is required to get started — the workflow runs fully inside assess.one and creates its own patch request records. If you want notifications sent to tools like email or Slack, those connections are configured directly within assess.one.

Ready to use this workflow?

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

Patch Management Workflow | assess.one