Before you evaluate a single Marketplace app, it’s worth knowing exactly what Jira and Confluence already do for each other out of the box. Sync-o (also written as synco) exists because the native layer has real limits, but most teams reach for a paid tool before they’ve actually configured what’s free. This is a setup guide for smart links, Jira macros, JQL-driven content, and automation rules, the four native building blocks, and an honest look at where each one stops being enough.

Quick answer: Native Jira Confluence integration covers three layers: smart links (paste a Jira URL, get a live status preview), the Jira Issue/Filter macro (embed a JQL-filtered table of issues), and Jira automation rules (create Confluence pages from templates on ticket events). All three are free on every Jira Cloud tier. None of them update an existing page’s written content when the underlying ticket changes again after creation.

Paste a Jira issue URL (something like https://yoursite.atlassian.net/browse/PROJ-1247) directly into a Confluence page and it renders as a live preview card: status, assignee, summary, and priority, all pulled from Jira without any macro configuration. This works automatically when the Jira and Confluence sites sit in the same Atlassian organization. It’s the fastest native integration to turn on because there’s nothing to turn on: it’s default behavior the moment both products are connected.

The catch is in the word “preview.” The card reflects the issue’s state as of when the Confluence page was last loaded, not a live push feed. If PROJ-1247 moves from In Progress to Done five minutes after someone views a page referencing it, the card still shows In Progress until the next page load. For a status reference on a page someone checks daily, that’s a non-issue. For an on-call runbook consulted once during an actual incident, a five-minute-stale status card is rarely the problem; a five-month-stale paragraph of manually written instructions next to it usually is.

Configuring the Jira Issues and Filters Macro in Confluence

Smart links show one issue. The Jira Issues/Filter macro shows many, and it’s the right tool for a “what’s currently open” or “what shipped this release” table embedded in a page. Insert it via the /jira slash command, then either paste a saved filter’s URL or write JQL directly into the macro’s search field. A release notes page pulling every Story resolved in a given fix version is a common, useful configuration:

project = PROJ AND fixVersion = "2026.7" AND status = Done
ORDER BY resolved DESC

Choose which columns render (Key, Summary, Assignee, Status, Resolution are the common set) and the table updates itself on every page load, no manual re-pasting of ticket lists required. This is meaningfully more durable than a smart link for anything list-shaped, and it’s the piece of native integration most teams under-use relative to how easy it is to set up.

Using JQL to Surface Related Work Automatically on a Page

The macro is only as good as the JQL behind it, and most teams write JQL that’s too broad (an entire project) or too narrow (a single fixVersion, requiring a new macro every release). A more durable pattern uses a label convention instead of a version: tag every ticket touching a specific system with a consistent label (auth-service, billing-v2) and drive the macro from that label rather than a release identifier that changes every sprint.

project = PLATFORM AND labels = "auth-service" AND status != Backlog
ORDER BY updated DESC

A page built around a stable label survives your release cadence changing, your sprint numbering changing, and your fixVersion naming convention changing, none of which are rare events over a page’s actual lifetime.

Building a Jira Automation Rule That Creates Confluence Content

Jira automation includes a native action that creates a Confluence page from a template when a rule fires, no code, free on every Cloud tier. A rule triggered by “Issue transitioned to Done,” scoped to a project and issue type, can create a page in a target space populated with smart values like the issue key and summary:

Trigger:   Issue transitioned to Done
Condition: Project = PROJ AND Issue Type = Story
Action:    Create Confluence page
           Space: ENG
           Title: {{issue.key}} - {{issue.summary}}
           Template: "Feature Summary"

Limitation: this creates a new page every time the rule fires.
There is no native action that updates a page that already
exists, so a ticket that reopens and closes again either
duplicates the page or, with a duplicate-check condition added,
silently does nothing.

For more control over what actually gets written into the page (not just a templated title and a couple of smart-value fields), the alternative is a “Send web request” action posting to the Confluence REST API directly. Jira Automation Rules: A Practical Guide for 2026 covers that route in depth, including the limitation that matters most: the Confluence API only supports full-page-body replacement, so a rule that writes to a page programmatically overwrites everything on it, including whatever a human wrote there by hand.

Where Native Jira Confluence Integration Hits a Wall

Here’s the honest version, because every one of these features is genuinely good at what it does and genuinely stops at the same line. Smart links show current status but only refresh on view. The macro shows current ticket lists but doesn’t touch the prose paragraphs around the table it’s embedded in. Automation rules create pages reliably but have no concept of “this page already exists, update the outdated section.” None of the three detects that a paragraph explaining how a system works is now wrong because the ticket that changed the system already closed.

That gap (a page that exists, was accurate once, and drifts as the system evolves after creation) is the specific problem native features weren’t built to solve, and it’s not a knock against them. A JQL macro and a webhook are the right tools for surfacing and creating content. Neither is designed to read an existing paragraph, understand what it claims, and know it’s now wrong. Documentation Drift Solutions That Actually Stick covers that problem directly, and it’s genuinely a different problem than integration.

A Realistic Setup Order for Teams Starting From Zero

We’ve seen teams try to configure all four layers in one sprint and abandon half of it. A more durable rollout goes in order of effort versus payoff. First, confirm smart links are working (they usually already are, since it’s default behavior once sites are connected). Second, add the Issues/Filter macro to your five highest-traffic Confluence pages, the ones people actually open weekly, not your entire space. Third, build exactly one automation rule for your highest-volume ticket type, and watch it run for a sprint before adding a second. Fourth, revisit after a quarter and check honestly whether pages are still drifting despite the native layer being fully configured; if Keeping Confluence Up to Date: Maintenance Strategies That Hold Up describes problems you still recognize at that point, that’s the actual signal you’ve outgrown what native features can do, not a reason to have skipped configuring them first.

Common questions about Jira Confluence integration

Do you need a paid app to connect Jira and Confluence?

No. Smart links, the Jira Issues/Filter macro, JQL-driven tables, and basic automation rules that create Confluence pages from templates are all native and free on every Jira Cloud tier, including the free tier. Paid apps become relevant when you need a native feature’s job done differently, most commonly updating existing pages rather than only creating new ones.

A smart link previews a single issue: paste a URL, get a status card, no configuration. The Jira Issues/Filter macro embeds a JQL-driven table of many issues and requires writing or selecting a filter. Use smart links for one-off references inside a paragraph and the macro for anything that should read as a list or a living status table.

Can Jira automation rules update an existing Confluence page instead of just creating a new one?

Not through the native “Create Confluence page” action, which only creates new pages from a template. A “Send web request” action can call the Confluence REST API directly, but that API only supports replacing a page’s entire body, not editing a specific section, so any hand-written content on the page gets overwritten in the process.

No. The card reflects the issue’s status as of the last time the Confluence page was loaded, not a live push update. Reloading the page refreshes it. For pages checked routinely this is rarely noticeable; for pages consulted only during incidents, it’s worth knowing the card can be several minutes behind the actual ticket state.

Every native integration layer between Jira and Confluence is built to create or surface content, not to revisit it. That’s not a gap in the implementation. It’s a different problem than the one smart links, macros, and automation rules were designed to solve, and knowing the difference is what tells you whether you actually need more than what’s already turned on.

The teams that get the most out of native integration are the ones who configure all four layers deliberately, in order, before deciding anything is missing. Most give up after smart links, notice a page went stale six months later, and blame the platform for a gap they never actually tested the rest of the toolkit against.