How to Route Salesforce Cases Tagged 'Feature Request' to the Right Eng Backlog
Salesforce's Case Type field can drive an Assignment Rule the moment a rep saves a record, but an Assignment Rule can only hand the case to a Salesforce queue or a Salesforce user. There's no field on that rule for "Jira project" or "Linear team," because those live in a different product Salesforce has no visibility into. Getting a case tagged Type = Feature Request into the correct engineering backlog automatically means putting something between the two systems. That something is logic that reads the case, decides which project or team it belongs to, and calls that tracker's API to create the issue there.
That logic is usually a Flow and a handful of branches, not a platform purchase. The part that takes ongoing effort is the same one any picklist-driven system runs into. Feature Request tells you the category, not the destination. The mapping between categories and destinations is something a person has to write down and then keep current as teams and projects change shape.
“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 Case Type alone can't finish the job
A Case Assignment Rule evaluates a case's fields in order, and the first matching rule entry wins, handing ownership to a queue or a user. Building a rule entry on Type = Feature Request is completely standard, well within what Salesforce ships natively. What that queue can't do is turn into a Jira project or a Linear team on its own. A queue is a Salesforce record holding Salesforce records; the case still has to leave Salesforce entirely before it becomes an issue anywhere else, and nothing native makes that hop.
Salesforce's own admin community treats the next step as a build-it-yourself problem, too. Its guide to building a request-management app walks through screen flows that route requests by matching skill or need, and separately notes teams wiring the same kind of app into a Jira board. The wiring between "which category" and "which board" is something each team builds for itself. There's no setting for it.
Two ways to actually wire it
Once the mapping is decided (this Case Type plus this Product Area goes to that project, that combination goes to that team), there are two practical ways to execute it.
The direct route is a Salesforce Flow with an HTTP Callout action, triggered on case creation, that calls the tracker's API straight from Salesforce using a Decision element to pick the destination. Jira's issue-creation endpoint requires a project id or key and an issue type on every request, so those are exactly the two values your Decision element needs to output. Linear's API works the same way in spirit, with different required fields. Creating an issue through its GraphQL API takes a teamId, since issues in Linear belong to a team first, and a project is an optional grouping that can even span teams. A case that should land with the Routing Engine team maps to that team's id, not to a project id. Get that mapping wrong and the callout comes back with a schema error instead of a filed issue.
The lower-code route works for Jira specifically. Point the Flow at a webhook instead of calling Jira's API directly, and let a Jira Automation rule with an incoming-webhook trigger read the payload, branch on whatever fields you sent, and run a Create-issue action into the matching project. Linear has no equivalent no-code rule builder for inbound webhooks, so if Linear is a destination, the branching logic has to live in the Flow or in middleware. You're calling issueCreate directly either way.
A worked example of the mapping breaking
The scenario below is illustrative, not an account of a real customer. It plays out close to how this goes wrong for teams that build it.
Picture a company where support runs through Salesforce and two engineering teams split the resulting work. A core team owns the product logic and tracks its backlog in Linear. An app team owns the customer-facing surface and tracks its backlog in Jira. For months, every case tagged Type = Feature Request lands in one shared queue, and a PM covering both teams reads each one and types it into whichever tracker fits.
Support: This case is tagged Feature Request but Product Area is blank. Core team or app team?
PM: If it's about how the underlying logic works, core team, Linear. If it's about anything on the customer-facing screen, app team, Jira. Tag it and I'll get a flow doing this so you stop having to ask me.
The fix adds a required Product Area picklist (Core, App, Billing, Admin) to the Feature Request record type, plus a Flow that reads Type and Product Area together. Core and Billing route to a Linear team id. App and Admin route to a Jira project key. Cases stop sitting in the shared queue waiting on the PM to read them.
A month later, one case breaks the mapping. It's tagged Feature Request, Product Area: Admin, and it's about a setting an account owner wants turned on by default for every user, so the Flow files it as a Jira issue in the App project. The core team owns that setting, because it lives in the product's configuration layer, not the customer-facing surface, and "Admin" as a category doesn't distinguish account administration from product administration. The Flow does exactly what it's told. The picklist isn't specific enough to tell it the right thing.
Where the mapping keeps needing rework
Two failure modes show up on a long enough timeline, and neither is a Salesforce problem:
- The taxonomy is never quite fine enough. Four Product Area values feel complete until a request spans two of them, the way the case above did, and the fix is always another value or another branch, never a one-time correction.
- The mapping is frozen the moment someone writes it. A new squad, a merged team, or a renamed project means editing a Decision element by hand, and that edit often happens weeks after the org chart already changed, during which every case routes to wherever the last config still points.
Underneath both is a gap the Flow was never built to close: it only sees requests that arrive as a Salesforce case. The same ask that shows up as "we ended up building a workaround for this" on a support call, or gets mentioned twice in a Slack thread with a customer, never enters a Case object, so it never gets classified at all. Nobody on the team knew that case was the third mention of that setting. It was just the first one anybody wrote down as a case.
Where Modem picks up from here
Past that point, most teams don't fix it with a smarter Flow. Modem works the request from a different direction. Modem wrote this guide. Its Salesforce integration syncs accounts, contacts, opportunities, and users into Modem for context. It doesn't ingest Cases directly today. What it does do is watch the trackers on the other side. Modem's Jira integration watches the projects you connect and can search, create, and comment on issues in them, and its Linear integration creates issues with the original quotes attached and checks for a matching issue before filing a new one instead of always creating fresh.
That combination mostly changes what happens with repeat asks. If the same ask already surfaced on a call, in Slack, or on an earlier support ticket, it's already a counted topic in Modem, tied to the account through the Salesforce data already synced, and usually already tied to whichever Jira or Linear issue someone filed for it the first time. By the time it shows up as a new case, the question isn't "which project does this go in," it's "is this the topic that already has an answer," and that's a lookup rather than a fresh routing decision. It doesn't remove the need for the Flow above; a request still needs a first home somewhere. It removes the need to re-solve the mapping question for every case that turns out to be a repeat of one already routed.
For the fully native version of this, without Modem or a connector, see how to track feature requests natively in Salesforce. Once a case is linked to an issue, keeping their status in sync as engineering works it is a separate problem, covered in how to keep Salesforce cases and Jira issues in sync.
The smallest version you can start this week
Pick the one Product Area value generating the most cases, confirm the single project or team it should always map to, and wire one Flow branch, with one HTTP callout or one webhook into a Jira Automation rule, for just that combination. Leave everything else routing to the shared queue by hand until the pattern proves out. The rest of the mapping gets added a branch at a time, which is a more honest starting point than enumerating every Product Area and every destination before the first case ever routes itself.
