How to apply tags retroactively to old support emails in Front
Front rules can't run retroactively. That's the direct answer from Front's own team on the community forum: a new tag rule only catches conversations arriving after you create it, so the six months of history sitting in the inbox before that point stays untagged forever unless you go back and do it by hand. The workaround, per Front's staff answer, is to use advanced search filters to pull the old conversations by keyword, then apply the tag to all of them at once with a mass action.
That's a real fix, and it works. It's also a manual process that has to be repeated for every keyword you care about, which is where it starts to strain once the taxonomy grows past a handful of tags.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhy rules don't reach backward in the first place
Front's rules engine is an event trigger. It evaluates each conversation as it moves (arrives, gets replied to, changes status) and runs its actions at that moment. It was never built to sweep a mailbox. Nothing in Front's rules documentation implies otherwise, and the community answer confirms it in one sentence: rules can't run retroactively.
The practical effect is that every time you add a new tag rule, you've drawn a line in your inbox's history. Everything after the line gets tagged automatically. Everything before it looks untagged, even if it's exactly the kind of conversation the rule was built to catch.
Step 1: build the search query that finds the old conversations
Front's advanced search filters are the tool for finding what a rule missed. The filters that matter most for backfilling a tag:
- Keyword search, plus the specific phrases customers actually use for the topic
before:andafter:(orduring:) to bound a date range, inYYYY-MM-DDformatis:archivedto include closed conversations, since most of what you're backfilling has already been resolved and filed awayfrom:or channel filters, if the request only shows up in one shared inbox
Stack two or three of these and you get a query narrow enough to trust, something like a keyword plus a date range plus is:archived. A query that's too broad means eyeballing results before you tag; too narrow and you miss the phrasing variants.
Step 2: select the results and apply the tag as a mass action
Once the search returns a clean set, Front's mass action feature does the tagging. For a small result set, shift-click or command-click the conversations you want. For anything larger, Front lets you select all: Cmd+A (or Ctrl+A on Windows) selects every conversation matching the current search, including ones that aren't rendered on screen, up to a documented cap of 10,000 conversations per mass action. Add/remove tags is one of the actions available on both small and large selections, alongside things like archive, reassign, and mark read.
Front's own documentation flags one nuance here: rules trigger on small selections but not on large select-all batches. If your tag has downstream automation attached to it (say, a rule that also notifies a Slack channel when the tag is applied), that automation won't fire retroactively even though the tag itself lands. Plan for that separately if the tag is wired to anything beyond just being a label.
A backfill that took an afternoon, not a sprint
Three separate "is there a warranty on the straps" threads slipped through the same shared Front inbox in one week before anyone noticed they were the same question. The inbox belongs to Ampersand Outdoor, a gear retailer, where Yusuf Demir handles support. As soon as he spotted the pattern he set up a warranty-question rule keyed to a few phrases in the subject and body.
The rule worked immediately for new mail. It did nothing for the roughly four months of warranty questions already sitting in the inbox, most of them archived once the ticket closed.
Yusuf: I want everything with "warranty" or "strap broke" in it since June, archived or not, tagged the same as the new stuff.
Support teammate: Ran
warranty strap broke is:archived after:2026-06-01, got 41 conversations. Selected all with Cmd+A and added the tag.
Forty-one conversations, tagged in one pass, in under ten minutes once the query was right. Yusuf ran three more searches that afternoon for the other phrasings he could think of — "torn strap," "under warranty," "replacement part" — and picked up another 19 between them. The whole backfill took an afternoon, not because the tool was slow but because each phrasing needed its own search.
The limits of the search-and-tag workaround
This holds up fine for a one-time backfill against a tag you can describe in a handful of keywords. It stops working cleanly in a few predictable spots:
- Phrasing you didn't think to search for. Yusuf's three keyword variants aren't exhaustive. "The strap gave out" or "clip snapped" describe the same warranty issue and won't match any of his queries, so whatever's left uncounted stays invisible.
- A taxonomy with more than a few tags. Each tag needs its own search-and-mass-action pass, repeated for every phrasing. Backfilling twenty tags this way is twenty times the work, not once.
- Doing it again next quarter. The backfill isn't a one-time chore if the taxonomy keeps growing, since every new tag means going back through history again.
- Counting who asked, not just how many. A mass-applied tag marks the conversation. It doesn't tell you it was the same customer asking three times across three threads, which is usually the number that matters for prioritization.
Those last two points are where we come in. Modem doesn't use rules or keyword searches at all: every workspace gets a dedicated inbound address, and any email forwarded to it, one message at a time or the whole backlog in bulk, gets classified into topics automatically. Getting old mail into Modem still takes an action; someone has to pull the backlog together and forward it over, which isn't fundamentally different in kind from the search-and-mass-action pass above. What changes is what happens once it arrives. A warranty question phrased three different ways across old and new threads still counts as one topic with three requesters attached, because Modem matches on what the message means rather than on which literal words it contains. There's no separate search to write per phrasing, and no per-tag rule to maintain as the taxonomy grows.
For the day-to-day version of this same problem in Front, see the tools that turn Front emails into feature requests, and for the wider question of getting signal out of a support inbox generally, the best tools to mine customer feedback in email. Below the point where a handful of tags cover what you need, the search-and-mass-action workaround above is genuinely the right tool — it's built into Front, it's free, and it takes an afternoon.
One tag is enough to know
Pick the one tag whose backlog bothers you most, write down every phrasing a customer might have used for it, and run one search per phrasing with is:archived included. Select all, apply the tag, and see how many conversations come back. That count is usually the argument for whether it's worth doing the rest of the taxonomy the same way, or worth automating.
