How to turn Microsoft Teams messages into Jira tickets with context
Two different problems hide inside one question. Turning a Teams message into a Jira ticket is a Power Automate flow triggered off that message, and Microsoft ships a purpose-built trigger for exactly this. Getting Jira's updates to show back up in the same Teams channel is a different mechanism running in the opposite direction, and it lives inside Jira, not inside Teams. Neither one turns the other on. A team that wires up ticket creation and stops there gets a one-way funnel. Messages go in, and anyone who wants to know what happened has to open Jira and look.
The honest answer to "how do I connect these" is that you're building two automations, not one, and the second is the one most tutorials skip.
How Teams already supports filing the ticket
Microsoft Teams has a built-in For a selected message trigger for Power Automate. Right-click any message, run the flow, and the trigger hands your flow the message's plain text, a link back to it, and the sender's name, exactly as Microsoft's own documentation describes it. From there the flow calls whichever tracker you use. Jira has an official Power Automate connector for creating issues; Linear doesn't, so that side needs a raw HTTP call to Linear's GraphQL API instead. We've walked through that split, the license tier it requires, and where a keyword-only version of this flow breaks, in a full guide on turning a Teams message into a Linear or Jira ticket. If you haven't built this half yet, start there.
What matters for this guide is what that flow does not do once it's built. It creates a ticket and stops, and nothing about it watches the ticket afterward.
How the reverse direction lives inside Jira
This half runs the other way, and it's built into Jira Cloud's automation engine, not Power Automate. Jira's automation actions include a Send Microsoft Teams message action, described in Atlassian's own docs as sending "a Microsoft Teams message to notify a team when a flow is run." Pair it with a Work item transitioned or Work item commented trigger, the current names Atlassian's own trigger documentation lists in place of the older "Issue transitioned" trigger, and any status change, assignment, or comment on that issue can post into a Teams channel without a human copying anything.
There are two catches worth knowing before you build it. The action can't post to a private channel, per Atlassian's own note on the setting, so anything scoped that way needs a standard channel instead. And the action needs a webhook URL to post to, which is where the setup gets less obvious than it should be.
“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 webhook URL is not what old tutorials assume
Older guides on this exact pairing tell you to add an "Incoming Webhook" connector in Teams and paste the URL into whatever's sending the message. That path is going away. Microsoft's own current documentation states plainly that "Microsoft 365 Connectors (previously called Office 365 Connectors) are nearing deprecation, and the creation of new Microsoft 365 Connectors will soon be blocked," and points teams instead at the Workflows app.
The current way to get a webhook URL a third-party tool can post to is to build a Teams workflow using the When a Teams webhook request is received trigger, which Microsoft documents as the direct replacement. That workflow, once created, exposes a URL. That's the URL you paste into Jira's Send Microsoft Teams message action, and Jira automation admins can restrict which domains are allowed there. The same actions doc notes that admins "can also set restrictions on which domains can be used by the action" and should "select View allowlist to make sure the webhook URL you add is included."
One limitation carries over from the workflow itself rather than from Jira's side of it. A Teams workflow is owned by whoever created it, not by the channel or the team, and Microsoft's docs say as much directly, warning that "Workflows can become orphan flows in the absence of an owner if no co-owners assigned." If the person who built the webhook workflow leaves and nobody was added as a co-owner, the flow stops running silently, and Jira's automation rule keeps firing into a URL that no longer does anything.
Kestrel Freight's helpdesk channel
Kestrel Freight runs a shared IT helpdesk on a Teams channel called #helpdesk-escalations, where anyone in the company can flag a broken VPN connection or a stuck payroll sync. For a while, the escalation path ran entirely through people. Someone posts in the channel, the on-call IT engineer manually files a Jira ticket in the HELP project, and status lives in Jira from that point on. Naomi Castellan, who runs the helpdesk rotation, raised it in a retro, saying that much of her day went to answering "did anyone look at this yet" in the channel for tickets that already had an answer sitting in Jira.
Owen Halvorsen, the IT ops engineer who owns the HELP project, built both halves. He wired the Teams For a selected message trigger to a flow that files a HELP ticket from the original post. Then, inside Jira, he built an automation rule on HELP with a Work item transitioned or Work item commented trigger, a Send Microsoft Teams message action, and a webhook URL from a new Teams workflow he created in #helpdesk-escalations.
It worked immediately. A VPN outage ticket moved from "In Progress" to "Resolved," and the channel got a message without Owen touching Teams. Naomi stopped fielding status questions for HELP tickets within a week.
Where it stopped being one project's problem
The setup Owen built is scoped to one Jira project and one Teams channel, tied together by one automation rule and one webhook URL. Kestrel Freight doesn't only have HELP. Payroll systems has its own project and its own channel, network infrastructure has a third, and each one needs the same rule rebuilt by hand, a new Teams workflow for the webhook, a new automation rule in Jira pointed at it, and someone remembering that the pattern exists at all when a fourth project spins up.
None of that is a Jira limitation. It's what happens when the unit of connection is "one rule, one channel" and the number of channels keeps growing. Six months in, Kestrel Freight had four of these rule-and-webhook pairs, no shared list of which project posts to which channel, and one incident where a workflow silently stopped posting for two weeks because its owner had left the team without a co-owner assigned, exactly the failure mode Microsoft's docs warn about. Nobody noticed until someone asked why NETOPS tickets hadn't shown up in the channel in a while.
There's also a limit the rule-based approach never solves even when it's running correctly. It reports on the ticket, not on the conversation. If someone in the channel rephrases the same request differently a month later, "the VPN drops every afternoon" instead of the original wording, the automation has no way to know it's the same issue, because it only watches Jira, never the channel it's posting into.
How Modem handles this instead
This is the point where a rule-per-channel setup stops being the fastest way to keep Teams and Jira in sync, and it's the category Modem works in. Modem's Microsoft Teams integration reads the channels you connect it to directly, without a webhook workflow to maintain per channel, and its Jira integration keeps each conversation and its ticket as one linked topic in both directions. A new message can update an existing ticket instead of always filing a new one, and a status change or comment on the Jira side posts back into the right Teams thread automatically, scoped by the topic rather than a project-to-channel mapping someone has to maintain. We build Modem, so weigh that against the DIY path on its merits, but the maintenance gap it closes here (no orphaned workflows, no per-project rule sprawl, no rephrased request treated as a new ticket) is a real one. For the notification half specifically, closing the loop when a Jira issue ships covers the same "tell people automatically" problem from the customer-facing side.
What to build first
If Kestrel Freight's setup sounds like where you're headed, build the two directions in order. Start with the Teams-to-Jira flow, since it's the one your team will notice missing immediately, then add the Jira-to-Teams automation rule on your busiest project, using a Teams workflow with a co-owner assigned from day one. One project, wired both ways, is a fair test of whether the whole pattern is worth it before you build a fourth copy of it by hand.
