Business rules doubts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago - last edited an hour ago
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.