Mandatory field values populated via list view (prompt) blank in current.[field name] (after insert/update BR)

[James Byrne]

I've an after insert/update business rule which simply logs an incident record when certain conditions have been met.

The conditions can be fulfilled while on the form, enforcing the population of mandatory fields etc, and then submitting.

The conditions can also be fulfilled while on the list view, again it enforces mandatory fields etc there too.

Even though I'm using an after insert/update business rule, any mandatory field values being populated when prompted by the list editor are unavailable to the current.[field name] script and leaves the target field blank once the incident is logged. 

If those same mandatory fields are populated when prompted while the user is on the form itself, the current.[field name] script has no problem fetching the data and populating the target field on the incident.

I've played around with changing the business rule to before update also and it still can't see the newly input value when done via the list editor.

Any idea why this happens? I thought after update would see it since the data should be committed to the database by that point?

Couple of the mandatory fields I've tested populating via the list view are Assigned To and Close Notes, logging their values via the script shows they're blank when populated via the list view, but their values are available when populated from the form.

The business rule logic itself is very basic:

Trigger Condition: When field is x and Status changes to x

var inc = new GlideRecord("incident");
inc.short_description =  current.number + ' Failed : ' + current.short_description;
inc.business_service = current.business_service;
inc.description = current.close_notes;
inc.caller_id = current.assigned_to;
inc.assignment_group = current.assignment_group;
inc.parent = current.sys_id;

inc.insert();

[johnfeist]

Hi James

I duplicated what you describe in my PDI and it works the same in list and form views.  I used specific category and subcategory values and state changes to On Hold as criteria, I suspect those are different from yours but shouldn't matter.  I only tested with the setup being after update.  You might try doing that to see if that helps you narrow it down.

You might try embedding debugging statements in the code in case something odd is happening or posbily find where something is failing. 

The only other thing I can suggest is that you may have some other BR that is acting on changes from list view.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster

[James Byrne]

Hi John,

Thanks for your feedback and testing on this.

The issue does appear to be out of the norm from how I understand it should work. It's a very basic script so something else must be at play... I've tried switching the BR to after update only, still no luck.

I've ran the detailed debugging and printed the script values to the logs, I don't see any other scripts which could be impacting it, not to say there isn't one.

In the logs I can see all other pre-populated field values before the list edit update took place, I just can't seem to be able to capture the new values of the fields being populated via the list edit mandatory prompt.

It's a custom table which I'm generating the incident from, but that shouldn't matter, there are very few other scripts running on it also. I'll continue debugging and update if I find the answer.

Appreciate your assistance.

[James Byrne]

Hi John,

I've discovered something interesting.

I left the BR as after update, I also changed the conditions slightly as below:

Previous Condition : field is x and Status changes to x

New Condition: field is x and Status is x

When I trigger it from the form and fill in the 2 mandatory fields it asks for, it logs a single incident with all fields populated.

Now when I trigger the same scenario via the list editor, the BR runs 3 times, it appears to be treating each field update as separate commits. 

When I look at the 3 incidents logged in turn :

1) the first INC is missing both mandatory field values which I filled in via the list editor

2) the second INC has the first mandatory field I filled in but left the second field blank

3) the third INC has all details including the 2 fields populated via the list editor

When I had the BR condition set to 'Status changes to' I must have only been seeing the first update which was regarding the status changing. The other 2 updates for the 2 mandatory fields hadn't ran yet and due to the condition neither would trigger the BR.

Any idea why the list view would treat each field update separately rather than as one transaction? 

[johnfeist · Accepted solution]

Hi James,

What you are experiencing is the difference between how updating from list view and form view work.  In list view, each change is saved as entered (you click on the green check mark).  In form view changes only get saved when you explicitly do a save.

In the case of the three incidents, I suspect that you entered the triggering condition first and then one by one the mandatory ones.  See what happens if you enter the triggering condition lsat.

For a variety of reasons, I don't allow list editing to my fulfillers.  I have a number of reasons that include what you are experiencing as well as there are a lot of fields that are not visible in form view that they can bring up in list view and change resulting in all kinds of issues.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster