before vs after business rule - why does same update script run differently?

Kenneth Zabrisk · ‎03-08-2022

simple business rule script to allow a new child project task to inherit fields from it parent:

current.u_customer_parent_account = current.parent.u_customer_parent_account;
current.u_customer_account = current.parent.u_customer_account;

I've confirmed that whether it's run as a before or after business rule, current.parent.u_customer_parent_account and current.parent.u_customer_account have values, but only as a before business rule are the corresponding fields on the child updated.

WHY?

Thanks in advance.

Allen Andreas · ‎03-08-2022

Hi,

The before business rule is pushing the update to the server/database. So you're basically intercepting the form, changing the values, and then telling the database this is what was submitted.

When you're doing it in an after business rule, the record has already been saved to the database. This is where you'd have to use GlideRecord, for example, query the database, get the related record, and update it. In an after business rule, the current record isn't updated, as it's recommended to do current record changes in a before business rule, not after. After is for other records that may need to be updated based on the current record and the scenario.

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

Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

View solution in original post

Allen Andreas · ‎03-09-2022

Hi,

A before business rule doesn't run only when a form is submitted.

You'd need to figure out "when" those project tasks are being created. Are they being created before the..."before" business rule runs that gets those fields updated. You can look at the created date/time for those project tasks and then the updated date/time for the current record and see the timestamps. That will help you understand things a bit.

From there, you can look at the UI Action code and see if those project tasks are being created from the UI Action (most likely in sort of script include).

I think you're looking at this in a linear way and instead should approach this understanding the pieces of the puzzle. The UI Action is doing something, what is it doing? Is it calling an asynchronous process? Is the current record from which the UI Action was clicked...is that counted as a current update (UI Actions can just executed script without even touching the current record).

Please mark reply as Helpful, if applicable. Thanks!

Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Kenneth Zabrisk · ‎03-09-2022

Allen, thanks for your persistence on this. I know I don't understand the depth of your question.

The BR is defined to run before a new task is inserted AND the Parent is not empty.

The script include that creates the records (PlannedTask) includes the following:
var newTask = new GlideRecord(projectTaskTable);

.

newTask.parent = parentTask.sys_id;

.

tasks[i] = newTask.insert();

So, I know when the newTask.insert() executes it has a Parent (and I know that Parent has the field of interest populated), but the BR is not acting to update those fields on the newly created record.

What timing would prevent that from happening?

Kenneth Zabrisk · ‎03-09-2022

And now we have it:
newTask.setWorkflow(false);

"Using a .setWorkflow(false) to prevent business rules from executing is rarely used because in most cases you want these to execute. For that reason, you have to use it with caution (specially if it doesn't execute query business rules , which also work like acls to restrict what data is retrieved during a query of a table)"

Very much appreciate your help.