Exploring advanced email workflows in FluentSupport (Postmark + webhooks)
Over the last weeks I’ve been digging deep into FluentSupport email workflows and ran into a few limitations that surprised me.
Mainly around:
- Reply-all behavior (especially preserving original CC recipients)
- Adding extra CC recipients on replies
- Not receiving tickets if we are in CC
- Better handling of forwarded emails
- Inline CID image rendering (screenshots/newsletters staying visible inside tickets)
- Stricter thread matching (preventing unrelated emails with similar subjects from being merged)
- More transparent logging of inbound mail flow
I ended up building a bridge on top of FluentSupport using Postmark inbound webhooks instead of the native piping flow.
Important: not as a replacement of FluentSupport itself, but as a narrower and more controlled mail-routing layer.
We are still in testing mode
That gave me much better control over:
- mailbox routing
- threading logic
- reply-all recipients
- inline attachments/images
- debug visibility
My question to the community:
Do you recognize these limitations in real-world support setups?
And for the Fluent team:
Thanks for your answers so far in our private communication.
But still curious: Were some of these choices intentional (to keep complexity low), or are they simply not high-priority yet?
Yes Roelinde Brons - threading logic and forwarded emails both cause me headaches.
Jonathan Gwyer how do you deal with it? If a client can not forward an email, you just tell them you cant read it? Or grab the forwarded email from your original inbox?
That doesn't seam to be a permanent solution to me.
Roelinde Brons exactly that - back to the original inbox, which means making sure that agents understand that forwarded contents are lost, and having to give them access to the inbox.
PITA 🤣
the CC part caused us major confusion with our customers (espeically those type of people who CC everyone), wish there was an option to turn it off so only the original submitter follows the ticket.
This is definitely something that I'd really like to see additional development on.
We currently operate our support system without a dedicated email box. Emails get directly forwarded to the FluentSupport email to be piped in. We just switched from FreshDesk and this is one thing I didn't run into with my basic testing. I would agree that it we need to be able to have the whole email thread come into the ticket. I'd rather have too much data in the ticket than not enough. I'd also like to see CC'ed recipients be automatically added to the ticket as CC'ed recipients with the ability to be able to remove them before an agent replies.
Also stripping out inline images is a nightmare for us. Sometimes people forward us content that needs to be added to a website or email marking campaign and now our current setup would require us to either request them to resend their email to an email address outside of our support email address (directly to a personal agent's inbox) or reply and add the files to the email as attachments.
FreshDesk also had the ability to be able to forward a ticket in on behalf of another person. In other words if a client sent an email to my direct email address (not the support email address) I would be able to forward that email to the support email address and it would automatically create the ticket as the client. Currently when I forward in an email it creates the ticket as me being the customer and I have to manually change the customer from within the ticket.
I'm going to look into this a bit more and see about using the API to handle ticket creation instead of email piping.
That's very similar to the issues we ran into.
We decided to investigate whether these limitations could be solved while staying fully compatible with FluentSupport. In our case we use Postmark inbound webhooks instead of native email piping.
We now have this running in production, covering things like CC handling, forwarded emails, inline images, Reply All, more reliable thread detection and a few other email workflow improvements. We'll continue to monitor it, but the initial results are very encouraging.
Personally, I'd much rather see capabilities like these become part of FluentSupport itself than maintain a separate long-term plugin around it. Once we've gained a bit more production experience, I'm happy to share what we've learned with the Fluent team if that's useful.