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

bookman1502 · ‎08-26-2015

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

coryseering · ‎08-27-2015

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.

View solution in original post

coryseering · ‎12-13-2016

Hi Charlie,

Looks like the only things that could be clearing the value are:

1. The UI Action script (client-side portion, if any)

2. The UI Action script (server-side portion)

3. A Before insert/update Business Rule with an order less than or equal to 10.

So that is where you should check. If it's using the default Submit UI Action, make sure that no one has modified that action. If it's using some other UI Action, go check out what the script is doing. Be aware that it might be marked 'client' and have both client-side and server-side code in it (see here for an example: Client & Server Code in One UI Action - ServiceNow Guru ). Add some logging to the server portion fo the UI Action and see if the value is filled out when it processes.

If the UI Action is clean, it's time to take a harder look at your Business Rules.

If none of that pans out, contact Support. Either something very simple is going on here (like you're checking for a field with one name, but it actually has a different name) or something really complicated. Support can help you figure out which.

Thanks,

Cory

hobbes113 · ‎12-13-2016

Cory,

As I'm trying to step through the process with more logging on my UI Action, let me throw one more fact at you. When I add a default value for the Node field, and I submit a new ticket, the node saves. If I try to change the default value when initially submitting, the record saves the DEFAULT value, not the one I selected. Going back in to that record, I am able to update the Node field and save as expected. I ask this, as it seems to show the field isn't getting cleared. It seems like interaction with the field on initial submit is just not being tracked. Does that trigger any additional thoughts? If not, I will be happy to track down the Support crew.

Thanks again for all the help. It's been educational!

Charlie

coryseering · ‎12-13-2016

Hi Charlie,

It really sounds like the field that you're filling out client-side, and the field you're expecting to have a value server-side, are different fields. Is it possible you have two fields with similar labels?

Thanks

Cory

hobbes113 · ‎12-16-2016

Cory,

It's possible, but I'm also experiencing this issue with another custom string field. If I enter values in either field, I'm losing the data. I'm also using similar fields in the Problem table and those work fine. The record I am using only shows one field with the name 'u_node'. Is it possible the field's definition was changed on the server version, but not reflected in the client version?

Can you tell I'm grasping here? And yes, ticket is being submitted.

Thanks again, Cory,

Charlie