Turning a Microsoft Teams message into a Linear or Jira ticket
The workflow is Power Automate, but which flavor depends on which tracker you're filing into. Teams has a built-in "For a selected message" trigger that turns any message into a one-click flow with no license upgrade required. Jira has an official connector for the other end, but it's a Premium connector, which means someone on the team needs a Power Automate per-user or per-flow plan, not the free tier bundled with Microsoft 365. Linear has no official connector at all, so the flow has to call Linear's GraphQL API directly over HTTP with a personal API key or an OAuth token.
Both paths skip manual copy-paste. Neither path is "connect two apps and you're done." Here's what each one actually involves, and where the setup that works for one keyword phrase stops working for ten.
“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 NotionThe trigger that actually ships: "For a selected message"
Microsoft's own documentation for triggering a flow from a Teams message describes the mechanism plainly: build a flow with the For a selected message trigger, and it shows up as a right-click action on any Teams message under "More actions." Click it, and the flow runs with the message content, the sender's name and ID, and a direct link to the message available as trigger outputs.
This is a real, working, zero-cost mechanism, and it's worth understanding before reaching for anything heavier. Two things about it matter for a ticket-filing workflow. It's manual by design. Nothing fires until a human selects the message and clicks the flow, which is a feature if you want a person deciding what becomes a ticket, and a limitation if the goal is to stop anyone from having to notice the message in the first place. And sharing isn't automatic. Microsoft's docs note that only the flow's author can trigger it unless they explicitly share it with the rest of the channel or chat, so a flow one person builds for themselves doesn't extend to their team without that extra step.
The alternative is the Teams connector's When a new channel message is added trigger, which polls a channel automatically (on a roughly three-minute interval, per Microsoft's connector reference) and can run unattended with a keyword condition attached, something like "if the message contains 'export' or 'SSO', continue." That's the version that scales past one person clicking a button, and it's also the version most Teams-to-tracker tutorials build, including the walkthrough Bitcot documents for wiring Teams into Jira.
What happens on the tracker side
Once the flow has a message, it needs to file it somewhere, and this is where the two trackers diverge:
Jira has an official Power Automate connector, confirmed in Microsoft's connector reference as a Premium-tier connector with a Create a new issue (V3) action that takes a project, issue type, summary, and description. Premium means the flow needs a Power Automate per-user or per-flow license attached to whichever account runs it. The license bundled free with Microsoft 365 only covers standard connectors, and Teams is standard while Jira is not. Bitcot's walkthrough mentions in passing that the same connector can be swapped for a raw HTTP call to Jira's REST API, without saying why a team would pick one over the other. That's worth being precise about, because it isn't an escape hatch from the license. The built-in HTTP action carries the same Premium flag in the flow designer, so a hand-built HTTP call to Jira costs the same license as the connector it's replacing.
Linear doesn't have an official connector in Microsoft's catalog at all. Linear's own GraphQL API documentation covers two ways in: a personal API key for scripts, or OAuth2 for anything built for a team to share. Either way, a Linear-bound flow is an HTTP action inside Power Automate, posting a GraphQL mutation with the Authorization header set by hand, not a connector picked from a dropdown. That's more setup than Jira's side, and it doesn't change the license math either. Microsoft's Standard tier connector list has no connector literally named "HTTP," because HTTP isn't a certified connector at all. It's a built-in action, and Power Automate's designer flags it Premium. Whoever owns a Linear flow built this way needs the same per-user or per-flow license as the Jira side, without an official connector to show for it.
Either way, the flow author is now maintaining an integration Microsoft didn't build turnkey for at least one side of it, and paying for the same Power Automate Premium seat regardless of which tracker the flow points at.
The keyword problem, worked through one channel
Wexford Trust is Anvix's largest payroll customer, and every conversation between the two companies runs through a single Teams Connect channel, since Wexford's IT policy blocks external Slack guests. Anvix's implementation lead, Declan Meyerhoff, built a flow off When a new channel message is added, scoped to that channel, with a condition: if the message text contains "SSO" or "single sign-on," create a Linear issue via the GraphQL HTTP action, with the message text and a link back to Teams in the description.
It worked the first time it mattered. Someone on Wexford's IT team posted in the channel that their security review had flagged the payroll portal for still lacking forced SSO, and asked whether it could move up before the Q1 audit. The condition matched, the flow fired, and ANV-514 appeared in Linear with the message pasted into the description.
Three weeks later, someone else at Wexford asked the same thing in a reply thread, worded as "any movement on the sign-on requirement?" The keyword condition didn't match, because "sign-on" isn't "SSO" and isn't "single sign-on." No new issue got created, and no comment got added to the existing one, because the flow only knows how to create, not how to recognize a repeat. Declan found out about the second ask when Wexford's account manager forwarded him a screenshot.
Where the flow runs out
A condition built on exact keyword text is really a small, brittle classifier, and it fails the way small brittle classifiers always do: it catches what it was written to catch and misses every rephrasing. Scaling it from here means picking one of a few losing tradeoffs. Declan could add more keywords to the same flow, but every synonym is a manual edit to the condition, and someone has to notice the miss before they know to add it. He could build a second flow for a second customer channel, but that means rebuilding the condition from scratch, and now two people maintain two flows that quietly drift apart from each other. Or the misses get accepted, which is what happens by default without a decision to do otherwise, and which surfaces later as a customer asking the same question twice.
None of that fixes the harder problem underneath the keyword list: a flow like this creates issues, it doesn't dedupe them. In Declan's case, one phrasing became a ticket and the other became a forwarded screenshot. Scale that pattern across more channels and more ways of asking the same thing, and a single request fragments into unlinked tickets or silent misses, and whoever ships the fix has no single place to look to see everyone who asked.
Where Modem picks this up
This is the category Modem works in. Modem's Microsoft Teams integration subscribes to the channels you choose, including Teams Connect channels shared with a specific customer, and reads every message without a keyword condition deciding what counts. Messages get classified and clustered into topics regardless of phrasing, so a request phrased as "SSO" one week and "sign-on requirement" three weeks later lands in the same topic instead of one flagged case and one missed rephrasing nobody sees until the customer repeats themselves.
On the tracker side, Modem's Linear integration and Jira integration let the agent search for an existing issue before filing a new one, create issues with the customer's quotes and the surrounding conversation attached instead of a bare one-line title, and update status from a Slack or dashboard conversation. Neither integration needs a Power Automate Premium seat or a hand-maintained GraphQL mutation; connecting either tracker is an authorization step in Modem's settings. Modem is our product, not a neutral referee, so read this comparison as the pitch it plainly is. For the DIY side of the equation, Zapier and n8n's Slack-to-Jira patterns and keyword search inside Teams itself run into the same dedupe gap from different starting points, and the fixes look similar however the message arrives.
One channel is a reasonable place to stop
Wexford Trust is Anvix's only Teams Connect customer today, and most of what comes through that channel is recognizable on sight, topics like SSO that Declan already knows by name. For that specific shape of workload, a flow scoped to one channel, a keyword list reviewed monthly, and a habit of checking Linear for near-duplicates before trusting what the flow filed doesn't need replacing. It costs nothing beyond time Declan is already spending reading the channel.
What changes the math is scale in either direction. A second customer channel would need its own keyword list and its own flow to maintain, or phrasing on the existing channel could start drifting past what the current keywords catch. That's the point where adding another condition stops being the fix, and reading the message instead of pattern-matching its words starts being worth the switch.
