How to Create an Incident or a Service Request from a Single Form in ServiceNow?

[sandeep_goudar]

Hi Community,

I have a requirement in ServiceNow to provide a single form through which users can either raise an Incident or submit a Service Request, based on their selection.

Requirement:

The form contains a mandatory dropdown field named “What do you need?” with the following choices:

• Request something

• Report an issue

The expected behavior is:

1. Request something: When the user selects this option and submits the form, ServiceNow should create a standard Request (REQ) and Requested Item (RITM), following the normal catalog fulfillment process.

2. Report an issue: When the user selects this option and submits the form, ServiceNow should create an Incident (INC) directly.

My understanding so far:

• A standard Catalog Item creates a REQ/RITM.

• A Record Producer can create an Incident directly by targeting the Incident table.

However, I am unsure how to handle both scenarios through the same form without creating unnecessary records or bypassing standard ServiceNow processes.

Questions:

1. Is it possible to achieve this using a single form while conditionally creating either an Incident or a Request?

2. Would a Record Producer targeting the Interaction table, combined with Flow Designer, be a suitable approach?

3. Alternatively, should I use a custom portal component or another approach to route the submission to the appropriate record-creation mechanism?

4. If the Catalog Item approach is used, how can I prevent an unnecessary REQ/RITM from being created when the user selects “Report an issue”?

5. What would be the recommended solution that follows ServiceNow best practices and is easy to maintain?

I would appreciate suggestions on the recommended architecture and implementation steps.

Thanks in advance!

[Kalyani Jangam1]

Hi @sandeep_goudar 
There are 2 ways we can achieve this by using record producer or catalog item but as my understanding record producer is best approach

Step 1: Create the Record Producer

1. Navigate to Service Catalog > Service Catalog Definitions > Record Producers.

2. Click New and fill in the basic details:

   • Name: e.g., General Support Portal

   • Catalog: Service Catalog (or whichever catalog you prefer)

   • Table name: Choose incident

Step 2: Configure the Variables

Add the mandatory dropdown field and any other necessary fields to the Record Producer:

1. Scroll down to the Variables related list and click New.

2. Create the dropdown field:

   • Question: What do you need?

   • Type: Select Box

3. Add the Choices for this variable:

   • Label:  Request Something| Value: request

   • Label:  Report an issue| Value: incident

4. Add any other relevant form fields (e.g., Short Description, Description, Urgency) and configure their UI Policies or container display logic so they show up dynamically if needed.

Record producer script:

ServiceNow Record Producers include an Advanced tab containing a script field that executes upon submission. We will use this script to intercept the submission. If the user chooses Request something, we will abort the incident creation and manually generate a Request sc_request and Requested Item sc_req_item.

Navigate to the Script field in your Record Producer and use the following template:

======================================================================

if (producer.what_do_you_need == 'request') {
// 1. Prevent the default incident record from being inserted
current.setAbortAction(true);

// 2. Define the Catalog Item sys_id that you want to fulfill as a standard Request
// Replace the sys_id below with the actual sys_id of your target Catalog Item (sc_cat_item)
var catalogItemSysId = 'YOUR_CATALOG_ITEM_SYS_ID_HERE';

// 3. Initialize and insert the Cart / Request logic
var cart = new Cart();
var item = cart.addItem(catalogItemSysId);

// Optional: Pass variables from your Record Producer to the target Catalog Item variables
// cart.setVariable(item, 'variable_name', producer.variable_name);
cart.setVariable(item, 'business_justification', producer.description); // Example mapping

// Submit the cart to generate the REQ and RITM
var rc = cart.placeOrder();

// Optional: Add a friendly message or redirect the user
// gs.addInfoMessage('Your request has been submitted successfully as Request: ' + rc.number);
} else {
// If "Report an issue" is selected, proceed with standard Incident creation
current.short_description = producer.short_description;
current.description = producer.description;
current.caller_id = gs.getUserID();
// Any other default field mappings for the incident table
}

=================================================================
For catalog item you need to create flow/workflow and implement logic on this.
Please check if this is helpful or not or if more information required.

[jMarshal]

1. No, not really. There is no "standard REQ/RITM" catalog fulfillment process in SN. Depending on the subscription you are using, there is a Service Catalog available for ITSM, CSM or HRSM customers...but you need to develop the desired "standard REQ/RITM" for your company/purpose...that doesn't just come OOB.

At uLethbridge, we did develop a standard default request form that asks for the users name a short description and a blurb of what they want...but we quickly shifted away from that strategy because it is not really very useful. Instead we use a record producer to create an interaction which a human agent converts to an appropriate (non generic whenever possible) catalog item or an incident, appropriately, as per our internal ITSM process.

...so you need to have at least 2 catalog items developed to support your requirements. One to be the generic item when a user is selecting "request something" and the other to front the psuedo-intake form that you are describing.

2. You can't use a record producer to target a REQ/RITM/SCTASK (oob Service Catalog infrastructure)...if you use a flow designer flow, you don't need a record producer for the incident component of the psuedo-intake form's process engine...the flow itself can/will work as the record producer (the core "create record" action targeting the incident table).

EDIT = I would caution against using a custom script in a record producer to front the oob Service Catalog infrastructure, but as detailed in a previous reply that is a way you could do this with a record producer...however, that embeds your new company process which you seem to be establishing in legacy infrastructure in platform (record producers and custom scripts are not recommended request intake methods in the modern ITSM landscape).

3. Yup! **insert john-c-riley-step-brothers.gif** (interaction table)

4. I feel like you are asking how to prevent the REQ/RITM for the pseudo intake form from being created when the flow that you develop for its process engine is acting as an Incident record producer...and the short answer is - you can't.

...but you can definitely develop that item's flow such that it gracefully handles the resultant REQ/RITM (or use an existing oob solution like GSS as mentioned in @Kieran3's reply).

The first thing I would do to support that plan would be to edit the oob email notification that a client recieves when a REQ/RITM is created with them as the requested_for user such that it doesn't trigger on the pseudo-intake item that you are developing.

...and then also make sure you are closing that item after the new item/inc is created by that flow.

...but having said that, there are many paths you can take - you could configure it such that the pseudo-intake form always makes the "requested_for" user System Admin and then retains the info about the submitting user as a variable to use later when making the INC or REQ in the flow...but that would create issues if you are using User Criteria records as those look to the named/reserved requested_for variable (not a custom form variable) oob.

5. You already answered this yourself - see answer #3

Hope this helps!

[Kieran3]

My suggestion would be to look at Guided Self-Service. You'd still need to make them separately, which you should do to follow the intended process of an requested item, but GSS allows the user to be guided towards an Incident form or a Catalog Request form using natural, user friendly language!

Hope this helps! If you found it useful, feel free to leave a 👍 Kudos. If it answered your question, accepting it as a solution helps others find the answer too.

[jMarshal]

This is a great suggestion and reinforces the answer to Q3 - "should I use a custom portal component or another approach to route the submission to the appropriate record-creation mechanism?"

@sandeep_goudar - there are multiple steps to solving this appropriately. If your company is already using Employee Center, GSS is very likely your best solution.

...but if you are not using EC, you'll first have to deploy it to make use of GSS.