Workflow Template

IT Problem Management Workflow

Manages IT problems from intake through root cause analysis, optional change request, fixing, verification and knowledge base update, tracking status through to closure to eliminate recurring incidents.

When IT problems get logged in scattered emails and spreadsheets, root causes go undocumented and the same incidents keep resurfacing because nobody closes the loop with the knowledge base. This workflow captures each problem as a record with a reference number, routes it through root cause analysis, an optional change request, fixing and verification, and only closes it once a knowledge base article is linked. Teams get a consistent trail of what caused each problem and what was done about it, so recurring incidents are easier to catch before they repeat.

Business Outcomes

Fewer recurring incidents through mandatory root cause capture before closure
Faster owner communication with automatic acknowledgement and closure emails
Clearer accountability with tasks assigned to engineers, change managers, problem managers and service desk
Reduced risk of unverified fixes through a dedicated verification step before knowledge base update
Improved knowledge base coverage since closure depends on an article link being recorded

Workflow Steps

Steps

1
Create Problem Recordcreate record
Registers the submitted problem as a new record.
2
Set Status to Openupdate record
Sets the problem status to Open.
3
Send Acknowledgement Emailsend email
Emails the owner an acknowledgement with the problem reference number.
4
Set Status to Root Cause Analysisupdate record
Sets the problem status to Root Cause Analysis before assigning the investigation task.
5
Engineer: Root Cause Analysiscreate task
Assigns an engineer a task to determine the root cause, corrective actions and whether a change request is needed.
6
Save Root Cause Analysis Resultsupdate record
Persists the root cause, corrective actions and change request decision to the record.
7
Route on Change Request Requirement
Checks whether a change request is required before proceeding to fixing.
change_request_needed: "Yes"→Change Manager: Raise Change Request
change_request_needed: "No"→Set Status to Fixing
Default→Set Status to Fixing
8
Change Manager: Raise Change Requestcreate task
Assigns the change manager a task to raise the change request and record its reference.
9
Save Change Referenceupdate record
Persists the change request reference to the record.
10
Set Status to Fixingupdate record
Sets the problem status to Fixing before the corrective work begins.
11
Engineer: Implement Corrective Actionscreate task
Assigns an engineer a task with no due date to implement and record the completed corrective actions.
12
Save Corrective Actions Completedupdate record
Persists the completed corrective actions to the record.
13
Set Status to Verifyingupdate record
Sets the problem status to Verifying before the fix is checked.
14
Problem Manager: Verify Fixcreate task
Assigns the problem manager a task to verify whether the fix resolved the problem, with notes.
15
Save Verification Outcomeupdate record
Persists the verification outcome and notes to the record.
16
Route on Verification Outcome
Routes to the knowledge base update if verified, otherwise sends it back to the engineer for further fixing.
verification_outcome: "Verified"→Service Desk: Update Knowledge Base
verification_outcome: "Not resolved"→Restart Fixing Cycle
Default→Restart Fixing Cycle
17
Restart Fixing Cyclerestart from step
Closes this iteration and restarts from the fixing stage since the problem was not resolved, up to 3 times.
18
Service Desk: Update Knowledge Basecreate task
Assigns the service desk a task due in 3 days to update the knowledge base and record the article link.
19
Save Knowledge Base Linkupdate record
Persists the knowledge base article link to the record.
20
Set Status to Closedupdate record
Sets the problem status to Closed.
21
Send Closure Emailsend email
Emails the owner confirming the problem is closed and includes the root cause.

Fields

Show all 16 fields

FormProblem Intake Form

Owner Name*· Text
Owner Email*· Email
Problem Title*· Text
Related Incident References· Long text
Affected Services*· Text
Symptoms*· Long text
Known Errors / Workarounds· Long text

TaskEngineer: Root Cause Analysis

Root Cause*· Long text
Corrective Actions*· Long text
Is a Change Request Needed?*· Choice

TaskChange Manager: Raise Change Request

Change Reference*· Text

TaskEngineer: Implement Corrective Actions

Corrective Actions Completed*· Long text

TaskProblem Manager: Verify Fix

Verification Outcome*· Choice
Verification Notes· Long text

TaskService Desk: Update Knowledge Base

Knowledge Base Article Link*· Text

Other fields

Problem Status· Choice

Owner Name*
Owner Email*
Problem Title*
Related Incident References
Affected Services*
Symptoms*

Forms

Problem Intake Form

7 fields

Data Views

Problem Management Overview

problem_title, affected_services, change_reference, problem_status

Dashboard Widgets

Problems by Status

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

IT problem managementproblem managementITSMroot cause analysisknown error

Similar Workflows

IT Incident Management Workflow IT Change Management Workflow Corrective Action Workflow

Similar Categories

Quality Management

FAQs

What happens if the engineer determines a change request isn't needed?

The workflow checks the 'Is a Change Request Needed?' answer from the root cause analysis task. If it's No, the record skips the change manager task and moves straight to Fixing status. If it's Yes, the change manager is assigned a task to raise the change request and record its reference before fixing begins.

What if the fix doesn't resolve the problem during verification?

The problem manager records a Verification Outcome and notes on their task. If the outcome is 'Not resolved', the workflow restarts the fixing cycle, sending it back to the engineer for further corrective action, and this can repeat up to 3 times before moving on.

Can this handle problems linked to multiple related incidents?

Yes, the request form has a Related Incident References field where the owner can list all relevant incidents when submitting the problem. That information is saved to the record and stays visible in the record's timeline throughout the investigation.

Who is involved in resolving a problem through this workflow?

An engineer performs the root cause analysis and later implements corrective actions, a change manager raises the change request when one is needed, a problem manager verifies the fix, and the service desk updates the knowledge base. Each is assigned a task in turn and the workflow waits for their input before moving forward.

What if the knowledge base task isn't completed within 3 days?

The Service Desk: Update Knowledge Base task has a due date of 3 days, but the workflow waits for the task to be completed before setting status to Closed and sending the closure email. The task stays open on the record until the service desk records the knowledge base article link.

Can we customise which fields appear on the problem request form?

Yes, workspaces can describe the change they want in plain English or edit the form fields directly in the workflow editor. Earlier versions of the workflow are kept, so changes can be reviewed or adjusted over time.

What does the owner see throughout the problem's lifecycle?

The owner submits the initial request and receives an acknowledgement email with the problem reference number, then a closure email once the problem is resolved that includes the root cause. They take part through the public request form and emailed messages without needing an account.

What if the fixing cycle repeats the maximum number of times without success?

The workflow allows the fixing and verification loop to restart up to 3 times when the verification outcome is 'Not resolved'. Each cycle's outcome and notes are saved to the record, so the full history of what was tried is available in the record's timeline for staff to review and decide next steps.

How is the root cause documented for future reference?

During the Engineer: Root Cause Analysis task, the engineer records the Root Cause, Corrective Actions and whether a change request is needed, and these are saved to the record. The root cause is also included in the closure email sent to the owner once the problem is closed.

Ready to use this workflow?

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