How to prevent Business Rule loop?

[peterraeves]

We have created a situation where sometimes we need to keep two records in sync. So we created a Business Rule that triggers when the one record triggers, updating the other and a second Business Rule doing the reverse. You can already feel where I'm heading with this right? When record A is updated, the BR triggers, updates record B and that triggers a BR that updates A again. ServiceNow notices the loop and quits there, which is nice, but it still has one update too many.

This could easily be avoided to compare the old and new values and if they are the same, the update should not happen. But this is not as easy with journal fields... The comments and work notes fields need to be synchronised as well.

I tried comparing current.comments.getJournalEntry(1) with other.comments.getJournalEntry(1), but this is not always the same, as it might take more than a second to process, changing the timestamp. I tried comparing the content of the entry, without the timestamp and user, but that gives a problem when the user types in 2 times the exact same thing in the comments or work notes. So is there another way, to let servicenow know that they can run all other business rules against the update of the second record, but not the same one again?

[peterraeves]

Yeah this^ basically. I still want other BRs to run, but I have gathered much information from all your replies, so I'll have to reflect some more on which is the most suitable for our situation. Thanks to all you guys.

[Brian Dailey1]

Hi Peter,

If you use your BRs to also sync the Updated [sys_updated_on] field manually, then you can use this to compare and not cascade updates in a loop.   You will also need to tell it not to update those fields automatically, but I've set this up in a BR loop between [incident] and [sc_request] and tested successfully.

Ex.   BR on your Back Office table, run After updates

function onAfter(current, previous) {

//This function will be automatically called when this rule is processed.

var inc = new GlideRecord('incident');

inc.addQuery(whatever your relationship is);

inc.query();

if(inc.next()){

if(inc.sys_updated_on == current.sys_updated_on){

return;     //This is where you abort any potential loops, because your BRs will be pushing the value

}

inc.autoSysFields(false);

inc.sys_updated_on = current.sys_updated_on;

inc.sys_updated_by = current.sys_updated_by;

inc.sys_mod_count ++;

inc.short_description = current.short_description;

//... all your other fields being copied

inc.update();

}

}

Of course, create an identical/reciprocal BR on your Incident table.   But that should take care of updating without the loops.

Give it a try and see.

-Brian

Edit:   Sorry, I had my tables flipped around in my description (script was fine). One of the dangers of posting while parenting... the post above is now corrected.

[Goran WitchDoc]

I would really think this through. Why do we need to have the same data in two records? Copying data back and forth seems not the correct way.

Second question would be: perhaps the solution isn't to fix it in ServiceNow, perhaps this is perhaps something that can be solved outside of ServiceNow?

//Göran

[peterraeves]

You might be right. I think I'll indeed contact both Service owners and ask them again how they want to exchange data.

[prasanna11]

you can also check in BR condition,

(if updated by   != "system administrator") so that any updates initiated by BR for synchronizing will not initiate a loop.

PS: Assuming the updates to be sync'd are made only by users and not the system.