question Business rules doubts in Community Central forum

Business rules doubts

NIHARADN — Thu, 11 Jun 2026 07:25:32 GMT

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.

Re: Business rules doubts

Yaramala — Thu, 11 Jun 2026 10:06:19 GMT

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

Re: Business rules doubts

Rakesh_M — Thu, 11 Jun 2026 10:16:00 GMT

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

Re: Business rules doubts

armanoj — Thu, 11 Jun 2026 10:23:21 GMT

@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.

Re: Business rules doubts

PoonkodiS — Thu, 11 Jun 2026 12:12:34 GMT

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.