How to forward feature-request emails from a support alias into Linear
The actual setup is two pieces, not one. A rule on your support alias matches feature-request-shaped language, and Linear's own email address turns a forwarded message into an issue. Neither piece does the other's job. Linear's intake will create an issue from anything that lands in it, feature request or not, and your alias tool won't send anything to Linear on its own until you tell it to.
That split is the part people miss. They set up Linear's email-to-issue address, forward the whole support@ alias to it, and end up with a Triage column full of password resets and shipping questions sitting next to the two emails that actually mattered. The fix isn't a smarter Linear setting. It's a rule upstream that decides what gets forwarded in the first place.
“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 NotionWhat Linear's own email intake actually does
Linear supports creating issues by email natively. Turn it on per team under Settings > Your teams > General > Create issues by email, or generate one scoped to a specific template, and Linear hands you a unique address. According to Linear's documentation, every email sent or forwarded to that address becomes a new issue, landing in Triage or the team's default workflow status. Replies on the same thread don't create duplicates, and attachments come through up to 25 MB per email.
What it doesn't do is look at what the email says. There's no keyword match, no bug-versus-feature detection, nothing that decides whether a message is worth an issue at all. Every email in is an issue out. That's fine if the address only ever receives things you've already decided are worth tracking. It's a mess if you point your entire support@ alias at it, because "how do I reset my password" gets the same treatment as "we need bulk export before we renew."
Why Front's Linear app doesn't solve this either
If your alias runs through Front, there's a native Linear app listed in Front's integration directory, and it does less than the name suggests. Front's own description is "quickly create Linear issues from within Front," which is a button a teammate clicks on one open conversation. It's not a rule action. Front's rule-automation actions include forwarding, webhooks, Zapier, and a short list of third-party connectors, and Linear isn't one of the connectors in that list per Front's guide to rule triggers, conditions, and actions. The automatable path to Linear from a Front rule is forwarding to Linear's email address, not a native "create issue" action firing on a rule.
The setup that actually filters
With those two facts established, the working setup is:
- Turn on Linear's email intake for the team that should own these requests, and copy the generated address.
- Write a Front rule with a content condition, not a tag or sender condition. Front's rule conditions include "message body contains," which matches on the words in the email itself, per the same rule-conditions guide. Match on phrasing like "would love," "any chance you could," "feature request," "wish it could," or "any plans to add."
- Set the rule's action to forward the matching message to Linear's intake address. Front's forward action works exactly like manually forwarding the email; it doesn't need Linear to be a listed connector, because as far as Front is concerned it's just an email address.
- Point the rule at a template-scoped address if you want structure. Linear lets an email address be tied to a specific issue template, so the forwarded email's contents fill the title and description while the template supplies labels and a project. That's the difference between a Triage pile and issues that already carry the right tags.
If your alias lives in plain Gmail instead of Front, the same shape works with a filter. An unquoted keyword in a Gmail search or filter matches against the message body, not just the subject line, and the filter's action list includes automatic forwarding, per Gmail's filter documentation and Gmail's search operators reference. The one extra step Gmail requires is adding Linear's address as a confirmed forwarding address first. Gmail sends a verification link to that address, and forwarding to it stays disabled in filters until the link is clicked. For a Linear-generated intake address with no inbox behind it, that means grabbing the confirmation email from wherever Linear's address actually delivers, usually by adding it to the team's forwarding rule temporarily just to catch that one message.
What a phrase list can't do for you
The rule works, and it's the right first move. It also has a shape that gets harder to live with as volume grows:
- Every new phrasing is a manual patch. "Any chance," "would love," "wish it could," and "hesitant to reorder" are four ways of saying the same thing, and a keyword rule needs all four typed in by hand before it catches all four.
- It has no memory. Ten differently worded emails about the same missing feature become ten separate Linear issues, because the rule matches language, not intent, and Linear's intake creates a new issue every time regardless.
- Nobody's counting. The rule tells you an email arrived and got forwarded. It doesn't tell you "this is the ninth person asking for this," which is the number that actually justifies prioritizing it.
Adding a classification layer beats extending the keyword list here. We build Modem, and its email integration is built around how differently customers word the same request. Forward the alias to a Modem-provided address, in bulk or as it arrives, and it classifies each message on what it's actually asking for rather than matching against a phrase list, then dedupes recurring requests into one counted topic instead of one issue per wording. Modem's Linear integration files the result as an issue carrying the original customer quotes, not a bare title, and links it to the person and company who asked so the count survives past the first mention. Modem is our product, not neutral advice, so judge the fit for yourself rather than taking our word for it. A support alias doing a few dozen feature-request-shaped emails a month is genuinely fine on the rule above.
If your alias problem is about routing and ownership rather than tracker handoff, how to route support emails when account ownership data lives outside your inbox covers the Front side of that in more depth. And if the question isn't new emails but a backlog of old ones that might contain the same recurring ask, how to search years of old support emails for a recurring feature request is the guide for the retroactive version of this problem.
A one-rule version you can turn on today
Turn on Linear's email-by-team intake, write one Front (or Gmail) rule matching your five most common feature-request phrases, and point it at that address. Check the Triage column after a week: if it's mostly relevant, keep tuning the phrase list as you notice gaps. If it's mostly noise, the rule is catching too broadly and needs tighter conditions, not more of them.
