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.