Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Requested for not populated in catalog item

Anna_Servicenow
Tera Guru

We have catalog item that doesn't have 'requested_for' (default one referring to user table), but another one with same name and its a choice (user or group).

 

Now, In the Request,RITM and SCTASK, the requested for is not populating on submitting Request. How can I fix this ?

11 REPLIES 11

Abnezer G
Tera Guru

Hi @Anna_Servicenow ,

is the requested_for a new variable in catalog item, if it is you need to map it to table field 

something like current.request_for= current.variables.request_for;

 

If my response turns helpful, please mark it as helpful.

We already have one it is a variable and not type reference.

 

How can I create one for requester for referencing to user table, defaulting to opened by , and on submit this should be populated at backed as well

 

first create a hidden variable(opened_by) which will reference user table  , then set the default value to logged in user

 

Screen Shot 2019-09-13 at 2.54.18 PM.png

then map the variable to opened by table field 

 

current.opened_by= current.variables.opened_by

hi @Anna_Servicenow 

 

Understanding the Issue
ServiceNow typically has a default requested_for field that references the user table. However, you've created a custom choice field with the same name, which can lead to conflicts and prevent the automatic population of the requested_for information in requests, RITMs, and SCTASKS.


Solution
Here's a step-by-step approach to resolving this and ensuring the requested_for information is correctly populated:
1. Rename Custom Field: The most straightforward solution is to rename your custom choice field. Choose a distinct name (e.g., "request_type") to avoid conflicts with the default requested_for field.
2. Create a New Field (Optional): If renaming isn't feasible, you can create a new field specifically for referencing the user table. Follow these steps:
* Navigate to your catalog item.
* In the "Variables" section, click "New."
* Create a reference field:
* Name: requested_for (or similar)
* Type: Reference
* Reference: sys_user (User table)
* Default value: javascript:gs.getUserID(); (This will default to the logged-in user)
3. Catalog Client Script: Add a Catalog Client Script to your catalog item to populate the new/renamed field on form submission.

N>B---The following script method is not supported in the Native ServiceNow Mobile APP.

 

function onSubmit() {
    // Get the sys_id of the logged-in user
    var userID = g_form.getValue('sys_created_by');

    // Populate the requested_for field
    if (g_form.getControl('requested_for')) { // Check if the field exists (renamed or new)
        g_form.setValue('requested_for', userID); 
    }
}

 


Replace 'requested_for' with your new or renamed field name.


* Replace 'requested_for' with your new or renamed field name.
4. Business Rule (Optional): If you want to ensure the requested_for field is populated even if the user doesn't interact with the catalog item form, create a Business Rule:
* Table: sc_req_item (Requested Item)
* When: Before (Insert)
* Condition: current.requested_for.nil() (If the requested_for field is empty)
* Action: Javascript syntex ---

 

current.requested_for = current.opened_by;

 


Explanation
* Renaming/Creating New Field: Prevents naming conflicts and allows the default requested_for behavior to function correctly.
* Client Script: Automatically sets the requested_for field to the logged-in user when the catalog item form is submitted.
* Business Rule: Acts as a failsafe, populating the requested_for field with the value from opened_by if it's still empty before the Requested Item is created.
Additional Tips
* UI Policy: Consider using a UI Policy to hide the original custom choice field (if you renamed it) or the newly created reference field to keep the form clean and user-friendly.
* Default Value: If you prefer to default the requested_for field to a specific user or group, you can modify the default value of the field (if you created a new one) accordingly.

 

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community

MackI | ServiceNow Technical Consultant | DXC Technology Australia | ServiceNow Practice | LinkedIn Top IT Operation Voice 2023 | Sydney,Australia