Modify provider notification before sending

[Mike Hashemi]

I have a provider notification ([sys_notification]) that runs against the [live_notification] table and on record change, insert, and when the field name is work_notes or comments (category is 'connect'). When someone sends an @mention, the recipient gets the notification in their "bell". When they click the notification, instead of being taken to the task (I have been testing with [sn_customerservice_case]) from which they were mentioned, the [live_notification] record is loaded.

I noticed that, if I modify the related [ui_notification_inbox] record, changing the target_table from [live_notification] to [sn_customerservice_case], then the notification loads the case. After creating a BR on the [ui_notification_inbox] table (runs before insert, when the trigger is my provider notification), I can see the BR script running, but the target_table is not being updated.

My assumption is that, when the record is inserted, BRs do not run, so I had a look at the existing [live_notification] BRs and found one called "Send Notification", which looks like it must create the [ui_notification_inbox] record, but it uses an API for which I cannot find any documentation. I updated the script, but it did not change how the [ui_notification_inbox] record is created.

Anyone know how to control [ui_notification_inbox] records or how to make the notifications point to my desired record?

Here is the "Send Notification" BR script:

(function executeRule(current, previous /*null when async*/) {

	var profile = current.profile;
	if(!profile) {
 	    profile = new GlideappLiveProfile().getIDFromProfileOrUser(current.user);
	    if (!profile)
            return;
	    current.setValue("profile", profile);
		current.update();
	}
	
	var liveGroupProfileGR = new GlideRecord("live_group_profile");
	liveGroupProfileGR.setWorkflow(false);
	liveGroupProfileGR.addQuery("document", current.document);
	liveGroupProfileGR.addQuery("table", current.table);
	liveGroupProfileGR.addQuery("type", "!=", "support");
	liveGroupProfileGR.query();

	if(liveGroupProfileGR.next()) {
		var liveGroupMemberGR = new GlideRecord("live_group_member");
		liveGroupMemberGR.setWorkflow(false);
		liveGroupMemberGR.addQuery("group", liveGroupProfileGR.getUniqueValue());
		liveGroupMemberGR.addQuery("member", profile);
		liveGroupMemberGR.addQuery("state", "!=", "inactive");
		liveGroupMemberGR.query();

		if(liveGroupMemberGR.next()) {
			return;
		}
	}

	// The following section was added to allow @mention notifications to trigger a notification that points to the task record instead of the live_notification record.
	gs.info('[Notification Update] Running update script in Send Notification BR.');
	var documentGr = current.document.getRefRecord();
	if (documentGr) {
		gs.info('[Notification Update] Found the live_notification\'s document record: ' + documentGr.getUniqueValue());

		var targetTable = documentGr.sys_class_name;

		if (targetTable) {
			gs.info('[Notification Update] Document table: ' + targetTable);

			//current.table = targetTable;
			//current.document = documentGr.getUniqueValue();
		} else {
			gs.info('[Notification Update] No document table returned.');
		}
	}

	new GlideNotificationBroadcaster().broadcast({
		title: current.title,
		message: current.message,
		table: targetTable, //current.table,
		document: documentGr.getUniqueValue() //current.document
	}, profile);

})(current, previous);

I can see it runs by checking the system log and the targetTable/documentGr records are what I expect.

[Sreeram Nair]

I think ui_notification_inbox records cannot be controlled or modified reliably, because they are created and overwritten by the Next Experience Notification Engine, not by your Business Rules. Even though your BR runs and logs correctly, the platform recalculates and inserts the inbox record after your BR finishes, which is why target_table always reverts to live_notification.

The API you found (GlideNotificationBroadcaster) is internal and undocumented, and it ignores any table/document overrides you try to pass—it always creates a UI inbox notification that points back to the live_notification record.

That means you cannot change where @mention notifications navigate using provider notifications, BRs on live_notification, or BRs on ui_notification_inbox. The behavior is not customizable.

If you want the notification to open the case (or any other task) instead of the live_notification record, I think you must create your own custom UI Notification, because it uses the newer notification engine and create ui_notification_inbox entries based on the configuration you provide, not from live_notification.

[lauri457]

Create an insert BR on [live_notification] that fires an event using the record referenced in the document id field.

var gr = new GlideRecord(current.getValue('table'))
if (gr.get(current.getValue('document')))
	gs.eventQueue('mention.event.name', gr);

 Then change your provider notification trigger to the event you created. 

[Mike Hashemi]

I went ahead and created the suggested BR on [live_notification] (before insert) and I verified that I could see the logging messages (before gs.info was commented-out):

Registered the event:

I can see the events:

The [sys_notification] is set to trigger when mention.even.name is fired:

But I am not getting any [ui_notification_inbox] records and thus, no notifications.

[lauri457 · Accepted solution]

Sorry I omitted a few key things needed to make this work. The record instance in the event will not be [live_notification] so you can leave the table field empty in the notification and the event. The table for the record will be whatever record the mention is on e.g incident (second gr parameter on gs.eventQueue()).

Use the event parameters to pass the target user to the notification.

(function executeRule(current, previous /*null when async*/) {
	var mentiodOnGr = new GlideRecord(current.getValue("table"));
	if (mentiodOnGr.get(current.getValue("document"))) {
		gs.eventQueue("mention.task", mentiodOnGr, /*event.parm1 set to mentioned user*/ current.getValue("user"));
	}
})(current, previous);

Recipient in parm1 on the notification:

And then you can transfer the notification condition from the [sys_notification] record to the business rule as you have easy access to both the [live_notification] and the target record.