Digital Product Release - Scope - Incident, Problem, Request

[Tommaso2]

Hi all,

Can you please provide a use case to explain when we add incident, problem and request to a Release Scope in the DPR Workspace?

I assume it is doable only if the release is about something already configured, against which it is possible to raise incidents and so on. Is that right?

Many thanks

[Dr Atul G- LNG · Accepted solution]

Hi @Tommaso2 

A release is a bundle of changes, which can include fixes for incidents or problems received.

We add the incident, problem, or change to a release when you are sending the fix for any of these records. For example, a long-standing problem might get fixed, and now as part of the release, you are deploying that fix to production. You can add the problem to the release — this is mainly for tracking purposes.

[Dr Atul G- LNG · Accepted solution]

Hi @Tommaso2 

A release is a bundle of changes, which can include fixes for incidents or problems received.

We add the incident, problem, or change to a release when you are sending the fix for any of these records. For example, a long-standing problem might get fixed, and now as part of the release, you are deploying that fix to production. You can add the problem to the release — this is mainly for tracking purposes.

[MaxMixali · Accepted solution]

🎯

Purpose of “Release Scope” in DPR Workspace

In ServiceNow Release Management, a Release Scope defines what work items are part of (or impacted by) a release.

It’s a traceability and risk control mechanism that helps you understand:

“What existing operational records (incidents, problems, requests, changes) are related to this release?”

---

🔍

When and Why You Add Incident / Problem / Request to a Release Scope

✅

Use Case 1 – Release triggered by recurring incidents (root cause fix)

Scenario:

• Multiple Incidents have been raised due to the same software defect (e.g., repeated crashes in a payment service).

• A Problem record identifies the root cause — a bug in a backend component.

• A Change or Release is created to deploy the fixed code into production.

Adding to Release Scope:

• You link those Incidents and the Problem to the Release via “Release Scope”.

• This provides traceability — you can later report:

  “These 5 incidents were resolved as part of Release 2025.04 (Hotfix).”

• It’s essential for Post-Implementation Review and Problem Closure evidence.

📊 Outcome:

• Stakeholders can measure incident reduction post-release.

• Compliance teams can audit: “Which defects/incidents were addressed in this release?”

---

✅

Use Case 2 – Release delivers a service request or new feature

Scenario:

• A Service Request (e.g., “Add new workflow to onboarding portal”) requires code/config changes.

• Developers implement this in a Change/Release.

• Once ready, the Request can be linked to the Release Scope.

Adding to Release Scope:

• You add the Request (RITM or REQ) to the Release so that:

  • Its fulfillment lifecycle is tracked within the release timeline.

  • The release owner can ensure all related requests are delivered and closed with the deployment.

📊 Outcome:

• Business sees which Requests are delivered in each release wave.

• PMO can trace which backlog features were implemented per release.

---

✅

Use Case 3 – Release resolves a Problem

Scenario:

• A Problem Record is raised (e.g., “Slow performance in mobile app checkout”).

• Root cause: suboptimal query in code.

• Development fixes it, packaged as part of a Release.

Adding to Release Scope:

• The Problem is linked to the Release to indicate this release resolves that problem.

📊 Outcome:

• You can automatically close the Problem record once the Release is marked “Deployed”.

• Provides direct linkage for RCA and audit: Which release contained the fix?

---

✅

Use Case 4 – Post-Release validation of operational impact

Scenario:

• After deployment, users report Incidents that might have been caused by or related to the new release (regression, side effects, etc.).

• Release Manager adds these new Incidents to the Release Scope post-deployment.

📊 Outcome:

• Enables impact analysis and post-release quality metrics:

  • Number of incidents created within 7 days of release (regression indicator).

  • MTBF between releases.

---

🧩

How ServiceNow Enables It (Mechanically)

In DPR (Release Workspace):

• “Scope” tab → “Add Related Records” → select Incident, Problem, or Request.

• These relationships are stored in m2m tables (rm_release_scope, etc.).

• You can view and report on:

  • “Which Incidents/Problems are in this Release?”

  • “Which Release resolved this Incident/Problem?”

---

🧠

Your assumption — partially correct

“It is doable only if the release is about something already configured, against which it is possible to raise incidents.”

✅ Yes — practically, this makes sense.

Usually, you link existing operational records (incidents, problems, requests) that are about a deployed or configured service/component.

You wouldn’t link random incidents — only those relevant to the scope of work in that release.

However:

• You can technically add any record, but it only makes business sense when the release changes or affects the same configuration item(s) (CI) that those operational records reference.

• It’s about maintaining logical traceability, not just data linkage.