If you have a table, such as incident, that has an activity log showing duplicated sys_journal_field entries, try de-checking the boxes for Run business rules and Refresh history set on the incident table subscribe configuration. Since Refresh history set is already checked on the sys_journal_field table itself, running refresh history set on the incident table will cause it to refresh twice. Due to the way ServiceNow handles timing and refreshing history set, this can cause two entries to occur. As well, running business rules can create duplicate entries, since a business rule may cause the system to believe two different events are occurring. However, turning off Run business rules will disable the table events' business rule (for example the incident events business rule for the incident table) that is run to create events in the event log. If you want these events to occur, you can execute them in the Before subscribe script of the table's subscribe configuration using the ServiceNow function that actually fires the event (gs.eventQueue()) and the gr_before and repl_gr GlideRecord objects available in the Before subscribe script. For example, to cause the incident.assigned.to.group event to be fired when the assignment group is changed, you would add the following to the Before subscribe script: Code Block |
---|
if (gr_before.assignment_group != repl_gr.assignment_group) {
gs.eventQueue("incident.assigned.to.group", current, current.assignment_group, previous.assignment_group.getDisplayValue());
} |
Note that for fields that are not stored in the table itself and are stored in the sys_journal_field table, such as the comments field in the incident table, you would want to have the script in the Before subscribe script of the sys_journal_field configuration as follows: Code Block |
---|
if(repl_gr.element == "comments" ){
var igr = new GlideRecord("incident");
if(igr.get(repl_gr.element_id)){
gs.eventQueue("incident.commented", igr, gs.getUserID(), gs.getUserName());
}
} |
In this case, the incoming sys_journal_field record is checked to verify that it is a comments record and that is for the incident table by checking if the sys_id in the record exists in the incident table. If it does, then the incident.commented event is fired using the incident record itself (igr) to ensure the event is properly created. |