BRs Running even after setAbortAction is true in BR running before them

[BhupeshG]

Hello Friends - I have BR X which run on Order = 50 and do the below stuff but I found even though I get error pop up saying invalid insert it does not stop another BR Y which is on   order 100,000 . Therefore the WS call is made and data is sent to External integration for an invalid ticket.

Kindly advise how can stop this

(function executeRule(current, previous /*null when async*/) {

// Add your code here

if(gs.isInteractive())

{

gs.addErrorMessage('Please assign this Incident to SNOW Group before assigning to External Group');

current.setAbortAction(true);

}

})(current, previous);

[Dave Smith1]

That's now how I read it in the API docs... It says that it abort the next insert/update/delete action. If BR1 aborts, then BR2 shouldn't run at all.

I parse that as "next database change" and not "all successive database amendments"... I'll have to try some proof-of-concepts here to clarify.

Either way, if BR2 contains a DB action and BR1 doesn't, then the situation still holds - which sounds true for Bhupesh's case.

Hmm.. more experimentation needed.

[Chuck Tomasi]

I agree, more experimentation is required. Let me know what you find.

In a BEFORE BR, the next action is the commit of update/insert/delete. If both are running before, then one is likely still run even if the DB commit is aborted. Before rules are "staging areas" (IMHO) for the current record before it gets saved, and AFTER are a reaction to what gets saved/committed.

Again, Bhupesh, the webservice call should really go after the save especially since you have an abort action.

[BhupeshG]

The problem here is with Some journal field entry will not be available if it after Insert

I am even trying an CS to stop this itself at Browser level so that BR should not trigger but no success. BRs are still triggered

Client script on Submit -

function onSubmit() {

//Type appropriate comment here, and begin script below

var grp = g_form.getReference('assignment_group', doAlert);

}

function doAlert(grp) {

if (grp.type == 'fa0179f4db217a0017d9f1c41d9619d6')

{

g_form.addErrorMessage("Via CS - Please assign this Incident to Real SNOW Group before assigning to External Group");

}

}

With Regards

Bhupesh Gupta

[Dave Smith1]

There's nothing in the client script that aborts the submit processing there, so the record change will still go through - thus firing the BR.

[BhupeshG]

This is what I received from HI support

Issue is reproducible on OOB instance. According to our documentation<http://wiki.servicenow.com/index.php?title=Scripting_in_Business_Rules#Aborting_a_Database_Action_in_a_Business_Rule> method 'current.setAbortAction(true)' would only result into aborting the database transaction (e.g. when a record is physically inserted / updated / deleted into / from the database). It would however not affect other before Business Rules being triggered within the same transaction. Therefore, it was expected to trigger before BR 2.

I would recommend you to raise an enhancement request following the procedure documented KB article<https://hi.service-now.com/kb_view.do?sysparm_article=KB0547257> and to document the benefits that could be achieved when OOB behavior is changed. Benefits are e.g. to gain performance by not processing subsequent before Business Rules within the same transaction.

With Regards

Bhupesh Gupta