- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2025 11:58 PM
Hi guys,
is there a way how to disable dot walking in a template?
Example:
If I create a template for incident table, I am able to use "Show related fields" option and set e.g. Configuration item.Owned by to some value.
This can end in two scenarios:
1. Such field is not on form and applying the template will show a warning that the field is not on the form, or
2. The dot-walked field is on the form and applying such template can unintentionally alter data in particular CI, not incident itself
Is there a system property or attribute to disable "Show related field" on a template?
The filed is type "template_value"
I found one community post in google that may be addressing this, but clicking on it shows it has been archived and redirects me to ITSM
https://www.servicenow.com/community/itsm-forum/disable-dot-walking-though-a-template/m-p/2427935
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2025 11:28 PM
Hi,
I got a response from ServiceNow support, it seems there is indeed no OOB settings to manage this.
So it's either BR or client script, we'll probably go with BR (I already mentioned this is the second thread).
BTW, your script is not entirely right, any template value can contain a dot (e.g. short description value) and your script would prevent submitting.
I am just gonna post it here in case someone is trying to get achieve the same:
(function executeRule(current, previous /*null when async*/ ) {
var dotWalkArr = [];
var conditionArr = [];
conditionArr = current.getValue('template').split('^');
for (var i = 0; i < conditionArr.length; i++) {
var field = conditionArr[i].split('=')[0];
if (field.includes('.')) {
dotWalkArr.push(field);
}
}
if (dotWalkArr.length != 0) {
gs.addErrorMessage('Following fields contain dot-walking reference which is not supported: ' + dotWalkArr.join(','));
current.template = previous.getValue('template');
current.setAbortAction(true);
}
})(current, previous);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2025 12:25 AM
Hi @jency83
Practically, this is not a good use case for restricting the dot walk. The reason is that a form has been built with a combination of many fields, and these fields are defined across one or more tables. If you restrict the dot walk, you're only limiting access to one table field, which is not ideal. Therefore, it's better to avoid this use case, as it can negatively impact the system's functionality.
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.
Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]
****************************************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2025 01:05 AM
Hi, thanks for your input.
However, I disagree with what you are saying, especially because of the two examples I gave.
I hardly see a form consisting of dot-walked fields from other tables.
I would always suggest this to be either a bad practice, or at least make sure there is an UI policy to set such field-read only, so user does not unintentionally change value in a table he didn't want to.
I can imagine a good sys_dictionary attribute would be very helpful in this case.
I can use before BR to check for dot-walked value but this is not ideal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2025 01:13 AM
Hi @jency83
Here is the incident table, and the fields are coming from the task table, which is an example of dot walking. The system has been designed in such a way that components can be reused, and how to handle those components or fields is the admin's responsibility. Even if a user has admin rights, it means they know what they’re doing. We can set everything in the system, but if we make changes, it would be very hard to manage.
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.
Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]
****************************************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2025 11:21 PM
I don't think you are right. Based on what you are saying and showing on picture, I understand if you create a template for incident table, you cannot set a value of field which is inherited from task table. This is, however, not true. And it doesn't matter if you allow or disallow dot-walking.