KM: Article Approved/Rejected trigger condidions

JoeyP
Tera Contributor

Hello everyone, I'm continuing my work on the knowledge management setup and am reaching one of my milestones but I'm having some issues with the approval emails.

I am trying to get the instance to send an email to the author of an article, based on the OotB email notifications:

  • KM: Article approved for publish
  • KM: Article rejected for publish

Both of these listen on table kb_knowledge for the events, knowledge.approval.approved and knowledge.approval.rejected respectively.

I've added a trigger in my approval workflow to trigger these events:

find_real_file.png

find_real_file.png

find_real_file.png

 

I'll include the event registry for these two, 

find_real_file.png

find_real_file.png

When the workflow runs, it does trigger the event but on the wrong table, it's triggering it in the knowledge templates table instead of the kb_knowledge table, as seen below:

find_real_file.png

What is the best way to fix this, I could create 2 records per knowledge template but that's gonna be a PitA for scalability so I was hoping I was just missing something.

If I change the table the notifications are setup to watch for to match the table I can see it triggering on, it DOES send the email.

find_real_file.png

I have also tried using the gs.eventqueue method of triggering the event, which behaves the same way.
What's odd to me is that the Event Registry for both events lists kb_knowledge as table, and the approval workflow runs on the kb_knowledge table too, yet it runs the event on the u_kb_template_servicenow_how_to table.

Any help would be appreciated.

 
1 ACCEPTED SOLUTION

-O-
Kilo Patron
Kilo Patron

As discussed on Slack the reason was that u_kb_template_servicenow_how_to extends kb_knowledge and the approved record is one in the former table and the solution was to replace the Create Event activities with Run Script activities where the event is raised with the u_kb_template_servicenow_how_to record reopened as a kb_knowledge record using script.

View solution in original post

2 REPLIES 2

-O-
Kilo Patron
Kilo Patron

As discussed on Slack the reason was that u_kb_template_servicenow_how_to extends kb_knowledge and the approved record is one in the former table and the solution was to replace the Create Event activities with Run Script activities where the event is raised with the u_kb_template_servicenow_how_to record reopened as a kb_knowledge record using script.

JoeyP
Tera Contributor

To add to that, this is the code I ended up using as per the conversation in slack:

(function runScript () {
    var kb_knowledge = new GlideRecord('kb_knowledge');
    if (kb_knowledge.get(current.getUniqueValue())) {
        gs.eventQueue('knowledge.approval.approved', kb_knowledge, '' + current.author, '');
    }
})();