Jira
Sync Jira issues into your Naumu graph as nodes, with two-way write-back.
Jira tracks your team's work as "issues" — tickets for bugs, tasks, and features. Connect a Jira site to a Naumu space, and Naumu pulls those issues in as nodes (the items in your graph).
Each issue's fields become node attributes (its properties, like priority or status), and the relationships between issues, projects, and sprints become edges (the connections between nodes). The work your team tracks in Jira becomes part of the same graph you can ask questions of.
The connection works in three steps:
- An admin connects over OAuth — a standard sign-in flow that grants access without sharing a password.
- Naumu does a one-time import of your existing issues.
- From then on, Naumu keeps the graph in sync as work changes on the Jira side — and writes your Naumu edits back to Jira.
Connect a Jira site
Connecting is an admin task, and you do it entirely from inside Naumu — no command line, API key, or external setup required.
- Open the space you want to populate.
- Go to Settings → Integrations.
- In the Jira card, select Connect.
- You are redirected to authorize Naumu. Approve the requested access.
- You are returned to Naumu, which opens an import thread.
A few things to know before you start:
- You must be an owner or admin of the space. Naumu checks this before the redirect, so a connection is only ever bound to a space you can administer.
- A space connects to one Jira site at a time. If your account can reach more than one site, you'll be asked to pick which one this space syncs with before the import starts.
Atlassian allows only one Jira-to-Naumu connection per account. If the same account is already connected to another space, disconnect it there first.
How issues become nodes
After you connect, Naumu fetches your issues and proposes how to fit them into the space's schema — the set of node types your graph already uses. Each kind of source item becomes its own Naumu node type:
- Issues. Each Jira issue type (Epic, Story, Task, Sub-task, and so on) becomes its own node type.
- Projects and sprints become their own types, so issues can be grouped under them.
- Members become nodes that issues are assigned to.
The proposal is additive: it never removes or rewrites types you already have. And if a proposed type matches one in your schema by name, Naumu reuses the existing one instead of creating a duplicate.
Field mapping
Rather than copying every field word for word, Naumu maps the fields it imports onto a small, consistent set of node attributes and edges. Here's where each field lands:
| Source field | Where it lands in Naumu |
|---|---|
| Issue title | Node label |
| Issue description / body | The node's content |
Issue key (e.g. KAN-42) | A JiraKey attribute |
| Priority | A Priority select attribute |
| Status / workflow state | A Status select attribute |
| Labels | A Labels multi-select attribute |
| Created / updated time | The node's own created and updated timestamps |
| Project, sprint, assignee, parent | Edges to the related nodes |
Labels are free-form, so Naumu adds new label values to the schema as it encounters them rather than locking in a fixed list up front.
Tracking status and staying in sync
The connection doesn't stop at the first import. As issues change in Jira — a status moves, a new issue is created, a label is added — Naumu updates the matching nodes in near real time. As a backstop, a daily reconciliation pass double-checks everything, so nothing drifts out of sync if a live update is ever missed.
For Jira, the sync also runs the other way: edits you make in Naumu can be written back to Jira, keeping both sides aligned.
Disconnecting
Disconnect from the same Settings → Integrations panel. Disconnecting is a soft operation: it clears the access tokens and stops syncing, but the nodes you've already imported stay in your graph. If you reconnect the same site later, Naumu resumes syncing against those existing nodes rather than creating duplicates.