- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-26-2020 01:17 AM
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:
I'll include the event registry for these two,
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:
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.
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.
Solved! Go to Solution.
- Labels:
-
Knowledge Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-28-2020 12:56 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-28-2020 12:56 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-28-2020 01:35 PM
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, '');
}
})();