Several basic questions on business rule conditions and scripts

[Dave Clemmer]

I'm just starting with ServiceNow, and have some basic, mostly yes/no questions relating to business rules and conditions for starting them.

Do field_name.changes conditions specified in 'When to Run' evaluate to true when doing an insert or delete?

If not, and, for instance, you want to run something unconditionally on insert, or conditionally on update, does that require a scripted condition or multiple instances of the rule?

Saw that 'current' argument can be null.  Is this the case on deletion?

Are there other cases where it is null?

Not a yes/no question, but just occurred to me to wonder what it will be if running on a query?

'previous' argument can definitely be null on async execution.  Also on insert and query?

Any other instances where it can be null?

Can updates on joined tables be done via dot-walking, or does it required separate query with explicit update()?

Thanks all,

Dave

[Allen Andreas]

Hi,

Ideally, we'd love to see your own responses to these questions where you've tried to look them up and see if you can figure it out. You may still be confused, but that's where we can help clear that.

Like your first question is about setting a condition on the business rule. If the "state" changes...does it evaluate to true when doing an insert or delete. It doesn't evaluate to true, it evaluates based off the facts. Meaning, it could be yes or no. When you select update or insert or delete...that's the operation in the system. You are telling the system what operation you want this business rule to run for.

Then, your conditions are saying only if these are true...do what is in the actions tab or advanced tab (for scripting).

Anyways, feel free to perhaps give your thoughts to some of your questions or where you may be confused and we can have more of a dialog than the classic scenario of people posting questions like look like interview questions and then then the community just responding. Not saying that that is happening here, the point is, let's help you learn. Otherwise, I could just say: yes, yes, no, no, no, yes...how does that help you or anyone else?

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Dave Clemmer]

Your first paragraph implies I'm lazy; I tried looking it up and didn't find an answer.

Your second paragraph, I think, significantly misunderstands or misrepresents at least one of the questions I was posing.  If I set a condition of 'current.field_name.changes()' for an update BR, then obviously, that will evaluate to true or false, depending on whether it actually changed.

On an insert or delete, however, you don't have two values to compare, so deciding whether it changed or not is a bit hand-wavy.  You could return false, on the premise that a comparison is impossible, and therefore it can't be considered a change.  Or you could return true because the state of the entire record is changing and therefore the state of any individual field is also changing.  Or you could assume null (or maybe some other value, depending on the field type) for the missing value and compare with that; easy to write that code, but potentially more annoying for anyone using the code.

The reason it matters is not so much for scripted conditions, but for conditions set in 'When to run'.  If current.field_name.changes() always evaluates to true on an insert, then setting conditions that include current.field_name.changes() can be sufficient check for both insert and update.  If it evaluates to false, then you need to put the condition check in the scripted condition, to check current.field_name.changes() or current.operation() == 'insert' (this is simple enough, but clunky as it can easily get difficult to read; think changing ten different fields, for instance).  If it can evaluate to either... then perhaps that works the same as it returning true (though you would possibly need to know what was being compared against.  Is it always against null?  If it's a string, is it compared to an empty string?  If it's a floating point, is it compared against 0.00? etc).

The reason for asking about current and previous potentially being null is that the documentation only says that they can be null, and that you should check against that.  It doesn't give any idea why they might be null (and yes, I did give feedback on that page), so I was trying to poke at some conditions where it would make sense to me for them to be null even without an error.

Does it make sense, now, why I'm asking the questions I am?

Thanks for taking the time,

Dave

[Allen Andreas]

Hi Dave,

We don't know if you've looked things up, unless you tell us. No one is saying you're lazy, I'm saying we want to have a dialog and lets discuss things. Share your thoughts and all that and then we can discuss. Furthermore, you're with a partner firm, correct? You have access to resources there that you can ping and ask and I'm sure they can help provide guidance. Given both of those things, led me to reply with what I did.

I say the same thing day in and day out to everyone else if they throw out a list of questions without much context of the authors own thoughts. You may not even know to do that or just didn't think of it, that's not lazy, you just didn't know. So we don't know what all you've done before hand.

Circling back to the specific question of yours that I mentioned and you reply with, with your own thoughts (thank you).

"changes" always...have a comparison. Changes could be from empty to something, from x to y. So using that specific example. Try creating a business rule on insert with a field (i.e., short description) changes. Then, create a new incident where you change it in one, the other you don't. Do the actions execute?

If the short description changes, meaning from empty to something or from something to something else, it will result in true and execute the action.

Using current.field_name.changes() in condition script and "changes" in the condition builder is the same thing. You determine "when" it looks for those conditions by checking the "insert", "update", "delete", etc.

With the above all said, yes, it can evaluate to true, if the condition is true on an insert (you can try for delete as well...but most likely if you're changing a value, it needs to save first (thus updating the record) before the delete).

So the answer provided below by the other response saying "no" is not correct and it can result in true on an insert, specifically, if the condition results to true. Simple as that.

Best of luck with the platform!

-Allen

[Aman Kumar S · Accepted solution]

Hey,

I have tried to answer your questions to the best of my knowledge, I will try to gain more understanding to be sure, but for these you can also easily test it out and share with us.

Do field_name.changes conditions specified in 'When to Run' evaluate to true when doing an insert or delete?

NO

If not, and, for instance, you want to run something unconditionally on insert, or conditionally on update, does that require a scripted condition or multiple instances of the rule?

You can either write BR separately for Insert and Update

OR

You can use current.operation() =='insert' or 'update' to decide the condition for which your logic gets run

Saw that 'current' argument can be null.  Is this the case on deletion?

Yes

Are there other cases where it is null?

No

Not a yes/no question, but just occurred to me to wonder what it will be if running on a query?

It remains as an object

'previous' argument can definitely be null on async execution.  Also on insert and query?

Any other instances where it can be null?

Can updates on joined tables be done via dot-walking, or does it required separate query with explicit update()?

No, it requires separate query