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();

[James Byrne]

Thanks John,

Can't say I've noticed that behaviour before, although most list edit scenarios I've accounted for don't trigger the generation of a new record.

In this scenario I might just lock down the list edit access, like you've mentioned I have also encountered issues with list edits for different scenarios before, just not this particular one.

I could try alter the trigger conditions of the BR so as it triggers after everything is completed, however there's no guarantee the next user wouldn't come along and perform the actions in a different order.

I was more so thinking of Visual Task Boards when deciding to open up the list edit access, as with New York they seem to have bundled list edit and VTB together for the most part with regards to securing them.

I'll just lock them down for this scenario, thanks very much for your help and feedback on this.