Reading the E-mail Log

The log records every message the platform sent, what it contained and what happened.

Where to find it

Architect Panel → Activity:

• E-mail Log — every message sent, with its result

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Security:

• Permissions — who can read the log

What an entry holds

• When it was sent, and through which account.
• Recipients, subject, body and attachments.
• The result, and the detail behind it.
• The source — what caused it.
• A tracking code.

The questions it answers

• "Did you send it?" — yes, at this time, to this address.
• "What did it say?" — the body as sent, not what the template would produce today.
• "Why did they get this?" — the source field.
• "Why four times?" — four entries, and the source tells you which process.

The source field is underused

It records what caused the message — which journey, task or action. When somebody receives something unexpected, or the same thing repeatedly, this is what identifies the mechanism.

Without it you are guessing between several processes that send similar messages.

Check the address before anything else

The commonest cause of a missing e-mail is a wrong address sent to perfectly successfully. Read the recipient carefully — transposed characters in a domain are easy to skim past — and if it is wrong, the activity log will say when and by whom it was entered.

Why the body is kept

Because "we sent you an e-mail about this" is rarely the end of the conversation. Keeping the body means you can see what customers actually received last month, not what the current template would produce — which matters after a template change.

The log is correspondence

Subjects, bodies and attachments are the content of your communications with people, which makes this one of the more sensitive stores in the platform.

Restrict access accordingly, and give it a retention period. A log kept indefinitely is an indefinite archive of everything you have ever said to anybody — and it is easy to overlook when listing what personal data you hold.

Watch the failures, not just the total

Reviewing failed sends periodically catches a decaying address list, an expiring credential and a recipient domain that has started rejecting you — all of which are cheaper to fix early.

Worked example

A customer complains of receiving the same reminder five times. The log shows five entries with the same source: a journey whose condition was re-evaluating each night. The fix is in the journey, and the log identified it in under a minute.

Recommendations

• Use the source field to identify what sent something.
• Read the recipient address carefully before investigating further.
• Set retention — this is correspondence, not metadata.
• Review failures as a routine, not after a complaint.