How to Automatically Populate Request Form Descriptions from a ServiceNow Catalog Item

When users submit a ServiceNow catalog item, they often provide specific inputs, such as a detailed description or a brief summary. While these values are captured in the Requested Item (sc_req_item), they do not automatically appear in the Request (sc_request) record by default. This leads many developers and administrators to ask: how can we auto-populate the Description and Short Description fields on the Request form with values entered in the catalog item?

In this article, we explain how to achieve this functionality using scripting techniques within workflows or business rules, ensuring a seamless data transfer from catalog item inputs to the parent Request record.

Understanding the Data Flow in a Catalog Request

In the ServiceNow request fulfillment model:

• Catalog Items are submitted by users via the Service Catalog.

• A Request (sc_request) is generated to group one or more Requested Items.

• Each Requested Item (sc_req_item) is associated with the catalog item and holds user-provided input as variables.

  
  

However, the sc_request record does not directly inherit fields like short_description or description from the catalog item or its variables unless explicitly scripted to do so.

Common Use Case

Consider a catalog item where users provide:

• A Short Description field (e.g., “Access to Adobe License”)

• A Description field (e.g., “Please provide a license for Adobe Creative Cloud.”)

  
  

Once submitted, these values exist in the variables of the Requested Item. To reflect this information on the Request record itself, a script must be used to copy the values over.

Solution 1: Using a Workflow ‘Run Script’ Activity

One of the most straightforward methods is adding a Run Script activity to the catalog item's workflow. This script accesses the current sc_req_item record and updates the associated sc_request record.

// Update the parent Request with values from the catalog item variables
var req = new GlideRecord('sc_request');
if (req.get(current.request)) {
    req.description = current.variables.description;
    req.short_description = current.variables.short_description;
    req.update();
}

How it works:

• The script retrieves the parent Request record using current.request.

• It copies the description and short_description from the catalog item variables.

• It updates the Request record accordingly.

  
  

Important Considerations:

• Ensure that the variable names (not labels) in your catalog item are exactly description and short_description, or update the script to match the actual variable names.

• This should be placed after the item is created in the workflow to ensure that all fields are populated when the script executes.

  
  

Solution 2: Business Rule on Requested Item

Alternatively, an asynchronous Business Rule can be created on the sc_req_item table to perform this update after insert or update.

Sample Script:

// Async Business Rule on sc_req_item
(function executeRule(current, previous /*null when async*/) {
    var req = new GlideRecord('sc_request');
    if (req.get(current.request)) {
        req.description = current.variables.description;
        req.short_description = current.variables.short_description;
        req.update();
    }
})(current, previous);

Why async? Running the rule asynchronously avoids delays in the user interface and ensures the Request record is already available.

Caveat: Handling Multiple Requested Items

If a request contains multiple items, each sc_req_item might overwrite the Request's description fields. In such cases:

• Consider aggregating the item descriptions into a custom multiline field on the Request (e.g., items_summary).

• Append values rather than overwrite them.

• Use conditions to only populate values if they are not already set.

  
  

Conclusion

Automatically populating the Description and Short Description fields on the Request (sc_request) record from a catalog item's variables enhances visibility and clarity across fulfillment processes in ServiceNow. This can be achieved effectively through a workflow Run Script or an asynchronous Business Rule on the Requested Item (sc_req_item) table.

Key Takeaways:

• Use a workflow activity or Business Rule to transfer data from variables to the parent Request.

• Ensure variable names match exactly what your script references.

• Handle multi-item requests with care to prevent overwriting or data loss.

  
  

Next Steps:

• Review your catalog item variables to confirm naming consistency.

• Test the script in a sub-production environment.

• Consider user experience: ensure that what users input is visible throughout the request lifecycle.

  
  

By applying these scripting strategies, ServiceNow developers can improve data transparency and streamline fulfillment operations across the platform.