Dotwalking in GlideRecord

Mathew Hillyard
Mega Sage

Hi everyone,

I am attempting to create a notification to tell people when their knowledge article is about to expire.

I have registered the event, created the scheduled job and the notification fired by the event. Everything runs as expected, but I am running into problems trying to dotwalk to another table in order to supply the author's manager as parm2 to the event.

My scheduled job looks like this.

gr.author works fine and fires the event, which sends the notification to the kb article' author, but as author is a reference field I cannot work out how to dot walk to obtain the author's manager to insert into parm2 in the gs.eventQueue() function below. gr.author.manager, current.author.manager and any other variation seems to fail.

There are no log messages, parm2 is just empty in the event log.

Any ideas as to the correct syntax?

Here's the script:

function queryExpiringKBArticles() {

  var gr = new GlideRecord('kb_knowledge');

  gr.addEncodedQuery("workflow_state=published^valid_toONYesterday@javascript:gs.daysAgoStart(1)@javascript:gs.daysAgoEnd(-14)"); //this will give you all the articles will expire in 14 days

  gr.query();

  gs.log(gr.getRowCount() + ' rows retrieved');

  while (gr.next()) {

  gs.eventQueue( 'kb.expiring', gr, gr.author, gr.author.manager );

  }

}

Thanks

Mat

1 ACCEPTED SOLUTION

Gurpreet07
Mega Sage

Hi Mathew,



As you are already passing the glideRecord object of the KB record, non need to pass additional parameters. Simply select knowledge as table in email notification and then select the recipients from fields.


find_real_file.png


View solution in original post

11 REPLIES 11

ohhh when i first replied you i faced the same but then i updated manager in one of the user . i thought i should ask you if manager is available in your user forms


Mathew Hillyard
Mega Sage

Long time ago! For anyone checking back the functionality is now OOTB - Notification KM: Article Expiry Warning driven by event kb.article.expiry.warning. This targets the author, KN Owner, KB Managers and the Revised by, but is smarter as it sends a summary, mapped to the relevant users, of expiring articles rather than one notification per article

As Gurpreet says - given the table record is available then it's simple enough to add author.manager via users/groups in fields.