How Does One Prevent Duplicate Comments?

[Jamy1]

We have Table Square (SQ) and Table Star (ST). Let's say we have two records SQ0001 and ST0023; they both reference to each other. When a user submits a comment in SQ0001, it should then add that comment to ST0023. A comment that is submitted from ST0023 should also apply to SQ0001.

I've created two Business Rules. One on Table Square and the other on Table Star. 

// Business rule in Table Square
(function executeRule(current, previous /*null when async*/) {
	var gr = new GlideRecord('star');
	gr.addQuery('square', current.sys_id);
	gr.query();
	if (gr.next()) {
		var text = current.comments.getJournalEntry(1).split('comment)'));
		gr.comments = text[1].trim();
		gr.update();
	}
})(current, previous);

// Business rule in Table Star
(function executeRule(current, previous /*null when async*/) {
	var gr = new GlideRecord('square');
	gr.addQuery('star', current.sys_id);
	gr.query();
	if (gr.next()) {
		var text = current.comments.getJournalEntry(1).split('comment)'));
		gr.comments = text[1].trim();
		gr.update();
	}
})(current, previous);

I've been able to get a version similar to this working as a "before" business rule with no duplicated comments. However, my understanding of business rules compels me that an "after" business rule should be used instead. After all, isn't it better practice and performance to update another table's comments using an "after" business rule. Unfortunately doing an "after" business rule creates a duplicate comments and I haven't found the right solution yet.

Is it better to do an "after" business rule and if so, how can it be done in the situation described? I do understand the inherit problem that a comment is coming in both directions and I'm looking for a solution to handle this.

Note that .setworkflow(false) does not resolve the problem.

[Abhijit Das]

This is the correct answer. Works like a charm.

[Jorn van Beek]

is it a hard requirement that comment is mapped to comment?

I had a simular request with work notes. I worked around it by adding an additional journal to the forms. And made the worknotes from table A added to the new journal on table B and vice versa.

Same logic you can do with comments. Just remind to give end users access to the new journal.

Main benefits were:

1. You have a very clear indication that the update came from the other record (can also be a disadvance if you dont want this to show)
2. You will never cross update eachother.