Running support: tickets, threading & replies

Give a table an email address and it becomes a support queue whose records are tickets — each carrying one ordered conversation of what the customer said, what you said back, and internal notes they never see. Replies are written from inside the record, and the customer's answer threads onto the same ticket instead of opening a second one. Where the conversation lives Open a record and the Conversation panel sits below its fields. It appears only on tables that can actually receive one — an email-in address, an open chat, or a record that already has messages — so an ordinary table of products never grows a support interface it has no use for. That last clause earns its keep: a mailbox can be deleted or a widget switched off, and the record of what was said to a customer must not vanish from the page along with it. The header shows the ticket's reference when the table has an Auto number field — Ticket 1042, built from the field's own name and the record's number — and a count of messages, with internal notes counted separately. Reply to the customer The composer has two tabs. On Reply to customer, To is prefilled with the address the mailbox filed their message into, or failing that the first Email field on the record that holds a value. Type and press Send. The message goes out in your account's branding with your organisation's name as the sender, and it is written into the thread whether or not delivery succeeded. A send that failed is badged Not delivered with the reason — a failed reply that left no trace would tell the next person the customer was never answered, and they would answer twice. Internal notes The Internal note tab writes into the same thread and is never emailed to anybody. The To row disappears, and the note is badged Internal note · not sent so that nobody skim-reading a long ticket mistakes an internal remark for something the customer was told. A note is unsendable by construction rather than by convention: nothing in RowFold mails one, so don't send this is a property of the message rather than a rule every future feature has to remember. How a reply finds its way home Every message RowFold sends sets its reply address to t-{mailboxToken}+{recordId}@… — the table's own inbound address with the ticket's id sub-addressed onto it. That is the primary mechanism because it survives mail clients that strip threading headers, and plenty of them do. When it is missing, RowFold falls back to the headers: In-Reply-To first, then the References chain read from the nearest ancestor outwards, matched against messages it has actually seen. Matching on the subject line is deliberately not implemented. Re: Invoice from two different customers is the classic way support systems cross-contaminate threads, and a wrongly merged ticket shows one customer another's conversation. New ticket, or a reply to an old one? A reply address naming a record in that mailbox's own table appends to it. One naming a record somewhere else is treated as unthreaded and starts a fresh ticket instead — a wrong thread is worse than a new one. Mail matching nothing at all becomes a new record exactly as it always did. Either way the body is cleaned first: quoted chains, On … wrote: trails and signature blocks are stripped, so the thread holds what somebody actually said rather than the archaeology underneath it. Attachments arrive as real files on the message, stored exactly like an upload. It updates while you read it A reply arriving lands in an open thread without a refresh. First paint, your own send and a live arrival all go through one rendering path on purpose — a second path would be a second set of bugs, and the place they would show up is the place that matters most: an agent believing they replied when they hadn't. People watching the record hear about replies too, which is why the form and widget settings offer to put the queue's owners on the watch list automatically. Chat and email in one thread Where a reply goes is decided per ticket, not per channel. A ticket opened in chat is answered in chat; one opened by email is answered by email; one that started in chat and left an address gets both, so an agent types once and reaches the person wherever they actually are. The thread labels every message by how it travelled — Sent to customer for mail, a chat badge for a widget reply — because telling an agent their chat message went out as an email is the sort of small lie that costs trust. Tips • Give the queue's table an Auto number field and every ticket gains a reference a customer can quote back at you. • Forward your real support@ address at the table's RowFold address and the whole queue lands in a table — numbered, filterable, automated, with AI triage one question away. • Use a note to hand a ticket over: it sits on the record, in order, exactly where the next person will read it. • The To box is editable — reply to a colleague on the thread and the exchange still lives on the ticket. Good to know • Emailing a reply needs both an email-in mailbox on the table and a recipient address — without either the composer says so rather than pretending to send. • A message that failed to send stays in the thread marked Not delivered; fix the address and send again rather than assuming it went. • A mail client that strips both the reply address and the threading headers starts a new ticket — there is no subject-line fallback, and that is a decision rather than a gap. • The Conversation panel is hidden on tables that can't receive one, so a table with no mailbox, no chat and no history shows nothing at all. • If the server's ticket sender is still a no-reply address, a customer who answers the From header instead of the reply address reaches nobody — an operator sets a replyable address on the inbound domain. Who can do what • If you can open the record you can read its whole thread, internal notes included. • Replying takes the same permission as editing the record — a read-only viewer sees the conversation and gets no composer. • Internal notes never leave the workspace: they are not emailed and never appear on any anonymous surface. • The secret in a reply address is the mailbox token; the record id in it is routing only, and mail naming a record outside that mailbox's table is never threaded onto it.