> ## Documentation Index > Fetch the complete documentation index at: https://docs.borghq.io/llms.txt > Use this file to discover all available pages before exploring further. # Integrations Overview > Connect an issue tracker and keep findings in sync Integrations push Odin's security findings into the issue tracker your engineers already use, so remediation work sits in the same backlog as everything else. Manage them all from **Management > Integrations** in the sidebar. ## Supported trackers Odin pushes findings to five trackers. Each has its own connect flow and settings. Push findings into a Linear team Push findings into a Jira project Push findings to GitHub Issues Push findings to GitLab Issues Sync findings to Shortcut as stories GitHub and GitLab are dual-purpose: they also grant the repository access Mjolnir needs for whitebox pentesting. A connection can provide repository access without issue tracking, so turning on **Issue tracking** is a separate step on the integration's card. **Azure DevOps** is a repository-access connection for whitebox pentesting and [PR Reviews](/mjolnir/pr-reviews). It gives Mjolnir access to your Azure Repos but does not track findings as issues yet, so it isn't one of the trackers above. It can be connected either through delegated Entra OAuth or with a customer-owned service principal (workload identity federation) — see the [Azure DevOps integration](/platform/integrations/azure-devops) page for both connect flows. ## How findings reach your tracker There are three ways a finding becomes an issue in your tracker. * **Automatically**: with **Auto-create tickets** on, Odin opens an issue as soon as a finding is reported at or above your minimum-severity threshold. * **Per finding**: open any finding and click **Push to** your tracker. This works whether or not auto-create is on. * **In bulk**: the **Sync now** banner on the Integrations page creates issues for every finding that doesn't have one yet. **Shortcut is automatic-only.** There's no per-finding push button for Shortcut. Stories come only from auto-ticketing or **Sync now**. See the [Shortcut integration](/platform/integrations/shortcut) page. ## Syncing existing findings When you connect a tracker after findings have already been reported, those earlier findings have no external issue. The same gap appears if you turn a tracker on later or push some findings manually and leave the rest. Odin counts these gaps across every fully configured tracker and shows a banner at the top of the Integrations page. The banner has three states: If you have unsynced findings but no tracker is fully configured yet, the banner tells you how many findings are waiting and prompts you to finish setting up a connection. There's no sync button until a tracker is ready. Once at least one tracker is fully configured, the banner reports how many findings are missing an external issue and shows a **Sync now** button. Click it to create the outstanding issues across every ready tracker at once. After you sync, the banner confirms the jobs are queued. Issues are created in the background and appear in your tracker shortly. **Sync now** ignores the **Auto-create tickets** toggle. If you run trackers in manual mode, you can still use it to backfill issues on demand without turning auto-create on. A tracker counts as fully configured when its connection is active and its destination is set: a target repository for GitHub, a target project for GitLab, a team for Linear, a cloud site and project key for Jira, or a workflow for Shortcut. You can dismiss the banner. It stays hidden until the set of trackers with unsynced findings changes, then comes back when a new gap appears. ## Sync health If a connection develops a problem that blocks syncing — one only you can fix, such as the Linear team you selected being retired — Odin marks the tracker with a **Sync error** state on its card in **Management > Integrations** and explains what to correct. The status dot on the card turns red and reads **Attention needed**, so a broken tracker no longer looks healthy. Odin keeps the connection active and keeps trying: once you fix the underlying problem (for example, by choosing a new destination), the next finding that syncs clears the error on its own. Use [Sync now](#syncing-existing-findings) afterwards to backfill anything that didn't sync while the error stood. ## Status sync Once an issue is linked, status flows both ways: * **Odin to tracker**: when a finding's status changes in Odin, Odin moves the linked issue to match. That's the equivalent workflow state for Linear, Jira, and Shortcut, or an open/closed state plus an `odin:*` label for GitHub and GitLab. * **Tracker to Odin**: moving the linked issue to a different workflow state (or closing/reopening it, depending on the tracker) updates the finding's status in Odin. Your team can work entirely from the tracker and Odin stays in sync. **Fixed & Retested** is the one status the tracker can never set, whatever label or state name it uses. Only Borg staff can confirm it. See each tracker's page for its exact state, label, or workflow mapping. ## Assignee sync A finding's owner can travel with it. Assign a finding in Odin and its linked issue picks up the same person; reassign the issue in your tracker and the finding follows. Ownership stays consistent whether your team works from Odin or from the tracker. This rests on a mapping between your Odin teammates and their accounts in the tracker, so Odin knows which tracker user each teammate is. Set it up in the **Map your team** panel on the tracker's card in **Management > Integrations**, alongside the issue customisation settings. The panel lists every teammate next to a picker for their account in the tracker. Odin links people whose email matches automatically and suggests likely name matches for you to confirm, so most rows are filled in already and you just check them. Use **Refresh suggestions** after someone joins either side. GitHub doesn't expose member emails, so you link its rows by hand. Assigning or reassigning a finding sets the same person on its linked issue, for every tracker where the finding is linked and that person is mapped. Clearing the finding's assignee clears it on the tracker too. Reassigning the linked issue updates the finding's assignee to the mapped teammate. If the issue goes to someone who isn't mapped to an Odin user, the finding's assignee is left as it was. A mapped assignee also wins over the tracker's [default assignee](#customising-synced-issues): when Odin opens an issue for a finding that already has an owner, it uses that owner, and falls back to the default assignee only when the finding is unassigned or its owner isn't mapped. GitHub, GitLab, and Shortcut let an issue have several assignees; an Odin finding has one. Odin sets that single person on the issue, and reads the first assignee back when the change comes from the tracker. ## Customising synced issues Once a tracker is fully configured, an **Issue customization** panel appears on its card in **Management > Integrations**. It controls how a finding looks when Odin creates it as an issue. Leave any field unset to keep the tracker's default behaviour. These settings apply to every issue the tracker creates, whether it was opened automatically, pushed from a single finding, or backfilled with **Sync now** (Shortcut only ever creates issues automatically or via **Sync now**; see [above](#how-findings-reach-your-tracker)). A few controls are shared across every tracker: * **Default assignee**: pick a user, and Odin assigns every issue it creates to them, unless the finding already has a [mapped assignee](#assignee-sync). The list is drawn live from the connected tracker. * **Labels**: choose labels to apply to every synced issue, on top of the labels Odin already adds (such as `security` and the severity label). For Linear and Shortcut you can create a new label from the picker; for Jira you can type a label that doesn't exist yet. ### Priority mapping For Linear and Jira, the **Priority mapping** table lets you decide which tracker priority each finding severity becomes. Map Critical, High, Medium, and Low to the priorities your team uses, and leave a row unset to fall back to the tracker's default. Linear maps to its fixed Urgent/High/Normal/Low scale; Jira maps to whatever priorities your site defines. ### What each tracker offers The shared controls are joined by a few tracker-specific ones: | Setting | Linear | Jira | GitHub | GitLab | Shortcut | | ---------------- | ------ | ---- | ------ | ------ | -------- | | Default assignee | Yes | Yes | Yes | Yes | Yes | | Labels | Yes | Yes | Yes | Yes | Yes | | Priority mapping | Yes | Yes | — | — | — | | Initial state | Yes | — | — | — | Yes | | Project | Yes | — | — | — | — | | Issue type | — | Yes | — | — | — | | Component | — | Yes | — | — | — | | Milestone | — | — | Yes | — | — | See each tracker's page for the detail on its own settings.