Workflow Template

IT Problem Management Workflow

Manages the lifecycle of an IT problem record from intake through root cause analysis, corrective action, optional change request, verification, knowledge base update, and closure with owner notification.

IT teams that track problems in spreadsheets or email threads lose root cause findings the moment the ticket closes, so the same incident resurfaces weeks later with nobody remembering what fixed it last time. This workflow captures every problem record from intake through root cause analysis, routes it to a change request only when needed, verifies the fix actually worked, and pushes findings straight into the knowledge base before closure. Teams publish it in assess.one in minutes and immediately get a repeatable process that cuts recurring incidents and gives every engineer visibility into what was tried and what worked.

Business Outcomes

Reduce recurring incident volume by capturing and reusing root cause findings
Cut mean time to resolution by routing change requests only when actually required
Eliminate lost RCA documentation with automatic persistence at each stage
Shrink verification failures by looping unresolved problems back into RCA automatically
Improve knowledge base coverage by making updates a mandatory step before closure

Workflow Steps

Steps

1
Create Problem Recordcreate record
Registers the submitted problem details as a new problem record.
2
Set Status to Openupdate record
Marks the problem as Open on creation.
3
Assign Engineerassign user
Assigns the problem to an engineer for root cause analysis.
4
Set Status to Under Investigationupdate record
Marks the problem as under investigation while RCA is performed.
5
Perform Root Cause Analysiscreate task
Engineer investigates related incidents and symptoms, records root cause, corrective actions, and whether a change is required.
6
Persist RCA Findingsupdate record
Saves the root cause, corrective actions, and change requirement to the record.
7
Route on Change Requirement
Determines whether a change request must be raised before verification.
requires_change: "Yes"→Set Status to Awaiting Change
requires_change: "No"→Verify Corrective Actions
Default→Verify Corrective Actions
8
Set Status to Awaiting Changeupdate record
Marks the problem as awaiting a change request before the fix can be implemented.
9
Raise Change Requestcreate task
Engineer raises a change request and records its reference number for the fix to be implemented.
10
Persist Change Referenceupdate record
Saves the change request reference to the problem record.
11
Verify Corrective Actionscreate task
Engineer verifies the corrective actions (and change, if applicable) resolved the root cause.
12
Persist Verification Resultupdate record
Saves the verification outcome and notes to the record.
13
Route on Verification Outcome
Determines whether the fix was effective or requires rework.
verification_outcome: "Verified - Effective"→Update Knowledge Base
verification_outcome: "Not Effective - Needs Rework"→Restart Root Cause Analysis
Default→Update Knowledge Base
14
Restart Root Cause Analysisrestart from step
Fix was not effective; restarts the workflow from root cause analysis for rework.
15
Update Knowledge Basecreate task
Engineer documents the root cause and fix in the knowledge base and records the article reference.
16
Close Problemupdate record
Persists the knowledge base reference and sets the problem status to Closed.
17
Notify Ownersend email
Sends an email to the owner confirming the problem has been resolved and closed.

Fields

Owner Name*
Owner Email*
Problem Title*
Related Incidents*
Affected Services*
Symptoms*
+10 more fields

Forms

IT Problem Intake

8 fields

Data Views

All Problems

problem_title, problem_status, owner_name, affected_services +3 more

Dashboard Widgets

Problem Lifecycle FunnelProblem OverviewProblems 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 it change management corrective action

Similar Categories

quality management

FAQs

What happens if the root cause analysis doesn't lead to a clear fix?

The workflow's routing step lets the engineer flag the problem as needing further investigation, which restarts the root cause analysis step instead of forcing a premature close. You can loop through RCA as many times as needed until findings are conclusive. Every attempt is persisted, so nothing gets lost between iterations.

Can this handle problems that don't require a change request?

Yes. The 'Route on Change Requirement' step branches the record based on whether a fix needs a formal change or can be applied directly. If no change is needed, the workflow skips straight to verification, avoiding unnecessary approval overhead.

What if verification shows the corrective action didn't work?

The 'Route on Verification Outcome' step checks the result and automatically sends failed verifications back to 'Restart Root Cause Analysis' rather than closing the record. This prevents problems from being marked resolved when they aren't, which is a common cause of repeat incidents.

Who needs access to this workflow?

At minimum you need engineers to perform RCA and corrective actions, a problem owner or manager to review status changes, and whoever manages your change process if change requests apply. Access and permissions for each role are configured directly inside assess.one, so you control exactly who can see or act on which step.

How long does it take to get this workflow running?

Publishing takes minutes — there's no implementation project or software installation involved. Once published, your team can start creating problem records and running the live process immediately.

Can we customise the statuses or add extra approval steps?

Yes. Statuses like 'Open,' 'Under Investigation,' and 'Awaiting Change' are editable, and you can add extra approval gates, notifications, or fields directly in assess.one. This lets you match the workflow to your existing ITSM terminology without needing developer involvement.

What if we have multiple engineers working the same problem?

The 'Assign Engineer' step supports reassignment as the problem progresses, so ownership can shift from an initial responder to a specialist during RCA. Status and history stay attached to the record regardless of who's assigned, keeping the audit trail intact.

How does the knowledge base update get enforced before closure?

'Update Knowledge Base' sits as a required step before 'Close Problem,' so the record can't be closed until findings are documented. This ensures every resolved problem contributes to institutional knowledge instead of relying on engineers to remember to write it up later.

Does the owner get notified at every stage or just at closure?

By default, the 'Notify Owner' step fires at closure to confirm resolution, but you can configure additional notifications at any step — such as when a change request is raised or verification fails — directly inside assess.one. Notification channels like email or Slack are set up within the platform without external integration work.

What compliance considerations does this workflow support?

Persisted RCA findings, change references, and verification results create a complete audit trail for every problem record, which supports change management and root cause traceability requirements common in ITIL-aligned environments. Because every step and status change is recorded in assess.one, you can review history for any record on demand.

Ready to use this workflow?

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