Breakdown: Auto-population of Variables
Recently I posted a poll on LinkedIn which surprisingly has quite a mixed responses so I thought to drilldown what happens in the background of this feature.
The “Auto-populate a variable” feature in the Utah release of ServiceNow’s Service Catalog allows for easy population of variables based on a reference variable within a catalog item. It simplifies the process by enabling dot-walking to fields on the reference table without complex scripting. The feature is responsive, works on page load, and automatically clears the auto-populated variable if the dependent variable is cleared. This new functionality reduces the need for previous methods like GlideAjax or Catalog Data Lookup Definitions, streamlining variable management in the Service Catalog.
You can also refer here: Auto populate Service Catalog Variables — Deepak Negi — Medium
The expected behavior of this implementation is to offer a low-code solution that automatically populates data on a form, visible to all users without the need for additional scripting. However, a problem arises when users without specific roles or access to the relevant table or field attempt to use the feature — it does not work for them due to the current configuration. To address this, we need to examine the process step by step to understand how it functions and identify potential solutions.
To understand how the auto-population feature works in ServiceNow, follow these steps:
- When you’re about to change values on the form, open Developer Options by pressing F12.
- Navigate to the Network Tab and select Fetch/XHR to monitor the network activity.
3. Look for an entry named ‘dynamic_value’ when a value is selected on the form. Click on it and review the Header tab to see the API endpoint being called.
4. Switch to the Response tab to view the API’s response, which should show the values configured to be auto-populated via dot-walking.
5. For users with read access to the table, the values will populate correctly.
6. However, for users without read access to the fields, the response will not include the necessary values, as the ‘value’ and ‘displayValue’ attributes are empty.
Breakdown: Lets deep dive how this actually works, SN has introduced a new Resource in “Service Catalog API”.
Navigate here to see the complete list of available methods.
Service Catalog API: https://<your_instance>.service-now.com/sys_ws_definition.do?sys_id=b4558e83c3a302006f333b0ac3d3ae8e&sysparm_view=
Search for “Get Dynamic Value” method or navigate here
https://<your_instance.service-now.com/sys_ws_operation.do?sys_id=f90b7b9febe011106fb3951ff1522873
Within this method, pay attention to line 42, where dynamicDotWalkPath specifies the field to be dot-walked for value retrieval. This line is crucial for understanding how the system determines which field's value to fetch for auto-population.
it explicitly states that if the user does not have read access to the particular element or field, the value and displayValue attributes will not be populated and will remain empty.
Additionally, out-of-the-box (OOB) logs are generated to record instances where read access is restricted, providing a clear audit trail for access-related issues during auto-population.
This explanation outlines the overall workflow of the auto-population feature in ServiceNow and should help clarify how the process functions, including the access restrictions and their implications on the feature’s behavior.
Challenge: How do we utilize this feature without giving the read access to every other user on the target table.
I hope this issue has been flagged to ServiceNow’s attention, and that a resolution will be forthcoming, as granting read access to every user is not a viable option. I trust this article has provided you with new insights. Happy learning!
Deepak
Connect me on LinkedIn
