How to check which field changed in an async update BR?

Smith Johnson
Tera Guru

Hello community,

I have an ASYNC update business rule running on the incident table when one of the following conditions is satisfied:
short description changes OR description changes OR assignment group changes OR assigned to changes OR category changes OR subcategory changes

I would like in this BR to understand which field(s) changed. 

The previous object is not available so I can not compare it with the current object.

In addition, the GlideScriptRecordUtil that I have seen in other posts works only in before and update BRs.
However, my BR needs to be ASYNC.

Any ideas how to observe the changed fields in an ASYNC update BR?

Thank you,
Smith.

1 ACCEPTED SOLUTION

Hi @Smith Johnson,

 

Generating an event makes it async. The events are processed completely async.

 

Quick guide (all naming is of course for demo purposes only):

  1. Create an event [System Policy --> Events --> Registry] : start_the_integration_with_xyz
  2. In the business rule you build up the information you need as a JSON
    1. If you just need the information that the fields have been changed, you can use (this comes from a before BR, prio 1001): 
      var changedFields = { "comments" : current.comments.changes(), "work_notes" : current.work_notes.changes()};
    2. gs.eventQueue("start_the_integration_with_xyz", current, JSON.stringify(changedFields));
  3. Create a script action that triggers on the start_the_integration_with_xyz event
    • Get your information
      • var incidentInformation = JSON.parse(event.parm1);
    • Start the integration based on the current record (your incident) and the information provided in the event parameter

 

 

View solution in original post

4 REPLIES 4

Hayo Lubbers
Kilo Sage

Hi @Smith Johnson,

 

You can't in the async business rule itself since the previous object is not there, as you already mentioned.

You could create an after business rule that checks the changes and fires an event to process your logic.

You can sent event parameters to the event, e.g. a JSON with the fields you need, like:

{
	"short_description_current" : "This is a test",
	"short_description_previous" : "This is a test with a changed short descrption",
	"description_current" : "Lorem ipsum",
	"description_previous" : "Lorem ipsum"
}

 

Since it is coming in as text, you only need to parse it in your script action and you can do your logic from there.

 

Hi Hayo,

I appreciate your time to answer my question.

However, we need this BR to be ASYNC because there is an integration that takes part and we want to make this asynchronously.

Hi @Smith Johnson,

 

Generating an event makes it async. The events are processed completely async.

 

Quick guide (all naming is of course for demo purposes only):

  1. Create an event [System Policy --> Events --> Registry] : start_the_integration_with_xyz
  2. In the business rule you build up the information you need as a JSON
    1. If you just need the information that the fields have been changed, you can use (this comes from a before BR, prio 1001): 
      var changedFields = { "comments" : current.comments.changes(), "work_notes" : current.work_notes.changes()};
    2. gs.eventQueue("start_the_integration_with_xyz", current, JSON.stringify(changedFields));
  3. Create a script action that triggers on the start_the_integration_with_xyz event
    • Get your information
      • var incidentInformation = JSON.parse(event.parm1);
    • Start the integration based on the current record (your incident) and the information provided in the event parameter

 

 

Kailash Bhange
Kilo Sage
Kilo Sage

Hello @Smith Johnson 

Hope you are doing Good!

 

When Async BR's are triggered, system creates a record in table 'sys_trigger' wit reference to your current record.

As soon as the job is executed by system the record will be deleted from same table. So it is mostly impossible/hardest to track these triggers with the current records with Async rules. That's why it is suggested to use After BR's.

 

But to trick your requirement, you can try below approach if it makes sense to you.

Key points: - 

1. When a record is updated, it holds the audit history on 'sys_history_set' and 'sys_history_line' tables with the field names which have been updated (old value, new value).

2. Maybe you can make use of these table if you want to track the changes related to 1-5 fields not more than that.

 

e.g. Modify your BR to first check the 'sys_history_line' table record with the qualifying conditions such as respective incident, field and pick the values you need to process ahead then trigger your exact code for the integration.

 

Hope, I have not confused you, if you need more details please get in touch with me.

 

Hope this helps.
If my answer resolves your issue, please mark my answer as ✅ Correct & Helpful based on the validations.

Thank You!
Regards,
Kailash
LinkedIn