E-mail

ActiveManage has a comprehensive email subsystem covering both outbound and inbound messages. It handles transactional emails (confirmations, password resets, workflow notifications), marketing-style bulk emails, inbox processing of incoming messages, and full retention logging of everything sent and received.

The main pieces

Several related features work together:

• E-mail Accounts — credentials and server settings for sending and receiving. Every email account has SMTP/IMAP/Graph configuration depending on its role.
• E-mail Inboxes — incoming mailboxes the platform polls for new messages, with processing rules.
• E-mail Relay Clients — for relaying outbound mail through external services (rather than direct SMTP).
• E-mail Templates — reusable message bodies with merge tokens.
• E-mail Designs — visual wrappers (headers, footers, brand) around templates.
• E-mail Log — record of every message sent (or attempted).

How outbound email flows

The path from "something happened" to "email arrives in inbox":

1. A trigger fires (a workflow step, a user action, a scheduled task, an admin clicking Send).
2. The platform picks the relevant E-mail Template and E-mail Account.
3. Merge tokens in the template are substituted with values from the relevant row.
4. The E-mail Design wraps the template body if one is configured.
5. The message is sent via SMTP (direct) or through a Relay Client (relayed).
6. The send is logged in the E-mail Log with status, recipient, and timestamp.

How inbound email flows

The path from "email arrives" to "action taken":

1. The platform polls configured E-mail Inboxes on a schedule (typical: every few minutes).
2. New messages are detected.
3. For each message, processing rules attempt to match — by from address, subject pattern, body content, attachment type.
4. The first matching rule's action fires — typically inserting the message into a datastore or appending to an existing record.
5. The processed message is flagged or moved so it isn't processed again.

Three real-world email setups

Example 1: Transactional only

One E-mail Account configured for outbound SMTP via SendGrid. Templates for password reset, welcome, notification. No inbound processing. Suitable for most consumer apps.

Example 2: Full support workflow

Outbound account for confirmations and notifications. Inbound account at support@ that auto-creates support tickets from incoming emails. Replies threaded by reference number in subject. Branded email designs match the website.

Example 3: Marketing-heavy SaaS

Transactional account via SendGrid for system emails. Separate marketing account via Mailgun for promotional emails (to avoid contaminating transactional deliverability with marketing complaints). Inbound at hello@ for general queries.

The platform's email subsystem is bidirectional — it sends emails out (to users, customers, partners) and receives them in (to be processed automatically). The two directions are configured separately and have distinctly different uses.

Outgoing flow

Most email traffic from an ActiveManage install is outbound — the platform telling someone something. Common categories:

Transactional

Triggered by user actions or system events. Confirmation emails after a form submission, password reset links, account verification emails, order confirmations, shipping notifications. Should always be sent (the user is expecting them).

Notification

Triggered by workflow state changes. "Your request was approved", "A new message is waiting for you", "The deadline is tomorrow". Sent to relevant parties when the platform's logic decides they need to know about something.

Periodic

Scheduled. Weekly digest emails, monthly reports, end-of-month invoices. Driven by Tasks rather than user actions.

Marketing-style

Bulk emails to opted-in audiences. Promotional offers, product updates, newsletters. Subject to anti-spam regulations (CAN-SPAM, GDPR).

Incoming flow

Inbound emails can trigger workflows in the platform. Common use cases:

Auto-creating tickets from a support email address

Customer emails support@; the platform creates a new support ticket with the email's subject, body, and attachments. The reference number is included in the auto-reply so further emails can be threaded.

Threading replies into existing records

Customer replies to a notification email; the platform extracts the reference number from the subject and appends the reply to the original ticket/order/case.

Processing structured emails from automated senders

An external system sends emails with specific subjects and structured bodies; the platform parses them and creates corresponding rows.

Triggering tasks from email commands

Authorised senders email admin@ with commands like "close ticket 1234"; the platform parses and acts.

Configuration differences

Outbound

Requires:

• SMTP credentials (or Microsoft Graph credentials, or a Relay Client).
• From-address configured with SPF/DKIM/DMARC for the domain.
• Templates for each type of message.
• Optional: E-mail Designs for branded wrappers.

Inbound

Requires:

• IMAP credentials (or POP3, or Microsoft Graph).
• An E-mail Inbox configuration with polling schedule.
• Processing rules that match patterns and define actions.
• Optional: a Task to handle complex post-processing.

Three real-world bidirectional setups

Example 1: Customer support flow

Outbound: confirmation, status update, resolution emails from noreply@. Inbound: support@ creates tickets; replies thread by reference number.

Example 2: Order management

Outbound: order confirmation, shipping notification, delivery confirmation, review request. Inbound: orders@ from suppliers acknowledging dispatch — auto-updates internal order status.

Example 3: Lead capture

Outbound: welcome emails, lead nurturing sequence. Inbound: hello@ creates lead records and forwards to the sales team.

Every message the platform sends (or attempts to send) is recorded in the E-mail Log. Use it to verify delivery, debug bounces, audit communication, and answer the inevitable "did you send the email?" question.

What's recorded

Per log entry:

• Recipient address.
• Sender (which E-mail Account was used).
• Subject.
• Body (the full HTML and plain-text versions).
• Template that produced the message.
• Send timestamp.
• Success / failure status.
• Error message if the send failed (e.g. SMTP rejection reason).
• Bounce status if the recipient's server reported a bounce.
• Open and click tracking (if you've enabled it via tracking-pixel injection).

Where to find it

Architect Panel → E-mail Log. The list page is filterable by recipient, subject, status, date range, template used, and sending account. Each entry can be clicked into for the full body view.

What you can do with the log

1. Verify delivery

"Did the customer actually receive the password reset?" Check the log; if status is Sent and there's no subsequent bounce, the email was delivered to their mail provider. (Whether it ended up in inbox or spam is a separate question — see deliverability monitoring.)

2. Debug bounces

Filter to Failed status. Common bounce reasons:

• User unknown — recipient address doesn't exist on their mail provider.
• Mailbox full — recipient's storage is full.
• Spam rejection — recipient's anti-spam filter rejected the message.
• Rate limit — your SMTP provider throttled your account.

Each has a different remediation: "user unknown" means clean up your contact list; "spam rejection" means investigate your SPF/DKIM/sender reputation.

3. Audit communication

"What emails have we sent to this customer in the last 6 months?" Filter the log by recipient. Useful for support tickets, compliance reviews, customer complaints.

4. Retry failed sends

Failed entries typically have a Retry action. Useful when a failure was transient (SMTP timeout, temporary provider outage). For permanent failures (invalid address), don't retry — fix the underlying problem.

Retention

By default, log entries are kept indefinitely. For high-volume installs (thousands of emails per day), this grows the database significantly over time. Set up a Task to purge entries older than your retention policy — typically 90 days for transactional, 1+ years for marketing.

Three real-world log uses

Example 1: Bounce investigation

Daily scheduled Task scans for new Failed entries with "user unknown" reason, removes the affected email from active marketing lists, alerts the data team to investigate the source.

Example 2: Customer support timeline

Support agent investigating a customer complaint pulls the customer's email log filtered to their address. Provides a clear timeline of what the platform sent to them and when, helping debunk "I never got the email" claims.

Example 3: Deliverability monitoring

Weekly Task aggregates the log and reports overall delivery success rate. A drop in success rate triggers an alert to investigate before the problem affects more users.