fabriclink

Every Jira change, landed in your Fabric tables.

Fabric Link mirrors issues, field history and service-management data from Jira Cloud into a mirrored database in your own Microsoft Fabric tenant. It reads from Jira and writes only to the workspace you authorise.

A field changes in Jira. Seconds later the same row updates in the mirrored table and the change lands in the changelog. Nothing is written back to Jira.

Jira holds the work. Fabric holds the analysis.

Most teams still bridge the two with brittle exports, shared spreadsheets, or warehouse jobs nobody owns. Fabric Link keeps a continuous mirror instead, so delivery and service data are queryable next to everything else in your tenant.

What lands in Fabric

Every table is a mirrored table in your workspace, queryable from the SQL analytics endpoint and Power BI. Names may vary by version.
Mirrored tables, their contents and refresh cadence
TableWhat is in it
jira_issuesOne row per issue with the fields you select
jira_changelogEvery field change with author and timestamp
jira_projectsProject keys, names and categories
jira_fieldsField definitions and types used for column mapping
jira_usersDisplay names and account IDs referenced on issues
jsm_sla_cyclesSLA cycles per issueRequires Jira Service Management
jsm_request_typesRequest types and their portal groupsRequires Jira Service Management
jsm_approvalsApproval decisions and approversRequires Jira Service Management

Control what you mirror

Configured from Jira admin. Nothing to deploy on your side.

Choose which Jira fields become Fabric columns

Pick exactly which Jira fields land in Fabric, globally or per project. An analytics starter pack covers the common reporting fields so you can start fast and tighten scope later.

Where it appears and its limits

Backfill field-change history from day one

Opt-in backfill crawls every issue's changelog, so field-change analysis starts from your project's first day rather than install day. Historical rows land in the changelog table ready for SQL or Power BI.

Where it appears and its limits

Mirroring status, watermarks and dead-letter replay

Per-table mirroring status, backfill progress, watermarks and a replayable dead-letter queue, all inside Jira admin so operators can see what landed and what needs attention.

Where it appears and its limits

How it works

Four steps from Marketplace to your first query.
  1. Step 1: Install on Forge

    The app runs inside Atlassian Forge. There are no servers, no middleware and no third parties in the data path.

  2. Step 2: Connect Fabric

    The setup wizard connects to your workspace with your own Entra service principal and provisions mirrored tables through Open Mirroring.

  3. Step 3: Keep tables current

    Live events, five-minute reconciliation sweeps, optional history backfill and hourly reference refreshes keep the mirror complete.

  4. Step 4: Analyse in Fabric

    Query the SQL analytics endpoint, build Power BI reports, or shortcut the tables into a Lakehouse.

Built for the security review

The full posture, scopes and subprocessors are on the security page.
Read-only from Jira
Forge scopes granted at install are read-only for work data. The app never writes to issues.
Read more
Your tenant, your credentials
Fabric writes use a service principal you create, consent to and rotate in your own Entra tenant.
Read more
Egress limited to Microsoft
The app can only reach Microsoft login, Fabric API and OneLake endpoints. Nothing else is on the allowlist.
Read more

Mirror Jira into Fabric on your terms.

Install from the Atlassian Marketplace, connect your Fabric workspace, and query issues within the hour.