Type and Order of BRs

[Kumar38]

I want to make sure , I'm not missing something that is obvious. I have a scoped app that  has 4 business rules, Script is correct on these. Its only become issue based on type of BRs and I want all of them work in Sync by setting them to correct type.

1.  Before/On Insert, update , Order 100 : A reference fields exists on the same table and I am updating rest of the fields based on data from the reference field [Working fine all the time]

2. Before/On Insert, update , Order 200 : Do some logic that requires to read all values populated from above Script and update a field on the same table

[if I do on before , The 1st time records gets created its doesnt execute till the end as it is not finding the current record from addQuery, variable.xxx, although it prints variable.XX in the log. If I run the Insert test script again the new record has all the calculations required on the new record ,  I switch it to After BR it works, then it is impacting some of the below Script updates]

3. After/On Insert, Update/Order 100 :  When one of the fields populated from Script 2 , propagate that value to  other  tables

[Some inconsistences after switching to After]

4. After/ On update/Order 200 : when one of the field gets updated , copy over the same value to field updated in script 2 on same table

[Some inconsistences after switching to After]

I would like to know if I am doing anything wrong here, the scripts works based on the types , however it keeps impacting scripts 3,4 based on type of script 2. Initially I did before on all 4 scripts and then the above

[vaishali231]

@Kumar38 

You are not doing anything wrong. This is expected behavior.

The main issue is timing.

On Before Insert, the record does not yet exist in the database. So queries like addQuery on the same table will not work, even though current.field values appear in logs.

That is why:

Rule 1 works fine (it only sets values on current).

Rule 2 fails on first insert when it is Before, but works when it is After.

Switching Rule 2 to After affects Rules 3 and 4 because they now depend on update order and may re-trigger each other.

Correct approach:

Use Before rules only to set values on current.

Use After rules for calculations that need the record to exist and for updates to other tables.

Add conditions to Rules 3 and 4 so they run only when the relevant field changes, to avoid recursion and inconsistencies.
*************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.

Regards
Vaishali Singh

[adityahubli]

Hello @Kumar38 ,

You are not missing anything obvious. This behavior is expected and is related to Business Rule execution timing.

The main issue is with Script 2 running as a Before Insert/Update rule. In a Before Business Rule, the record does not yet exist in the database, so any GlideRecord query on the same table will not find the record. That is why it fails on the first insert but works on the second attempt or when changed to an After Business Rule.

Your setup works logically, but:

• Before BRs should only calculate and set values on current

• After BRs should be used for propagation to other tables or DB-dependent logic

• Updating the same record in an After BR can cause inconsistencies and should be avoided

Recommendation:

1)Combine Scripts 1 and 2 into a single Before Insert/Update rule (no table queries)

2)Keep Scripts 3 and 4 as After rules, triggered only when values actually change

This is a timing/transaction issue, not a scripting mistake.

If this helps you then mark it as helpful and accept as solution.

Regards,

Aditya,

Technical Consultant