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

@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

[AdityaH30338218]

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

[Sarthak Kashyap]

Hi @Kumar38 ,

You’re not doing anything wrong logically. The issue is Business Rule timing. Before Insert runs before the record exists in the database, so queries and addQuery won’t work. Any logic needing DB access must run After Insert/Update. Keep calculations in Before, propagation in After.

Please mark my answer correct and helpful if this works for you

Thanks and Regards,

Sarthak

[DiveshTyagi]

Hi @Kumar38 ,

You’re not missing anything obvious here — what you’re seeing is expected behavior and comes down to Business Rule execution timing/transaction rather than a scripting error.

Why Script 2 behaves differently

• In a Before Business Rule, the record has not yet been committed to the database.
• That means any GlideRecord query on the same table will not return the current record during the first insert.
• This explains why Script 2 fails on the initial insert but works on subsequent attempts, or when you switch it to an After Business Rule.

• Before Business Rules : Best used for calculations and setting values directly on the current object.
• After Business Rules: Best used for propagation to other tables or logic that depends on the record being saved.
• Avoid updating the same record in an After BR: Doing so can introduce recursion or inconsistent results.

Recommended Approach: 

1. Combine Scripts 1 and 2 into a single Before Insert/Update rule. This way, you can calculate and set values on current without querying the table.
2. Keep Scripts 3 and 4 as After rules, but ensure they only trigger when values actually change (using conditions like current.field.changes()).
3. Use order only to sequence logic within the same type (Before or After), not to fix timing issues across types.

--------------------------------------------------------------------------------------------------------------------------------------------

If my response helped, please mark it as the accepted solution so others can benefit as well.

Regards,

Divesh Tyagi