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 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.
Where it stops being one project's problem
Everything above is scoped to one Jira project and one Teams channel, tied together by one automation rule and one webhook URL. Most teams don't stay at one. The payroll system has its own project and its own channel, network infrastructure has a third, and each one needs the same setup 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. A few rule-and-webhook pairs in, there's no shared list of which project posts to which channel, and a workflow can stop posting silently because its owner left without a co-owner assigned, exactly the failure mode Microsoft's docs warn about. Nothing surfaces that failure on the Jira side either, so the usual way it gets found is somebody eventually asking why a project's tickets stopped showing up in the channel.
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
Past a few rule-and-webhook pairs, that setup stops being the fastest way to keep Teams and Jira in sync, and Modem works in the category that replaces it. 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 together on one topic. A new message lands on the same topic as an existing ticket instead of starting a new one, and the agent can update the Jira ticket when you ask, 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 that pattern 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.