Seeking Insights: ServiceNow Problem Task Best Practices

[jorgescanavino]

Hi everyone,

As a Product Owner for IT Problem Management at a multinational company with AMS, EUR, and AOA teams, I'm reaching out to the community to benchmark how you utilize ServiceNow Problem Tasks (PTASKs).

Currently, we leverage ServiceNow Problem Records to document our root cause analysis. We manage the associated tasks through the creation of PTASKs. Our established PTASK types include:

• Root Cause Analysis
• General
• Advanced (which incorporates methodologies like Ishikawa Diagrams and 5-Whys)

I'm keen to understand how other organizations are using this functionality. Specifically, I'm interested in:

• Do you use the same or similar PTASK types? If not, what types do you employ, and why?
• How is the governance of PTASKs structured in your organization? Do your Problem Managers and Problem Owners have full control over the creation, assignment, and closure of PTASKs?
• Do you use Problem Tasks in a collaborative manner? If so, how do different teams or individuals contribute to and interact with PTASKs?
• Do you use Problem Tasks to declare validated root causes and document mitigating actions? Or do you use other methods within ServiceNow for these purposes?

Any insights, experiences, or best practices you can share would be greatly appreciated!

Thanks in advance for your contributions.

[danmjunqueira]

Thanks for initiating this discussion—it's highly relevant for anyone working with structured IT Problem Management in ServiceNow.

Here’s how we’ve approached PTASKs in our environment:

Task Typing
We’ve standardized PTASK types similarly:

RCA (with mandatory methodology selection: 5 Whys, Ishikawa, etc.)

Remediation/Action Plan

Verification (post-implementation validation)
This helps us align PTASKs with the lifecycle of problem resolution rather than just using “General” tasks.

Governance and Roles
Problem Managers own the PTASK workflow end-to-end. However, we allow technical SMEs or resolver groups to update status and work notes directly. Only Problem Managers can close PTASKs, to maintain governance and final accountability.

Collaboration Model
PTASKs are assigned across cross-functional teams—Infra, Apps, Security. We use @mention in work notes for visibility, and embed knowledge articles or RCA templates via links to keep documentation standardized and accessible.

Root Cause and Mitigation Tracking
We log preliminary root causes in PTASKs, but the final validated root cause and permanent fix are documented at the Problem Record level. PTASKs support that narrative but do not replace the formal RCA fields.

Additional Tip
We’ve built dashboards for PTASK aging, overdue items, and type distribution. This helps keep Problem Managers accountable and provides insight into bottlenecks in the RCA process.

Would love to hear from others—especially around how PTASK usage scales in multi-regional teams or with different ITIL maturity levels.

[jorgescanavino]

Thanks @danmjunqueira !!! Your reply provided me with a lot of insights. And I am glad to see the same mindset related to PTASK Accountability. 

Now, as we continue to explore Problem Tasks, what about actions that are not actually root-cause driven, such as "improve the major incident declaration time"? That is not the cause of a system crash. But while assessing all possible root causes, the team realized that improvement action. That said, would that be a Problem Task?

[danmjunqueira]

Great question and you're absolutely right to reflect on whether all improvement actions belong within the Problem Task (PTASK) framework, especially those that don’t directly resolve a root cause.

If you allow me, maybe this suggestion can guide your governance around with this

First ask: Is it a Problem Task (PTASK)?

Let's evaluate intent:

Problem Tasks should primarily be used to:

Investigate or validate potential root causes

Document root cause analysis (RCA)

Implement corrective or preventive actions that are linked to the root cause

So if an action is directly tied to resolving or preventing recurrence of a specific incident or problem, like "replace faulty server hardware" or "patch memory leak in app module", it clearly belongs as a PTASK.

Than I would ask about actions like "Improve the major incident declaration process"?

That’s more of a process improvement or capability uplift, rather than an RCA-derived technical fix. However, it still emerges as a learning from the Problem Analysis phase, and that makes it valuable.

You have a few options:

Option 1: Include it as a Preventive PTASK
If you adopt a broad view of Problem Management (aligned with ITIL 4), preventive measures and systemic process improvements can be tracked in PTASKs — but you may want to use a dedicated PTASK Type like:

“Preventive Action”

“Process Improvement”

“Lesson Learned Action”

This ensures clarity for reporting and avoids muddying the metrics for root-cause-specific tasks.

or
Option 2: Link the Improvement to a CSI (Continual Service Improvement) initiative
For more strategic process enhancements, you may want to:

Log it as a CSI record or feed it into a Problem Learning Review (PLR)

Link it from the Problem Record for traceability

That allows teams like Major Incident, ITSM Governance, or Process Excellence to track and own the improvement, without overloading Problem Management scope.