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

[Kenneth Zabrisk]

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 · Accepted solution]

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!

[Kenneth Zabrisk]

Thanks, that is helpful.

I've discovered one other issue. Now that I'm running it as a before BR it is bypassed (or doesn't update) the Project Tasks created by the UI Action Project task creator.    I've changed the Order of the BR rule to be both lower and higher than the order of the UI Action, but still no update for the created Project Tasks.  Only when I create the Project Task "manually" am I seeing the BR rule execute.

[Allen Andreas]

Hi,

I'm not sure the full context of what is being updated, since your included script was about the current record (which appeared to be a child record of a parent) and taking a related parent value and setting it as it's own.

For your UI Action, there is either a current.update() type method being used to run an update on the current record and then create the task. The "create the task" step being done after the update to the current record has already happened.

Whatever you'd need to update in the project tasks you'd either need to address in that UI Action or in it's own business rule on "insert" and use the conditions properly to have it validate if it should run or not.

Please mark reply as Helpful, if applicable. Thanks!

[Kenneth Zabrisk]

The UI Action I referenced is OOB and creates a user selected number of project tasks all linked to the same parent project.

I had thought the before Business Rule would "intercept and update" each of those project tasks before insertion, but does a before Business Rule only run when a form is submitted? 

A business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried.

Use business rules to accomplish tasks like automatically changing values in form fields when certain conditions are met, or to create events for email notifications and script actions.

Perhaps I have mistakenly focused only on the first part of the definition above.

So in my scenario, whenever (and however) a new Project Task is created, if it has a parent it should inherit two field values from it's parent.   I had thought a before BR would accomplish that as a universal actor, but the behavior indicates otherwise.

Flows seem to have a universal trigger (when record created), is there any other way to write a universal update like I need?