Assignment Rules tracking

[Community Alums]

Hello Experts! (@Maik Skoddow @sergiu_panaite @Allen Andreas @Chuck Tomasi @DrewW)

I have a use-case and I might be totally overcomplicating it, so I'm willingly putting myself out there and giving the possibility to look foolish.

The use-case is as follows: Identify the Assignment Rule(sysrule_assignment) which run on a task type record. Then, put a worknote on that incident or wm_task or etc., with the Assignment Rule's (AR for the rest of this post) name or sys_id. I'd like to accomplish this on server-side.

For the above, I'd like to track/intercept/trace/listen the update transaction during which the AR is run and the update happens on the Task type record's Assignment Group field. Otherwise, just "simply" get the sys_id of the AR.

Now, I have tried looking at the Event queue for hints and didn't really find anything. (except maybe the metric_update event is fired at one point after the field update)

Then I looked at the Node Logs and it seemed to me, that I found at least a couple of references to what I'm after, but I might be looking in the wrong places:

2023-09-25 01:19:48 (885) http-33 [AMB] AMBClusterBroadcastExtension channel_id=/meta/subscribe message_id=30 cometd_session_id=307ywtuy24a4hgw15shpfwgsub53 glide_session_id=E192CCFC1BA1F95048B860A7234BCB02 user_id=LLLLL glideSessionMappedToHttpSession: true, canReestablishGlideSession: true, isPublicOrUserSet: true, contextName: send /amb/meta/subscribe /sn/rp/sysrule_assignment/4d0682331b99f910e9cc5208624bcb10

2023-09-25 01:20:11 (567) http-39 New transaction E192CCFC1BA1F95048B860A7234BCB02 #475623 /api/now/v1/batch
2023-09-25 01:20:11 (569) Default-thread-7 SYSTEM txid=904324f01ba5 DEBUG: #475623 [REST API] RESTAPIProcessor : Started initializing REST Request
.......
2023-09-25 01:20:11 (577) Default-thread-7 E192CCFC1BA1F95048B860A7234BCB02 txid=904324f01ba5 DEBUG: #475623 [REST API] RESTAPIProcessor : Request Header: referer:https://AAAAAA.service-now.com/now/nav/ui/classic/params/target/sysrule_assignment.do%3Fsys_id%3D4d0682331b99f910e9cc5208624bcb10%26sysparm_stack%3Dno%26sysparm_domain%3Dglobal%26sysparm_domain_scope%3Drecord

From what I've gathered this processor called RESTAPIProcessor is being called here by ServiceNow and that handles this request, at least, from the transaction.

I also see the AMB here, and not sure whether or not it is possible to subscribe(?) to an event from which I can get the necessary info, from the server-side.

I had also tried to use in a BR and in the AR's Script field the following lines, but it returned the task type record.(e.g. incident; I guess in the chain of requests/events the task record was the new initiator at that point):

GlideTransaction.get().getRequest().getRequestURL()  OR
GlideTransaction.get().getRequest().getHeader("referer")

Other less documented classes might work, but I did not find those.

I could probably store the existing AR sys_ids in a sys_property or some table, then after the update find the sys_id, but that just doesn't feel right and not very elegant either.

So, as I said in the beginning, there might actually be a much easier solution and I overcomplicated it, thus missing the mark.

In case I didn't, then obviously I don't know enough about the inner workings and architecture of ServiceNow (but I'm more than open to learn it), hence why I'm looking for some help, different point of views or approaches to this. 

Thank you for taking the time to read it and looking forward to hearing from you.

Kind regards,

Lori

[Ratnakar7]

Hi @Community Alums ,

Tracking the Assignment Rule (AR) that ran on a task type record in ServiceNow can be a bit complex because Assignment Rules typically run on the client-side, making it challenging to intercept the exact moment when an Assignment Rule is executed. However, you can still achieve this with some workarounds.

Here's a high-level approach to track the Assignment Rule:

1. Custom Script: Create a custom script (Business Rule or Script Include) that runs before or after the Assignment Rule. This script should log information about the Assignment Rule execution.

2. Audit Table: Create a custom table to store Assignment Rule execution logs. This table can include fields such as the Incident (or task) number, Assignment Rule name/sys_id, timestamp, or any other relevant information.

3. Custom Code: In your custom script, log the necessary information about the Assignment Rule execution to the custom audit table.

Here's a simplified example:

// Custom script (Business Rule or Script Include) that runs before/after the Assignment Rule.
(function executeRule(current) {
    // Check if an Assignment Rule was triggered (you may need to customize this logic).
    if (/* Logic to check if Assignment Rule ran */) {
        // Log the Assignment Rule execution in a custom audit table.
        var arLog = new GlideRecord('your_custom_assignment_rule_log_table');
        arLog.initialize();
        arLog.assignment_rule = current.assignment_rule; // Store Assignment Rule sys_id or name.
        arLog.task = current.sys_id; // Store the Incident or task sys_id.
        arLog.timestamp = new GlideDateTime(); // Store the timestamp.
        arLog.insert();
    }
})(current, previous);

This approach allows you to log Assignment Rule executions in a custom table. However, keep in mind that you might need to refine the logic to detect when an Assignment Rule has been executed.

Additionally, please note that this approach doesn't directly integrate with the Event Queue or provide real-time tracking. Instead, it captures Assignment Rule executions when the related record (e.g., Incident) is updated.

Thanks,

Ratnakar

[Community Alums]

Hi Ratnakar,

Thank you for the suggested approach, although I don't think this would work due to several impediments.

The problem is exactly how to log/detect the AR execution, since you don't know which got executed.

Having an after BR on the Incident table won't simply give me any identifier (sys_id or name) of the AR record.

Creating a custom table for this is not an option due to licensing and it would probably grow to a large size for each and every execution.

The Event Queue was just an example that I found(and thought could have relevance, but might not) during my investigation.

Unless I misunderstood your proposed solution, I can't really do much with this unfortunately.

Best to you,

Lori

[Allen Andreas]

Hi @Community Alums 

If you don't mind, can we take a quick step back as to why you need to do this in the first place? Is this because you all have a bunch of assignment rules that could be overlapping and in an effort to sort of clean things up, you're wanting to track which is running?

Outside of that, the assignment rules have access to "current" which would be the record object and that means they run on the server...not client. You could, in theory, add a few variables in the script of the assignment rule with the name of the assignment rule, etc. and then set the work-note as part of your tests to see which one is executing it, etc. Just a thought.

[Community Alums]

Hello Allen,

Thanks for the quick reply.

Unfortunately, you're right on point. One of the reasons on why I'd like to achieve this is due to a bunch of rules that might overlap.

I'm aware of the current object in the Script field of the AR. 

The problem is that current points not to the AR itself, but to the target table record, that one sets up in the Table field. So, current.sys_id will give me the Incident sys_id for example, not the ARs.

I tried to add custom variables, that I'd then read out on the Task type record in a BR, but could not access the sys_id from the AR record itself.

I could possibly batch update all the ARs with a Fix Script and set in the Script field the target record's worknotes (current.work_notes) directly with the name of the AR, if that's what you were actually proposing. 🙂

Thanks,

Lori