👤 For people who use Pipefy to receive and reply to email from customers, vendors or candidates, in support, procurement or HR processes.
🔐 Available on all plans (the automatic email cap varies by plan).
🎯 For anyone who wants every reply to land on the right card, with no duplicate card per reply.
A customer replies to an email that went out from a card, you open the process expecting to see the conversation continue there, and instead you find a brand new card in the first phase, no history, no context, cut off from everything already handled. When this happens a few times a day, the process inbox turns into a pile of conversations sliced in half, and whoever picks it up has to rebuild by hand which reply belongs to which request.
By the end of this article, you will know why these replies drift away from the card they came from, and which configuration choices keep the whole conversation, back and forth, stored on the right card. The point is not which button to press, it is understanding the logic Pipefy uses to tie each message to its card. Once that logic is clear, the configuration decision follows naturally.
📖 What you will understand here:
The conversation lives inside the card, not outside it
In Pipefy, email is not an attachment to the process nor a separate tool. Each card has its own email inbox, and every message sent from there goes out with a unique reply address, generated by Pipefy for that card alone. That address is the backbone of everything that follows: it carries the card's identity into the conversation.
When the external contact receives the message and hits reply, the reply travels back to that unique address. Pipefy recognizes the address, knows exactly which card it came from, and slots the reply into that card's email tab. The thread stays whole, in order, inside the context where the person needs it. That is why thinking of email as part of the card, rather than as a parallel channel, changes how you design the process.
The linking logic is the unique reply address, not the message subject. Two emails with the same subject do not merge because of it, and changing a reply's subject does not break the link. What ties a conversation to a card is always the address.
Why a reply sometimes becomes a new card
If the link depends on the unique reply address, the duplicate shows up exactly when that address is missing from the reply. The new card is not a defect: it is Pipefy's correct behavior when facing an email that arrived without any existing card's identity. It has no way to guess which conversation it belongs to, so it treats it as a new request.
In practice, the link is lost in two situations.
- The first is when the reply does not go out from the card's unique address, for example when someone forwards the message externally instead of replying through the original path.
- The second is when something alters the email header in transit and the unique address stops being recognized. In both cases, Pipefy receives an orphan message and does the only coherent thing: it creates a card for it.
A common trap in the shared inbox: using "reply all" puts the pipe's own address on the recipient list. That makes the process email itself and creates a card-creation loop. Select only the recipients that make sense for each reply.
What keeps the conversation tied to the card
Because the link lives in the unique reply address, the configuration decision that holds everything together is making sure the process receives replies through that path, with no intermediaries that erase the card's identity. It starts by enabling the pipe's own email address and, when the team uses a corporate support address, redirecting that address to the pipe's address, so every message comes in through the right door.
The second decision is about how replies come back. When the contact replies directly to the message they received, the unique address goes along and the link holds. What you want to avoid in the process design are the paths that discard that address: manual external forwards, replies started from an outside email client instead of the card, or redirect rules configured in a way that rewrites the sender. The step by step for each screen is in the Help Center; what matters here is the underlying decision, keeping the unique address intact end to end.
When an email should create a new card
Not every incoming message should continue a conversation. The question that guides the design is: is this message the continuation of something already in progress, or a request that does not yet exist in the process? A reply to an open ticket belongs to the card that already exists. A first contact from a new customer, arriving at the process email, is a brand new request and should be born as a new card in the initial phase.
The pipe inbox feature covers exactly this second case: emails arriving at the process address that have no link to any card yet become cards automatically, with the initial form fields filled from the email fields. The decision criterion is the link: if the message carries a card's unique address, it updates that card; if it does not, it opens a new card. Designing the process with this distinction clear is what avoids both unwanted duplicates and the opposite, strangers' replies getting lost inside a card that is not theirs.
A high volume of first contacts through the pipe inbox calls for an initial phase built for triage, not for work. A card just created by email arrives raw: whoever receives it needs room to read, classify and decide where it goes, before the process takes over.
Before moving on, make sure you understand:
☐ The link between a reply and its origin card is made by the card's unique reply address, not by the message subject.
☐ The duplicate appears when that unique address does not reach the reply, through an external forward or a change in the email header.
☐ You can decide, for your process, when a message should update an existing card and when it should create a new one.
