E-mail Inboxes

An email inbox in ActiveManage is a configured mailbox that the platform polls (or that pushes via webhook) to receive inbound messages. Inboxes power features like inbound support tickets, “reply by email”, and bounce processing — anywhere the system needs to read mail rather than send it.

Supported Connection Types

• IMAP: Standard mailbox protocol. Works with any provider that exposes IMAP — Gmail, Fastmail, hosted Exchange, Zoho, IceWarp.
• Microsoft Graph: Modern OAuth-based connection for Microsoft 365 mailboxes. Required if Basic Auth has been disabled by your tenant administrator.
• Gmail API: Google's OAuth API for Workspace and personal Gmail. Higher quotas and faster than IMAP polling.
• POP3 (legacy): Single-client protocol that downloads and deletes. Use only if your provider doesn't offer anything else.

Step-by-Step Setup

1. Navigate to Architect Panel → Email Inboxes and click Add Inbox.
2. Enter a friendly display name (e.g. “Support inbox”). This is what staff see in dropdowns.
3. Choose the protocol. For Graph/Gmail you'll be redirected to consent — for IMAP, fill in hostname, port and credentials.
4. Pick the folder to poll (typically INBOX). You can also tick subfolders if your routing rules drop mail elsewhere.
5. Choose a polling interval — typically 1 minute for high-traffic support inboxes, 15 minutes for low-volume operational ones.
6. Click Test Connection. The platform fetches the most recent five messages without ingesting them.
7. Save and enable.

Example Inbox Configurations

• support@yourcompany.com — IMAP, 60-second polling, all incoming becomes a support ticket.
• bounces@yourcompany.com — IMAP, 5-minute polling, parsed by the bounce handler to flag bad recipients.
• noreply@yourcompany.com — Graph, 24-hour polling, used purely to receive and discard delivery receipts.

Warning: Never reuse a personal mailbox for inbox automation. The platform processes and may delete messages according to your rules. Always use a dedicated address.

Inbox processing rules determine what happens to each message after it's fetched: whether to create a record, file the message, run an action, or simply discard it. Rules run in order and the first match wins (unless you mark a rule as “continue on match”).

Match Criteria

• From address: Match a specific sender or domain (e.g. @stripe.com).
• Subject regex: Match a pattern (e.g. ^Ticket #(\d+):).
• Body contains: Plain-text or HTML body contains a keyword.
• Has attachments / specific MIME type: Match messages with PDFs, images etc.
• Header values: Match arbitrary headers (e.g. List-Id, Auto-Submitted, In-Reply-To).

Action Types

• Create record: Spawn a new row in a chosen datastore, mapping email fields to columns.
• Append to existing record: Find a record by reference number in the subject or by In-Reply-To header, then add the message as a related note.
• Run task: Trigger a configured task (which can in turn run any custom code).
• Forward: Hand off to another address.
• Discard: Mark processed and drop.

Worked Examples

• Support ticket creation: Match anything to support@; create a ticket; auto-reply with the new ticket number.
• Ticket reply matching: Match subject ^Re: Ticket #(\d+); find ticket by ID; append the body as a customer reply.
• Bounce handling: Match from mailer-daemon; parse the bounced recipient address; mark the user's email as invalid.
• Auto-responders: Match Auto-Submitted header; discard silently so vacation replies don't loop.

Tip: Always end your rule list with a catch-all “unmatched” rule that creates a row in a triage inbox. That way nothing ever vanishes and you can refine rules over time as patterns emerge.

Triggers are the custom-code hooks that run when an inbox processes a message. Whereas rules handle the common cases declaratively, triggers let you implement business logic that goes beyond filing the message.

What a Trigger Receives

Every trigger is invoked with structured access to the message:

• $message->from, $message->to, $message->subject, $message->date
• $message->bodyText, $message->bodyHtml — body in both forms
• $message->attachments — array of file blobs with name, MIME type and size
• $message->headers — full header dictionary
• $matchedRule — the rule that fired the trigger (null if “unmatched” trigger)

Trigger Return Value

The trigger should return one of:

• true — processing succeeded, mark message as handled.
• false — let the next rule continue processing.
• ['error' => 'reason'] — mark as failed; the message stays in the inbox for retry.

Example Triggers

• Expense receipt extraction: When a PDF arrives on receipts@, run an OCR step and create a draft expense entry with the parsed amount.
• Sender reputation: Check incoming sender domain against a deny-list; bounce or quarantine flagged senders.
• Out-of-office detection: If the body matches typical OOO patterns, mark the sender as “unavailable until X” on their user record.
• Forward to teams: If subject contains a project code, look up the project owner and forward the message to their address.

Note: Triggers run synchronously during inbox polling. Keep them quick — anything over a few seconds should queue a background task rather than blocking the next message.