setWorkflow and subsequent actions

[dmartinc]

Hello all,

I have a question about GlideRecord's .setWorkflow() method.
In its wiki page ( http://wiki.service-now.com/index.php?title=GlideRecord#setWorkflow ) it is written:

[quote]
Enables or disables the running of business rules that might normally be triggered by subsequent actions. (emphasis mine)
[/quote]

In other words, it says that calling .setWorkflow(false) will affect all the following .update() calls.

However in the example script, the .setWorkflow() method is called just before the .update() call, which is inside two while() loops. So it makes it seem like you have to call .setWorkflow(false) before every .update().


Can someone please confirm which one is correct?

My particular context is that I have an "after insert/update" business rule and I am doing a current.update() preceded by a current.setWorkflow(false). However I want to know if I should do a current.setWorflow(true) afterwards so as not to change the behaviour of similar business rules that may be executed afterwards.

[tony_fugere]

To be safe, I always .setWorkflow(false) PRIOR to the .update() that I want and .setWorkflow(true) after, so I cannot speak to any experiences outside of ensuring it is FALSE only when I want it to be.

Have you tried it in your DEV instance or on SN DEMO to see what happens? 🙂

[dmartinc]

Hello Tony,

Some quick tests with a background script seem to show the following for a GlideRecord object:
* .setWorkflow(false) is remembered between updates to the same record
* .setWorkflow(false) is also remembered between two updates to two different records, when changing from one record to the next via .next() .
So in business rules, I will keep doing as you: call setWorkflow(false) just before the update and setWorkflow(true) just after, just in case.

This also means that the example script at http://wiki.service-now.com/index.php?title=GlideRecord#setWorkflow is misleading, since it could do "ref.setWorkflow(false)" outside of the inner while() loop.

[oneppo]

dmartinc,

I know this post is about the behavior with the 'setWorkflow()' method, but I have to ask why you would need to have to call 'current.update()' in a business rule. Would it be possible to achieve what you are trying to do in a before insert/update business rule so that you would not have to use 'current.update()' and 'setWorkflow(false)'?

To your point about the wiki code being misleading, I think you are correct. There are some methods on GlideRecord that are persistent throughout the query. For example, getRowCount() is unaffected by .next(). setWorkflow() is probably the same.

Thanks,
Peter

[dmartinc]

Hello Peter,

Why I had to use an "after" BR (business rule) instead of a "before" BR: it's a kind of long and unrelated story, which is why I did not include it initially.

As you may know, the incident table has an "after" BR called "incident events", which among other things triggers events than then trigger notifications, for example when there is a new user comment.
The BR I had to develop implied copying the contents of a certain field into the "comments" field when some conditions are met. However, this would make the "incident events" BR to trigger an event ("incident commented"), which we did not want to happen.
To avoid this, I had to somehow modify the comments fields after the "incident events" BR , which forced me to use an "after" BR and therefore to use current.setWorkflow(false) so that my current.update() would not trigger the "incident events" BR again.
I could also have put all the logic into the "incident events" BR; but we did not want to modify it in this particular case.

I hope this answers your question 🙂
Cheers,
David