Caller field on record producer for incident being overriden by logged in user

[bookman1502]

I'm doing these exercises in my personal developer instance to improve my ServiceNow skills. I'm working on this exercise: "Set up a record producer for the incident table that contains a 'Caller' and 'Configuration item' reference fields the same as your incident form. Automatically populate these fields onto an incident record without using any scripting."

        Personal developer instances come with a record producer for incident out of the box, but they don't have those two fields. I created the two fields with the 'Map to field" checkbox checked and with the corresponding field selected. While the Configuration item field works just fine, the Caller field keeps getting overridden by the logged in user once the incident is actually created. There are no catalog UI polices for record producers and only 10 catalog client scripts total, none of which would seem to be causing this. Any advice on what might be going on and how to fix it would be appreciated.

Thanks

[The SN Nerd]

1. Activate the Javascript Debugger
2. Right click on the Caller field and click 'Watch Field'
3. Fill out your record producer form and submit
4. Any configuration that has touched the Caller field will be printed in the debugger, with a link to what is changing the field

This should give you the tools to solve your issue.

[bookman1502]

Hi,

The Javascript debugger is a cool tool to know about, so thanks for pointing that out to me, but in the Field Watcher tab there are only two ACLs (read/write) and the UI policy "make fields read-only on close" which is somehow being overridden. In the JavaScript Debugger tab, there are so many scripts that I don't even know where to start.

[coryseering · Accepted solution]

Hey Robert,

There's only a few things that can be acting on the data once it's been submitted. You're going through a Record Producer, so I'd check the Script on the Record Producer (in the "What it will contain" section). By default, the "Create Incident" out-of-box record producer script looks like:

var isMobile = GlideMobileExtensions.getDeviceType() == 'm';

var link = isMobile ? '#/!list/incident/q:active=true%5Ecaller_id=javascript:gs.user_id()%5EEQ' : 'home.do';



var s = 'This incident was opened on your behalf<br/>';

s += 'The IT department will contact you if they need any further information<br/>';

if (isMobile)

       s += 'You can track status from this <a href="' + link + '">List</a> <br/>';

else

       s += 'You can track status from the <a href="' + link + '">Homepage</a> <br/>';

gs.addInfoMessage(s);



current.contact_type = 'self-service';

current.caller_id = gs.getUserID();

if (producer.comments.length > 80)

       current.short_description = producer.comments.substring(0, 79);

else

       current.short_description = producer.comments;

Line 13 shows the caller being set to the currently-logged-in user. If you copied this producer's script, and modified it for your needs, you may have missed that line.

After it goes through this script, the only other thing acting on the submitted Incident before it gets saved to the database will be business rules. You can set a Before business rule with a really low order, on Incident, Before insert, which simply logs the caller_id. That will tell you wether the caller_id is getting changed *before* business rules are invoked, or after/during business rule processing.

[bookman1502]

Yeah, once I commented out line 13 the issue went away. Out of curiosity, I tried to apply Paul Morris' suggestion to the service catalog variable, but unlike the Caller field on the incident form I was unable to watch the field and apply the Javascript debugger. Do you know why that would be?

[coryseering]

Variables are weird. They aren't actually fields on the record- and that's doubly-true for Record Producers. You're looking at an interface that is collecting data, and then creates a record in a totally different table.

I don't know how the Field Watcher works, but I am not surprised that it isn't 100% reliable for variables on the catalog.

Variables are weird.