Business rules doubts

[NIHARADN]

Hi,

I am learning Business Rules in ServiceNow and I have a doubt.

When creating a Problem record from an Incident using a Business Rule, how many fields are typically mapped?

For example, in my script I am only mapping:

• short_description

• description

Is this sufficient, or should additional fields such as category, assignment group, impact, urgency, or configuration item also be mapped?

My script creates the Problem record successfully, but I would like to understand the best practice followed in real-world implementations.

Thank you.

[Yaramala]

Hello @NIHARADN 

There is no fixed number of fields that must be mapped from Incident to Problem. The best practice is to map only the fields that help the Problem team start root cause analysis, not to blindly copy every Incident field.

Mapping only short_description and description is technically enough to create the Problem, but in real implementations I would usually include a few more fields for context, such as:

• Short description

• Description

• Configuration item / affected CI

• Business service / service offering, if used

• Category / subcategory, if your organization uses them consistently

• Impact / urgency / priority, only if they are meaningful for Problem prioritization

• Assignment group, only if the same team should own the RCA

• Company/location, if relevant

• Link back to the source Incident using problem_id on the Incident or related Incidents

I would avoid copying fields like Incident state, resolution notes, close code, SLA fields, caller-specific data, or anything that is only relevant to restoring service.

Also, from a process point of view, be careful with auto-creating Problems through a Business Rule for every Incident. A Problem should usually be created when there is a recurring issue, unknown root cause, major incident follow-up, or RCA requirement. If you create Problems automatically for all Incidents, it can create unnecessary Problem records and reduce data quality.

So my recommendation is:

Map enough context for RCA, keep the Incident linked to the Problem, and let the Problem owner update the Problem statement, assignment, priority, and RCA fields as needed.

Please mark this as Helpful if it helps.

If this addresses your question, please mark this response as Accepted Solution 

 or mark has helpful 

 if you find it helpful.

Thank you!

TejaswiniY

[Rakesh_M]

Hi @NIHARADN ,

When a Problem is created from an Incident using the out-of-the-box (OOTB) UI Action, the following fields are automatically mapped from the Incident to the Problem record:

• description
• short_description
• cmdb_ci
• impact
• urgency
• priority
• company
• sys_domain
• business_service
• service_offering
• category
• subcategory

The field mappings are configured in the system property com.snc.problem.create_from_incident.attributes

[armanoj]

@NIHARADN , 

You can map additional fields from the Incident to the Problem record, such as CI, Category, Origin Task, Problem Statement, Description, Assignment Group, Impact, and Urgency.

Typically, the Assignment Group on the Problem is determined based on the selected CI, ensuring that the appropriate support team is responsible for investigating and resolving the issue. If resolving the problem requires a change, a Change Request can also be created directly from the Problem record as part of the resolution process.

[PoonkodiS]

Hi @NIHARADN 

The Scenario

An entire office building suddenly loses its internet connection, causing employees to flood the IT Service Desk with tickets.

How the Data Maps Over

Imagine your Business Rule automatically copies these specific fields from the major Incident over to a new Problem record:

• Short Description: "London Office completely offline – no internet connectivity."

  • The Use: The Problem team instantly knows the exact technical symptom they are investigating.

• Configuration Item (cmdb_ci): London-Core-Router-01

  • The Use: The network engineers don't waste time checking individual laptops; they know the exact piece of hardware that failed.

• Category / Subcategory: Network / Routing

  • The Use: The ticket is automatically categorized correctly for the end-of-month IT stability reports.

• Impact & Urgency: 1 - High / 1 - High (Priority 1)

  • The Use: The Problem Manager sees this is a P1 and instantly assigns a senior engineer to it, dropping all lower-priority work.

• First Reported By Task: INC0010432

  • The Use: The engineer can look back at this original incident to see the diagnostic logs and timestamps from when the ping dropped.