A
n important part of managing the flow of any record submission is to be able to validate the information from the form or record and provide feedback to the end-user if there is something that they need to change. While there are many ways to validate different kinds of data, preventing the submission of that data is pretty straight-forward. In Service-now, there are two different ways to stop the submission of a record. One method works client-side (in the rendered html form) and the other method works in server-side javascript as the record hits the database.
Client-side abort:
Preventing client-side form submission is very simple. All you need to do is set up an ‘onSubmit’ client script and return ‘false’ in the script. Of course, you won’t simply want to return false, you’ll want to actually validate something first.
It has also been brought to my attention that simply returning false, while aborting the submission correctly, also allows users to navigate away from the form without checking for modified fields and confirming the navigation with users. This is known as the ‘dirty form’ capability in ServiceNow. The reason for this is that ‘dirty form’ checks for a ‘g_form.submitted’ option that gets set to true when the form is submitted. ‘dirty form’ needs this to be set to false so the solution is to set ‘g_form.submitted’ to false before aborting the submission. Thanks to Frantisek below for pointing this out!
Here’s a simple example that aborts submission of the user tries to submit a high-priority incident.
if(g_form.getValue('priority') == 1){
alert('Record submission aborted.');
//Make sure dirty form still works
g_form.submitted = false;
//Abort the submission
return false;
}
}
Server-side abort:
Server-side validation is also very simple. The primary difference with server-side validation is that it works in a business rule. Because of that, the syntax is slightly different. The most important part of this type of validation is that your business rule has a ‘When’ value of ‘Before’…so that your business rule runs before insert or update…otherwise the database action will have already taken place by the time your script runs.
Server-side aborts make use of the ‘setAbortAction’ method. SetAbortAction simply tells the system to abort the next database action (insert, update, or delete) for the record it is used against. Here’s an example script and screenshot of setAbortAction in a ‘Before’ business rule.
current.setAbortAction(true);
}
Whenever I use this method I always add another information message so it is clear to the user what happened.
gs.addInfoMessage('Record submission aborted.');
current.setAbortAction(true);
}
Hi Mark,
How “previous” object works in relation with current.setAbortAction if there are multiple records to update and one of them has been aborted by setAbortAction. What will be the current and previous values if that is the case?
I am observing one issue where for mulltiple record update from schedule job, busines rule validate some data before update and suppose data is not valid for first ticket in queue then business rule aborts the action. For the next ticket in queue now for some reason ‘previous’ variable keeps the earlier ticket in it for which action was aborted for all other processing done afterwards. Ideally previous and current for next record should be same but in this case because of first ticket was aborted it becomes previous for next all tickets. is this correct behaviour? and how can we handle this so that for all records previous and current should be same even if any of the record is aborted in between for multiple records.
That sounds like a bug to me. Make sure you can reproduce it on a ServiceNow demo instance and then contact support with the details.
Hey Mark,
Even I am facing similar issue in SN instance. If i am running any update job on say cmdb_ci table and in between it encounters a before update business rule which is written on the same table does setAbortaction, entire job is stuck.
Is there any way out through which we can capture this setAbortaction and make sure that the update job is completed properly.
Thanks, Amit
The only sure way I know of to deal with that is to filter out those records before you do your update. I haven’t ever tried this though, and it surprises me that ‘current.setAbortAction’ would have any impact on the rest of the query. It should just impact the ‘current’ record. You may want to reach out to SN support on that.
Is there is anyway to hide the “Invalid Update” error message after using current.setAbortAction(true) in my before insert business rule.
Please let me know.
There isn’t to my knowledge. I always add a second ‘addInfoMessage’ or ‘addErrorMessage’ line to any script containing ‘setAbortAction’ so that I can clarify to the user why the update was invalid.
Hi Mark,
I have client-side abort that is working well. However if the submission is aborted and the user clicks reload form, the form is reloaded immediatelly. There is not the usual alert ‘Changes have been made’. Am I doing something wrong?
if(g_form.modified){
alert('Changes have been made. Save the form.');
return false;
}
}
You’re not doing anything wrong, but I think you’ve stumbled upon a ServiceNow bug that has probably been around since the beginning. ServiceNow has a ‘g_form.submitted’ check that goes along with ‘g_form.modified’ to make the dirty form capability work. That isn’t being set correctly when you abort with your client script. The solution is to set ‘g_form.submitted = false;’ right before your ‘return false;’ line in your script. I’ve updated the example script above with this fix. Thanks for the feedback!
Hello Mark, guys,
I have a long form, and in the middle of it there is a checkbox which has to be true when submit.
The script I use is the first one mentioend in the article, on submit client script. Works good!
I wonder how can I do that after the submit button and the alert popup the screen navigates on the form where the checkbox is placed? I mean scrolling up until the checkbox. Even some higlight error message would be nice under that checkbox there to say that please select this.
Thank you!
Normally you could use the javascript ‘scrollIntoView’, but I can’t get this to work in ServiceNow in my testing. You can google that and research it though and give it a try yourself.
Hi Mark,
If i dont want to show invalid insert. Only want to show message. then?
It’s not possible to suppress that message unfortunately. You’re stuck with it so the best thing you can do is include an additional info message to clarify what it means.
Hi Mark,
This was just what I was looking for. Thank you!
Great to hear. Thanks!
I’m using the g_formsubmitted = false and return false; but these are not preventing the submission of my catalog item. please see my script below.
var grp = new GlideRecord('sys_user_grmember');
grp.addQuery('group', g_form.getValue('ad_group'));
grp.addQuery('user', g_form.getValue('ad_user'));
grp.query(groupMemberCallback);
function groupMemberCallback(grp){
//If user is a member of selected group
if(grp.next()){
//Do something
g_form.showErrorBox("ad_user", "Error: user is already a group member " + 'ad_user.name' );
g_form.submitted = false;
return false;
}
}
}
Basically I have a catalog item with two variables, a username and group name. I’m checking to see if the user is already a group member and if they are I’m displaying an error around the user variable and preventing the form from submitting, of course if the user is not a group member the form should submit. I can identify if the user is a group member but cannot prevent the form from submitting. Any insight you can offer is appreciated!
Try commenting everything else out but ‘return false;’ within your ‘if’ statement and adding an ‘Alert’ message right before ‘return false;’. Does the script show the alert? Does it prevent the submission? If it shows the alert and stops the submit correctly then your problem is probably with ‘g_form.showErrorBox’, which I don’t think is available in catalog client scripts and will need to be removed.