"Enabling Comm Log Entry?" option

Answer

An option named "Comm Log Entry?" is available in the Communication Templates application. By enabling this, an entry will be inserted in the COMMLOG table upon sending an e-mail using a communication template. If the e-mail is sent successfully, the entry will always be inserted in the COMMLOG table as long as the "Comm Log Entry?" checkbox is checked. However, if sending the e-mail fails, the entry will be sometimes inserted in the COMMLOG table but sometimes not. This depends on how it is sent and how it fails.

In case an e-mail sent from an escalation fails with SendFailedException, the corresponding entry will be inserted in the COMMLOG table as long as the "Comm Log Entry?" option is checked.

However, in case an e-mail sent from an escalation fails with a MessagingException, no entry will be inserted in then COMMLOG table even if "Comm Log Entry?" is checked.

MXServer does not throw an Exception when a SendFailedException is thrown by Java Mail. It just logs it and moves on. The Commlog code writes an entry into the table only if there are no exceptions, which is why you see a row when a SendFailedException is thrown by the Java Mail API and not when other MessagingException are thrown by Java Mail.

On the other hand, in case an e-mail is sent from Workflow, an entry will be always inserted in the COMMLOG table regardless of the error type.

In the case of Workflow, if there is an error or exception during the sending of a notification, the Workflow process does not stop. The notification error is logged and the Workflow process moves to the next node. The only time a WorkFlow process stops and rolls back is when the business action (like creating assignments or changing status etc.) fails. If the business action is successful and if there is a notification defined below it which fails, the process moves forward to the next node. When the Workflow process moves forward internally, what happens is the Transaction stack is saved and committed when the process leaves one node and moves to the next. The Transaction stack includes the CommLog object which in turn gets committed to the database as a result of the Transaction Save.

For example, you have a Start and Stop node with an Action line between them. Let's say your action is to 'Change the status to Approved' and also to send a notification after the Status is changed. Even though you killed the Email Server during this test and generated the exception, the Workflow process continued to the next node which is 'Stop' in this example. This is the reason why the corresponding entry will be inserted on COMMLOG table in this case.