Requested for not populated in catalog item
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2024 04:15 AM - edited 07-15-2024 04:15 AM
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2024 04:24 AM - edited 07-15-2024 04:36 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2024 04:39 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2024 04:47 AM
first create a hidden variable(opened_by) which will reference user table , then set the default value to logged in user
then map the variable to opened by table field
current.opened_by= current.variables.opened_by
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2024 05:18 AM
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