Does Demand record captures the information who approved it from scenarion planning?

[Madhukar_P]

We  Approve Scenarios in scenario planning and Project created automatically from demands in approved scenario.  If  I check on demand record there won't be information on who converted it to a project and under which scenario.   Is there any field which stores this information of scenario and approver on demand record for audit purposes. 

[BeingKhan]

Hi,

This is a very valid audit and traceability question, and you are correct to notice that this information is not obvious on the Demand record after scenario approval.

Let me explain what happens OOB, what is and is not stored, and how customers typically handle audit requirements in Scenario Planning.

---

Short Answer (Direct & Honest)

❌ Out of the box, there is NO single field on the Demand record that stores:

• Which scenario converted the demand into a project

• Who approved the scenario that triggered the conversion

This is by design, not a configuration gap.

---

Why This Happens (Important Concept)

In Scenario Planning, a scenario is treated as a temporary decision model, not a transactional object.

When you:

1. Approve a scenario

2. Convert Demands → Projects

ServiceNow performs a one-time orchestration action:

• Creates Projects

• Updates Demand state

• Then discards the scenario context

The Demand is not “owned” by the scenario after conversion.

---

What Is Stored OOB (And Where)

✅ 1. Scenario Approval Information

Stored on the Scenario record itself, not on Demand.

You can audit:

• Scenario approvers

• Approval date/time

• Approval state

But this data does not propagate to Demand.

---

✅ 2. Demand → Project Relationship

On the Demand record:

• You can see the Project reference

• You cannot see why or by which scenario it was created

This answers what happened, not how it happened.

---

✅ 3. System Audit / History (Partial Traceability)

You may infer information using:

• sys_history_line

• sys_audit

• Workflow / Flow execution context

Example:

• Demand state changed at the same timestamp as scenario approval

• Project created by a system user / flow

⚠️ This is forensic, not explicit, and not reliable for formal audits.

---

What Is NOT Stored OOB (Key Gaps)

Information Stored on Demand?

Scenario sys_id	❌
Scenario name	❌
Scenario approver	❌
Scenario approval date	❌
“Converted by scenario” flag	❌

There is no hidden field you are missing.

---

Why ServiceNow Designed It This Way

From a platform perspective:

• Scenarios are planning artifacts

• Demands & Projects are execution artifacts

• Mixing the two creates:

  • Historical dependency

  • Data bloat

  • Complex rollbacks

So ServiceNow intentionally keeps them loosely coupled.

---

Recommended Solution (Best Practice for Audit)

✅ Add Explicit Audit Fields to Demand (Most Common Approach)

Customers with audit/compliance needs typically add:

• u_converted_from_scenario (Reference → Scenario)

• u_scenario_approved_by

• u_scenario_approval_date

Then populate them at conversion time.

---

How to Populate (High-Level)

Hook into:

• Scenario approval flow

• Demand-to-project conversion logic

At the moment of conversion:

• Capture scenario sys_id

• Capture approver

• Write once to Demand

✔ Clear audit trail
✔ Reporting-friendly
✔ Upgrade-safe

---

Alternative (Weaker) Option

If customization is not allowed:

• Rely on Scenario record + timestamps

• Correlate with Demand state change

• Document the limitation for auditors

This works for internal review, not strict audits.

---

Strong Practitioner Opinion

If auditability matters:

Do not rely on implicit system behavior
Persist decision context explicitly

Scenario Planning is a decision engine, not an audit engine.

---

Final Answer (Clear)

• ❌ There is no OOB field on Demand storing scenario or approver details

• ✅ Scenario approval data exists only on the Scenario record

• ✅ For audit purposes, you must extend Demand and capture this data during conversion

---

Platform Context

This behavior is consistent across releases of ServiceNow that support Scenario Planning and Demand Management.

---

[Madhukar_P]

Khan thank you for the detailed response. In which script include of scenario planning you think we can map these custom fields . I see script includes of Scenario planning or protected with read only policy

• u_converted_from_scenario (Reference → Scenario)

• u_scenario_approved_by

• u_scenario_approval_date