Most of the time we struggle to find solutions to problems that look so easy and so common at first glance. But sometimes, after spending a lot of time searching through articles in the ServiceNow community or reading the ServiceNow documentation, we are still not able to find that missing piece that will easily solve our issue.  

In this article, we are providing a solution for one of these situations. 

Problem

On the incident form in the customer’s instance, we have a new custom field – “Affected End-User”. The client wants both fields “Caller” and “Affected End–User” to have default values with the logged-in user. 

If you think about this problem, it looks simple, right? One client script and the problem is solved. 

But what will happen if the incident is created manually. The clients also have CTI integration (Cisco Telephony Integration) which creates a new incident (open a new incident form) and when the user calls, the integration automatically populates the “Caller” field with the user who initiated the call. 

In this case, the client also wants both fields “Caller” and “Affected End User” to have the same values, but this time it should not be the logged-in user. Instead, it must enter the user who triggered the integration and initiated the call. 

Solution

1. One client script that is triggered “onLoad” and populates only “Caller” field with the logged-in user. This script will be executed in all cases, even if the incident is created manually or by the CTI integration. 

function onLoad() {
	//Populate the Caller with the logged in user if the field is empty
	if (g_form.getValue('caller_id') == ''){
		g_form.setValue('caller_id', g_user.userID);
	}
}

2. One client script “onChange” that will be executed when “Caller” field changes and will update “Affected End User” field with the same value as “Caller” field. 

function onChange(control, oldValue, newValue, isLoading, isTemplate) {
	//if (isLoading) {
	//	return;
	//}

	if(newValue == ''){
		g_form.setValue('u_affected_end_user', '');
	} else {
		if(g_form.getValue('u_affected_end_user') == ''){
			g_form.setValue('u_affected_end_user', newValue);
		}
	}
}

3. But now comes the tricky part. The second client script (onChange) will be executed only if we remove (or comment out) the logic, including the parameter “isLoading”.  

“isLoading” can be a good check if you want to trigger scripts after the initial loading. Since an “onChange” client script can run “onChange” and “onLoad”, using “isLoading” will prevent it from running “onLoad”.  

In our case, we want the “Affected End User” field to be populated “onLoad” right after the value of the “Caller” field is changed. And when the integration is used and an incident is created by it, then the “Caller” field will be automatically populated, and this will also trigger the “onChange” client script. 

Do you have another solution to this problem? You can share it with us and open a discussion. 

Learn more about the thrilling features of the new ServiceNow San Diego Release. For more ServiceNow tips and insights, subscribe to our newsletter.