E-mail Inboxes

Configuring an Inbox

An inbox is a mailbox the platform collects from, so incoming mail becomes records rather than sitting where only one person can see it.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through
• E-mail Inboxes — monitored mailboxes and their rules

Architect Panel → Automation:

• Tasks — E-mail Inbox Processing, which does the collecting

Architect Panel → Activity:

• E-mail Log — what has been sent
• Error Log — collection failures

What an inbox holds

• The account it collects from.
• A polling time — how often to check.
• An action — what to do with a message.
• An attachment mode.
• A maximum to process in one run.

Use a mailbox nobody works in

The most important setup decision. Point the platform at a mailbox a person also uses and you get a conflict: the platform processes messages and the person moves, reads and deletes them, and neither behaves predictably.

Give it its own address — enquiries, support, referrals — with the credentials belonging to the organisation rather than to somebody's account.

The processing limit is a safety valve

The maximum per run bounds how much a single collection attempts. It matters most on the first run against an existing mailbox holding thousands of messages, and when something has been down and a backlog has built.

Without it, the first run tries to process everything at once. Leave it at a sensible number and let a backlog clear over several runs.

Empty the mailbox first, or expect history

Connecting to a mailbox with two years of mail in it will process two years of mail. Decide deliberately: archive first, or accept the backlog and let the limit meter it in.

Polling frequency

Match it to how quickly somebody needs to see an enquiry. Every few minutes suits a support address; hourly is ample for something routine. Very frequent polling of a quiet mailbox is work for nothing.

Attachments

The attachment mode decides what happens to files arriving with a message. Think about it alongside your upload policy — mail is an uncontrolled route into your system, and attachments arriving this way should get the same scanning and type expectations as anything uploaded through a form.

The collecting task ships enabled

E-mail Inbox Processing is one of the few tasks that ships on, because an inbox that collects nothing is useless. Worth knowing it is already running before you connect a mailbox.

Watch the first day

Check the error log and the resulting records after connecting. Authentication problems, unexpected volume and messages nothing knows what to do with all appear immediately, and are much easier to deal with before a week of mail has accumulated.

Worked example

A support address is given its own mailbox with organisational credentials, archived before connection, polled every five minutes with a limit of fifty per run. The first collection processes fifty, the next fifty, and the small backlog clears within the hour without anything timing out.

Recommendations

• Use a dedicated mailbox nobody works in.
• Archive before connecting, or expect the history.
• Keep the per-run limit — it is what makes a backlog survivable.
• Check the error log on the first day.

Inbox Rules

Rules decide what happens to an incoming message, by matching on part of it.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through
• E-mail Inboxes — monitored mailboxes and their rules

Architect Panel → Data:

• Data Extraction — a common action for structured mail

How a rule works

Each rule names a component of the message — the sender, the subject, the body — a comparison, and a value to compare against. Where it matches, the rule's action runs.

Match on the most stable thing available

Senders are more durable than subjects. A subject line containing a reference is reliable while the sending system keeps that format and breaks silently when it changes — and it will change without telling you.

Where you can key on the sending address or a stable identifier, do.

Order matters

Specific rules before general ones. A rule catching everything from one domain will swallow the message from that domain that needed different handling, and it will do so silently.

Review the order whenever you add a rule, not only when something goes wrong.

The fallback is the important part

What happens to a message matching nothing is more consequential than any individual rule, because it is where the surprises land — a new sender, a changed format, somebody replying to the wrong address, an out-of-office.

Route unmatched mail somewhere a person looks. An inbox that silently discards what it does not recognise loses enquiries, and nobody finds out because there is nothing to find.

Watch what falls through

The unmatched pile is your best source of new rules. If the same kind of message arrives repeatedly and matches nothing, that is a rule waiting to be written — and until it is, somebody is handling it by hand.

Automatic replies and loops

Out-of-office replies, delivery failures and automated acknowledgements all arrive in the inbox. If your rules generate a reply, be careful not to reply to a machine that will reply to you — mail loops are easy to create and generate a great deal of traffic before anybody notices.

Exclude automated senders explicitly rather than assuming they will not match.

Test with real messages

Forward genuine examples rather than composing test messages. Real mail carries the formatting, quoting, signatures and encoding that break rules; a clean test message proves very little.

Structured mail suits extraction

Where a sender transmits structured data — a CSV, a form submission, an XML payload — handing the attachment to data extraction is usually better than parsing it in a rule. The mapping lives somewhere visible and every run is logged.

Worked example

A referrals inbox keys on the partner's sending domain rather than the subject line, which had been changing. Unmatched mail routes to a queue a coordinator checks each morning; two recurring patterns found there in the first month became rules three and four.

Recommendations

• Match on the sender where you can.
• Specific rules first, and re-check the order on every addition.
• Route unmatched mail to a person, never to nothing.
• Test with real forwarded messages.

What Happens to a Message

Once a message matches, an action decides what becomes of it.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through
• E-mail Inboxes — monitored mailboxes and their rules

Architect Panel → Data:

• Activity Stream — the record timeline mail is filed to
• Data Extraction — for structured attachments

What actions typically do

• Create a record — an enquiry, a case, a referral.
• File against an existing one, so the message joins that record's timeline.
• Hand the content to extraction, where it is structured.
• Run a custom function for anything else.

Filing against the right record is the hard part

Creating something new is easy. Recognising that a message belongs to an existing case is what makes an inbox genuinely useful, and it is where most of the design effort goes.

The reliable method is a reference in the subject that your own outgoing mail put there — because most replies quote the subject unchanged. Matching on the sender's address alone fails as soon as somebody has two open cases.

Put the reference in outgoing mail

It follows that threading is designed at the point you send, not when you receive. If outbound messages carry the record reference in a recognisable form, replies bring it back and file correctly.

Retrofitting that onto a live mailbox is much harder than doing it from the start.

Attachments belong with the message

Keep them attached to the record rather than discarded. A referral arriving with a supporting document is not much use as text alone, and the attachment is frequently the substance.

Expect replies to closed things

Somebody will reply to a case closed three months ago. Decide what should happen — reopen, create new and link, or file and flag — because the default of filing silently onto a closed record means nobody sees it.

Do not lose the original

Whatever the action produces, keep the message itself against the record. A parsed summary is an interpretation; when somebody disputes what was said, the original is the answer.

Mail is untrusted input

Anybody can send to a monitored address, and a rule that creates records will create them for whoever writes in. That is usually the point — and it means volume is not under your control, and content should not be trusted to be well-formed or well-intentioned.

Tell senders what happened

An automatic acknowledgement with the reference closes the loop and reduces chasing. Keep it brief, and make sure it cannot reply to an automated sender.

Worked example

Outgoing case e-mails carry the reference in the subject. Replies match it and file to the case timeline with attachments intact. Anything unmatched creates a new enquiry rather than being dropped, and an acknowledgement with the reference goes back — which cut "did you get my e-mail" calls noticeably.

Recommendations

• Design threading when you send, not when you receive.
• Keep the original message as well as anything derived.
• Decide what a reply to a closed record does.
• Acknowledge with the reference.