Problem Manager Identifies Root Cause and Eliminates Recurring Issues

Use Case at a Glance

Persona: A problem manager responsible for identifying systemic causes, coordinating investigation, and preventing recurring service disruption

Job to be done: Connect recurring incidents to a single problem record, establish and document the root cause, and drive a permanent fix or an explicit risk decision

Starting point: Incident history, service data, or operational trends indicate that the same or related disruption is recurring

Successful outcome: The problem has a supported root-cause analysis, related incidents and remediation records are traceable, affected users have approved guidance, and post-change evidence shows that recurrence or impact has decreased.

Use this scenario to determine whether a recurring issue is understood and controlled. Use the related Help topics for steps to create and associate records, update problem analysis, document a workaround, create a change request, accept risk, reopen a problem, and close it.

Detect a Pattern Worth Investigating

Start with evidence of a shared underlying condition rather than the number of incidents alone. Compare symptoms, error signatures, affected services and configuration items (CIs), timing, recent changes, user populations, resolutions, and recurrence after service restoration. Similar wording can describe different causes, while differently worded incidents can originate from the same failure.

Use problem dashboards to find trends, open work, service-level agreement (SLA) breaches, unassigned records, resolution time, and resolution-code patterns. Treat dashboard information as an investigation lead rather than proof that incidents share a cause. For details about dashboard metrics, see Problem Manager Dashboard for IT Services.

Establish the Problem Without Delaying Recovery

Incident Management restores service for each active disruption. Problem Management investigates and removes the systemic cause. Keep those outcomes separate: an incident can be resolved through a workaround while its related problem remains open, and a problem shouldn't be closed merely because the latest incident stopped affecting users.

Create or select one problem that describes the recurring condition at the appropriate scope. Confirm its subject, description, category, subcategory, affected services and CIs, impact, urgency, priority, owner, and investigation status. Associate the supporting incidents and other relevant problems, change requests, releases, or knowledge articles so that investigators can distinguish evidence from coincidence.

Avoid creating one problem for every incident or one broad problem for unrelated failures. Use associations such as Caused By and Similar only when the available evidence supports the relationship.

If the Associate Similar Problems proactive action is enabled, it can automatically associate problem records based on semantic similarity. A Similar association doesn’t establish a Caused By relationship. Review automatically associated problems before using them as evidence of a shared root cause.

To associate records manually, open the problem. On the Associations tab, click Associate, and then select a Record Type and Relationship Type, such as Caused By or Similar. Removing an association doesn’t delete the associated record. Resolve is separate from linking and can close multiple related records, so review the selected records before clicking Resolve.

For steps to create and associate problems, resolve problems, accept risk, and reopen problems, see Manage Problems for IT Services. To create a problem directly from an incident, see Manage Incidents for IT Services.

Investigate and Establish the Root Cause

Build a testable explanation from incident timelines, logs, telemetry, configuration and asset data, recent changes, known errors, knowledge articles, and subject-matter expertise. Reproduce the failure safely when possible. Compare affected and unaffected conditions, challenge competing explanations, and record what evidence confirms or rejects each hypothesis.

Document the causal chain rather than restating the symptom. Explain the failed condition, why it produced the observed impact, the affected scope, and the conditions under which the issue can recur. Cite the records or tests that support the conclusion. Mark unresolved assumptions and assign follow-up work instead of presenting inference as fact.

Track the configured root-cause milestone without compromising investigation quality. The standard Problem SLA tracks Root Cause Completion Time for critical- and high-priority problems, but your org’s policies can differ. Completing the milestone doesn’t prove that the analysis is correct. See SLA Policy for Problem for IT Services.

Reduce Impact with a Workaround or Known Error

When a safe temporary method reduces disruption, document its applicability, prerequisites, steps, limitations, risks, and verification results in the problem’s workaround information. Make the guidance available to incident fulfillers so that they can restore service consistently while the permanent fix is pending.

Create or update a knowledge article about a known error when a confirmed root cause and reusable workaround must be available beyond the problem record. Remove record-specific and sensitive details, route the article through the configured review process, and verify that the intended support audience can find it. A workaround controls symptoms or impact; it doesn’t eliminate the underlying cause.

If no safe workaround exists, state that explicitly and strengthen monitoring, escalation, communication, and recovery preparation. Use a knowledge article to make a verified temporary workaround available to the intended audience. See Key Workflows in IT Services.

Eliminate the Cause Through Controlled Change

After sufficient evidence supports the root cause and remediation, create and associate a change request from the problem. Include the affected scope, causal evidence, proposed fix, implementation requirements, test plan, rollback approach, schedule constraints, and verification criteria. Keep the problem open while the change proceeds through risk assessment, approval, scheduling, implementation, and verification.

The change outcome must test the causal claim. Confirm that the targeted condition changed as intended, service health remained acceptable, rollback wasn't required or was successful, and no material side effects appeared. A successfully implemented change isn’t enough if the recurring failure continues.

When a permanent solution isn’t feasible, use Accept Risk only after the appropriate stakeholders understand the residual impact, likelihood, current controls, ownership, and review conditions. Record the justification and the conditions that trigger monitoring or reopening. Risk acceptance is a governed decision, not a substitute for incomplete analysis. For change request and risk acceptance steps, see Manage Problems for IT Services.

Verify Recurrence Reduction and Close

Observe the service for a period and volume appropriate to the original recurrence pattern. Compare pre- and post-remediation incident frequency, affected users or transactions, error rates, downtime, workaround use, support effort, and service-level outcomes. Account for seasonality, traffic, releases, and reporting changes before attributing improvement to the fix.

Close the problem only when the record contains the supported root cause, resolution information, associated incidents and remediation, verification evidence, remaining risk, and reusable knowledge. Resolve related associations according to your organization’s process while preserving their history. Reopen the problem when the issue recurs, the causal explanation is disproved, or new evidence changes the required action.

Problem management is successful when a verified remediation or explicit risk decision results in a traceable reduction in recurrence or impact. Closing a problem, publishing an article, or completing a change alone doesn’t show that the recurring issue was eliminated.

Use AI as Assistance, Not Evidence

When configured, Einstein can draft a problem from an incident, and Agentforce actions can summarize problems, check attributes, find related records, propose resolutions, and draft root-cause or resolution summaries. Review generated fields and associations before saving or acting on them.

Generated summaries and proposed fixes aren’t verified root-cause evidence. Confirm every material claim against logs, records, tests, trusted knowledge sources, and subject-matter experts. Preserve the distinction between a semantic match, a plausible hypothesis, and a demonstrated cause. See Create Problems Automatically from Incidents with Einstein, AI Actions for Problem Management, and Proactive Actions for IT Problems.

Confirm That Problem Management Is Ready

Before deploying this process more broadly, confirm that Problem Management and its field validations, priority matrix, record layouts, associations, dashboards, and SLAs support your process. Also confirm that the required Knowledge, Change Management, and configuration management database (CMDB) components are configured. Einstein, Agentforce, and proactive actions are optional capabilities that require separate setup and permissions.

Assign the appropriate Problem Manager or Problem Fulfiller permission set group. Also assign the permissions required to accept risk, reopen problems, associate incidents, change requests, and releases with problems, and resolve associations. See Set Up Problem Management for IT Services and Problem Management Permission Sets for IT Services.

Validate the configuration before deploying it more broadly. Confirm that an authorized user can find problem records and dashboards, inspect analysis and resolution fields, and view related incidents and other associations. Confirm that the appropriate change request and risk actions are available for the record’s state, along with any configured Knowledge and AI assistance. When testing, exit any create, edit, questionnaire, generation, approval, or closure flow without saving changes.