The Problem Management process has several states, and each one matters for the quality of the process. The Problem life cycle can be represented in a diagram as follows:

What happens in each state:

1. New: the problem is logged, from one major incident, from many similar incidents, or proactively from trends. Basic details such as the CI, category and impact are captured.

2. Assess: the Problem Manager reviews the record, confirms it is a real problem and not a duplicate, sets the priority and assigns it to the right team or Problem Coordinator.

3. Root Cause Analysis: the team investigates why it happens (5 Whys, Fishbone and similar techniques) and records the cause. If a workaround is found, it is documented and the problem can be marked as a Known Error so the service desk can use it.

4. Fix in Progress: the permanent fix is being delivered, usually through a change request raised from the problem.

5. Resolved: the fix is in place. The problem stays here while you confirm the incidents have really stopped.

6. Closed: the problem is closed with a resolution code, for example Fix Applied, Risk Accepted (the business decides not to fix it), Duplicate or Canceled.

Note: Known Error is a flag on the problem in newer releases, not a separate state. Mentioning this shows you know the current state model.

Root Cause Analysis is a structured way to find the underlying cause of an incident or problem, instead of only treating the symptoms. It answers: "Why did this happen, and how do we stop it from happening again?"

5 Whys: ask "why" repeatedly, each answer going one layer deeper. For example: the application crashed, because the database connection timed out, because the database was at full CPU, because a new report ran an unindexed query, because the release process had no DBA review. Root cause: a missing review step.

Fishbone (Ishikawa) diagram: for complex problems, group possible causes under branches such as People, Process, Technology and Environment, then find the dominant one.

Others worth naming: Pareto analysis, Kepner-Tregoe and timeline analysis. The findings are recorded in the Cause notes on the Problem form.

Note: Don't just list techniques. Walk through a short 5 Whys example like the one above.

Both aim to remove root causes. The difference is when the investigation starts.

Reactive: starts after incidents have happened. Example: a payment service went down at peak hours; after service was restored, a problem record was opened to find out why the database stopped responding.

Proactive: starts before incidents happen, from trends, monitoring, audits or vendor advisories. Example: a trend report shows disk usage growing every month and heading for full capacity, so a problem is raised to plan an upgrade before anyone is affected.

Mature organizations do both. Proactive problem management depends on good monitoring and reporting, such as Performance Analytics.

A known error is a problem whose root cause is known and whose workaround is documented, while the permanent fix is still pending (or will not be done because the risk is accepted). The KEDB is the collection of these known errors.

In ServiceNow the KEDB is not a separate table: it is the problem records marked as Known Error, with the Workaround, Cause notes and Fix notes fields filled in.

How it is used:
1. Faster incident resolution: agents search known errors and apply the documented workaround straight away.
2. Prioritization: reports show which known errors cause the most incidents, so those get fixed first.
3. Self-service: selected workarounds can be published as knowledge articles for end users.

Note: A KEDB is only as good as the discipline of keeping workarounds up to date.

Not every incident needs a problem. A problem is raised when the cause is unknown and the issue is likely to come back or has a large impact. Typical triggers:

1. A major incident: almost always followed by a problem to find the root cause, even if service is already restored.

2. Repeat incidents: the same symptom on the same CI or service keeps coming back, for example several incidents in a week.

3. A workaround with an unknown cause, like this case: the user is working again, but nobody knows why it broke, so it will happen again.

4. Proactive sources: trend reports, monitoring alerts, vendor advisories or audit findings, before any incident is raised.

Who decides: the agent or support team can propose it (Create Problem from the incident copies the details and links the two), but the Problem Manager or Problem Coordinator reviews it in Assess and decides whether it is a real problem, a duplicate of an existing one, or not worth investigating.

When not to raise one: a one-off issue with a known cause (for example, a user typed the wrong password), or an issue already covered by an existing problem. Then link the incident to that problem instead of creating a new one.

Note: Mention that the workaround should still be recorded on the problem, so it becomes a Known Error the service desk can reuse while the root cause is investigated.

Once the root cause and the permanent fix are known, the fix is deployed through Change Management. On the problem form, the "Create Normal Change" (or Emergency) related link creates a change request that is linked back to the problem and copies key details such as the short description and the CI.

After that, the two records stay separate but linked:
- The problem shows the change in its related list, and the change shows the problem it came from.
- Each follows its own lifecycle. The problem stays in Fix in Progress while the change goes through approval and implementation.
- When the change is closed successfully, the problem can be resolved. If the change fails, the problem stays open and a new change can be planned.

Note: Not every problem needs a change. If the fix is a documented workaround, an accepted risk or user training, no change is required.

This is a recurring incident pattern, which is exactly what Problem Management is for.

1. Raise one problem record (for example, "Recurring VPN failure on Monday mornings") and link all the related incidents to it.

2. Assign it to the network team and set the priority based on the business impact.

3. Do the RCA. The same time every week points to a scheduled trigger, such as weekend jobs leaving stale VPN sessions that use up the licences before the Monday rush.

4. Document a workaround straight away, for example clearing stale sessions on Sunday night, so the service desk can apply it.

5. Raise a change from the problem for the permanent fix, such as moving the cleanup job or adding licence capacity, and schedule it before the next Monday.

6. Watch the following Mondays. If the incidents stop, resolve and close the problem and the linked incidents.

Use a before update Business Rule on problem with the condition "State changes to Resolved OR State changes to Closed". Collect the open task numbers in one query so the message is useful:

(function executeRule(current, previous) {
    var openTasks = [];
    var taskGr = new GlideRecord('problem_task');
    taskGr.addQuery('problem', current.getUniqueValue());
    taskGr.addActiveQuery();
    taskGr.query();
    while (taskGr.next()) {
        openTasks.push(taskGr.getValue('number'));
    }
    if (openTasks.length > 0) {
        gs.addErrorMessage('Close these problem tasks first: ' + openTasks.join(', '));
        current.setAbortAction(true);
    }
})(current, previous);

Note: Why not just a UI Policy or Client Script? They only run on the form. List edits, imports, REST calls and other scripts would still close the problem. A before Business Rule protects the data no matter how the update arrives. You can add a client-side check as well, but only for a nicer experience.

1. Run it asynchronously (an async Business Rule on problem, "State changes to Resolved", or a Flow), so the user resolving the problem doesn't wait for every incident update.

2. Find the linked incidents in one query, filtering out what should not change: already resolved or closed, and reopened ones (reopen count above zero, a sign the fix didn't hold for them).

3. Copy the fix into the resolution notes and reference the problem number.

(function executeRule(current, previous) {
    // The Problem reference field on incident: problem_id in the base system.
    // Confirm the name on your instance (Configure > Dictionary) before using it.
    var PROBLEM_FIELD = 'problem_id';

    var incidentGr = new GlideRecord('incident');
    incidentGr.addQuery(PROBLEM_FIELD, current.getUniqueValue());
    incidentGr.addActiveQuery();
    incidentGr.addQuery('state', '!=', 6);       // not already Resolved
    incidentGr.addQuery('reopen_count', 0);      // leave reopened incidents for an agent to review
    incidentGr.query();
    while (incidentGr.next()) {
        incidentGr.setValue('state', 6);         // Resolved
        incidentGr.setValue('close_code', 'Resolved by problem');   // use a code from your choice list
        incidentGr.setValue('close_notes', 'Resolved by ' + current.getValue('number') + ': ' + current.getValue('fix_notes'));
        incidentGr.update();
    }
})(current, previous);

The notification question: setWorkflow(false) would stop the emails, but it also skips every other Business Rule, SLA update and metric on those incidents, so the data would be wrong. Better options:
- keep the workflow running, and add a condition to the "incident resolved" notification so it doesn't send for updates made by this process (for example, when the resolution code is "Resolved by problem"), sending one summary per caller instead;
- for very large volumes, process the incidents in batches from a scheduled job rather than in one long transaction.

Note: Interviewers want to hear the trade-off, not just the loop. Mention why reopened incidents are skipped and what setWorkflow(false) really turns off.