Turn a shared inbox into a Trello queue

<h2>What a shared inbox is actually doing</h2><p>A support address is a queue that nobody sat down and designed. Mail arrives, somebody answers, and the record of what happened lives in one person's sent folder. It works at ten messages a week. At forty, two people answer the same thread within a minute of each other, and at the end of the month nobody can say how many requests came in.</p><p>Moving to a helpdesk is one answer. Moving the queue onto a board you already use is the cheaper one, and it takes an afternoon. This is the flow we build most often, written out in full.</p><h2>The shape of the flow</h2><p>Four pieces: a trigger with a search, a filter, a card creation step, and a cleanup step that stops the same email being handled twice. The cleanup step is the one people skip, and it is the one that decides whether this survives past week two.</p><h3>The trigger search</h3><p>Syncline uses a Gmail search string, so whatever you already type into the search box will work here. Start with the label your team applies, and exclude a second label that the flow itself will write:</p><pre><code>label:support -label:synced -in:spam newer_than:7d</code></pre><p>The exclusion is doing real work. Once the flow has created a card it applies the synced label, and that message can never match the search again. Without it, any change to the message, any thread reply, and any reprocessing after an outage produces a second card for the same request.</p><p>The seven day bound is a safety rail for the first run. When you enable a flow against a mailbox with four thousand archived messages, an unbounded search will happily create four thousand cards. Widen it once you have watched the first day.</p><h2>Mapping the fields</h2><p>Six fields cover almost every version of this. The interesting decisions are the last two.</p><table><thead><tr><th>Gmail value</th><th>Trello field</th><th>Note</th></tr></thead><tbody><tr><td>Subject</td><td>Card name</td><td>Trim to about eighty characters so the board stays readable</td></tr><tr><td>From address</td><td>Card description</td><td>Put it on the first line, teams scan for it constantly</td></tr><tr><td>Body, plain text</td><td>Card description</td><td>Plain text, since Trello markdown will mangle mail HTML</td></tr><tr><td>Received at</td><td>Due date</td><td>Add your promised response window, commonly 24 or 48 hours</td></tr><tr><td>Thread ID</td><td>Card description</td><td>Hidden at the bottom, this is what makes deduplication possible</td></tr><tr><td>Attachments</td><td>Card attachments</td><td>Large files arrive as a link instead, noted in the run history</td></tr></tbody></table><h3>Why the due date is not optional</h3><p>A card with no due date is a card the board sorts randomly. Mapping received time plus your response promise turns the board into a queue that puts the oldest unanswered request at the top by itself. That single mapping does more for response time than any alerting you add later.</p><h2>The duplicate problem, solved once</h2><p>Threads reply. A customer answers your answer, the message matches the search again, and a naive flow opens a second card while the first is still in progress. The fix is a lookup before the create, keyed on the thread ID you wrote into the description:</p><pre><code>Subject: Re: order 88214 has not arrived Thread ID: 18f3a9c2b7e04d10 Board lookup: search descriptions for 18f3a9c2b7e04d10 Result: matched card 662f, added a comment instead of creating </code></pre><p>Now a reply lands as a comment on the card that already exists, in the list where it already sits. The person handling it sees the new message without the queue growing, and your monthly count stays honest.</p><h2>Turn it on carefully</h2><ol><li>Point the card creation step at a scratch board first and run it against ten labelled messages.</li><li>Open all ten cards and read them. Look for HTML fragments in the description and truncated subjects.</li><li>Move the flow to the real board with the seven day search bound still in place.</li><li>Add the synced label action last, after you are satisfied. Adding it early makes reruns during testing awkward.</li><li>Widen the search window a day at a time until it covers the backlog you actually want on the board.</li></ol><h2>What to watch in the first week</h2><ul><li><strong>Automated mail.</strong> Delivery receipts and out of office replies match a support label surprisingly often. Add a sender exclusion when you see the first one.</li><li><strong>Long threads.</strong> A conversation with fifteen replies produces one card and fifteen comments, which is correct but heavy. Some teams cap the comment step at the first three replies.</li><li><strong>The card that nobody moves.</strong> If cards pile up in the first list, the problem was never the inbox. The board just made it visible, which is uncomfortable and useful.</li></ul><blockquote><p>We ran the old inbox and the new board side by side for a week so people could bail out. Nobody bailed out. By Thursday two people had stopped opening the shared mailbox entirely.</p><p>Idris Bakare, support manager at Palmwood Studio</p></blockquote><h2>The part that is not a flow</h2><p>Cards arriving is half the job. Somebody still has to decide what a finished card means and who moves it there. Agree on three lists before you build anything, keep the names boring, and let the board argue with you for a week before adding a fourth.</p>