current.update() on "Insert" only Business Rule

[seberly]

I am writing a business rule to inherit a custom field value on change_task from change_request, however when the business rule runs on update, change_task records that are created at the creation of the change_request record by a workflow running on change_request are seen as null by the before business rule.

If the business rule is run after or async, however, the values on the parent change_request record are what they were submitted as (not null).

I know that current.update() in a business rule is a big no-no - I have felt the wrath of the consequences of such a business rule - but what about if a business rule only runs on insert? Then using current.update() shouldn't be an issue, right? This is my only working solution at this point, and it seems like this should be a pretty simple function, but it hasn't proven to be in practice. Any help is appreciated!

I floated the question here, but it didn't seem to get too much traction: https://community.servicenow.com/community?id=community_question&sys_id=e18772fcdb231344a39a0b55ca96...

Thanks!
Scott

[Allen Andreas]

If this is happening AFTER everything else has ran...then there are no other BRs to run? This particular BR is just to copy over a field, that's it, right? So it wouldn't stop the workflow...it just prevents other BRs from running based off you updating this field.

Yea I see you repeatedly saying you're getting positive results...that's great for you. No need to restate it as we're just presenting the other side of the coin. This is also a community forum and not a private message just to you, right? So we can't have this publically facing without stating the other side of things.

So you said: "however when the business rule runs on update, change_task records that are created at the creation of the change_request record by a workflow running on change_request are seen as null by the before business rule."

I'm not really clear on this, because you're saying it's running on update? But then say that the change_task records that are created at the creation of the change_request record by a workflow show values as null? So if the records aren't created and the BR is running before, it will be null because the values haven't been written to the database yet.

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

[seberly]

Doesn't setWorkflow also affect the running WFs as well? Also, doesn't it kill audits?

To recap, the BR is running on change_task insert.

When the BR is configured to run "before":

• current.parent.u_field = NULL
• current.parent.number = NULL
• current.parent.state = NULL
• current.u_field = "a value"
• current.number = "CTASK0000001"

So, how would the change_task field have a value and not any field on its parent? That's where I am stuck. In my experience, on before insert BRs the fields on the table you are trying to insert to have values which is the case here, but it's the parent that is missing values.

Thanks,
Scott

[Allen Andreas]

setWorkflow(Boolean)
Enables or disables the running of business rules that might normally be triggered by subsequent actions. If the e parameter is set to false, an insert/update will not be audited. Auditing only happens when the parameter is set to true for a GlideRecord operation.

It's just for business rules and again, you wouldn't want any others to run due to you doing current.update(); That's where this whole thing is coming from...we're trying to help you still do your current.update(); As far as the auditing, yes, it ignores auditing...but again...you're just copying the field right? So you lose the audit that you copied it...not sure how big of a deal that is...and again....lol...this is to help you use current.update(); So all these by-products are from using current.update(); in a BR (or you can just go without and if it's not a problem, go for it...).

Side note...have you considered setting these in the workflow itself?

I guess I don't understand fully what all is going on other than you trying to set a custom field to the parent record in the task. But the tasks are getting created in workflow? So couldn't you just set that in the workflow task activity advanced script?

Like: task.u_field = current.sys_id;

Something along those lines?

[Ian Mildon]

current.setWorkflow(false);

Use of this in this context is direct from HI. I know this the hard way by having them involved in solving the headache of a couple of "runaway" business rules that caused a chain reaction and major instance slowdowns.

Their advice was to either stop use of current.update(); in business rules or add the setworkflow line to prevent any further recursive behavior

[Ian Mildon]

You can prevent recursive behavior that the current.update() could cause by using it like this:

current.setWorkflow(false);
current.update();

It is still a better solution to not use current.update(), especially in After business rules