# Ticketing URL: /integrate/ticketing Open issues in Jira, ServiceNow or GitLab from alert rules and automations. Each issue holds the case link, so the work is tracked where your team works while the evidence stays in Foxborne, and Jira Data Center syncs status back. A finding needs an owner, and your tracker already assigns owners. Foxborne opens the issue with the case link inside it, so the discussion happens in the tracker while the evidence stays behind your identity provider. The **Ticketing** group on the **Destinations** tab of **Integrations** holds the trackers. The console describes it as "Issues that hold the case link, so work is tracked where the team already tracks it." ## Choose a tracker [#choose-a-tracker] | Tracker | Protocol choices | Target field | Air-gapped | | --------------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------- | ---------------------- | | Jira Data Center | REST API v2, POST /rest/api/2/issue | **Project and issue type** | Yes, until end of life | | Jira Cloud (Atlassian Government Cloud) | REST API v3, OAuth 2.0 (3LO) | **Project and issue type** | No | | ServiceNow (GCC, NSC) | Table API, POST /api/now/table/incident; Event Management, POST /api/global/em/jsonv2 | **Table or event source** | No | | GitLab self-managed | Issues API v4, POST /api/v4/projects/:id/issues; Alert HTTP endpoint, alerts/notify.json | **Project** | Yes | Jira Cloud and ServiceNow sit outside the enclave, so they show **Needs a network path out**. They take L0 unless your program authorizes them for CUI. **Jira Data Center** authenticates with a personal access token sent as a bearer token. It is the one tracker with status sync back. Atlassian stopped selling Data Center to new customers on 30 March 2026, and existing customers can buy until 30 March 2028. End of life is 28 March 2029, when the products turn read-only. **Jira Cloud (Atlassian Government Cloud)** uses OAuth 2.0 (3LO). Atlassian Government Cloud reached FedRAMP Moderate in March 2025. On 23 September 2026 Atlassian moved its IL5 submission to July 2028 and its FedRAMP High submission to January 2029. **ServiceNow (GCC, NSC)** authenticates with OAuth 2.0 or a web-service-only integration user. Event Management takes events from a user with the `evt_mgmt_integration` role, and `message_key` deduplicates them. **GitLab self-managed** opens issues with a project access token, or posts to the project's alert HTTP endpoint with its key as a bearer token. GitLab offers that endpoint in Free, Premium and Ultimate, on self-managed and Dedicated. ## What Foxborne sends [#what-foxborne-sends] At L0, the default, an issue carries the rule, the severity, the vehicle alias, the UTC time and the case link. The link opens the case only for people who can sign in to your deployment. No ticket carries L2: evidence moves only through [Export](/integrate/exports), with approval. In the example dataset, Jira Data Center received this issue for INC-0142. It answered `201 Created, REL-418 (id 48213)`. ```json title="Payload, as sent" caption="Example dataset: POST /rest/api/2/issue, L0" { "fields": { "project": { "key": "REL" }, "issuetype": { "name": "Task" }, "summary": "INC-0142: R4 Memory pressure, Critical", "description": "Foxborne case INC-0142. Highest alert R4 Memory pressure, Critical, UAS-04 at 14:32:01.204 UTC on 24 Sep 2026.\nCase: https://foxborne.hfr.internal/app/incidents/INC-0142", "labels": [ "foxborne" ] } } ``` The ledger records its idempotency key as the case, `case:INC-0142`. When the incident's status changes, Foxborne comments on the same issue, for example "Foxborne case INC-0142 is now In review." with the case link. Jira Data Center's **Sync back** reads "Issue status flows back to the case activity". ## Where tickets come from [#where-tickets-come-from] | Source | When | What the ticket adds | | ----------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------- | | R3 Failsafe entered | Any transition into failsafe while armed, routed to **Jira Data Center, project REL** in the example dataset | The case link | | A1 Sortie closeout triage | Any finding at the closeout is High | The case link | | A3 Repeat hardware fault | The same device fired in 3 or more of the vehicle's last 10 sorties | The sorties and timestamps | | A4 Case closure and retention | The case moves to Approved | The tag-manifest SHA-256 of the BagIt bag | In the example dataset, R3's route and A1 share one issue per case: REL-423 holds INC-0143. A3 deduplicates per device and closes its ticket after 10 clean sorties. [Automations](/integrate/automations) describes each automation in full. ## Before you start [#before-you-start] * An admin is available to turn on egress. Admins confirm with a hardware security key. * The deployment can reach the tracker. Jira Cloud and ServiceNow need a network path out. * The credential sits in your secret store: a personal access token, an OAuth client, an integration user or a project access token. * You know the project or table the issues go to. ## Connect a tracker [#connect-a-tracker] Go to **Integrations**. On the **Destinations** tab, select the tracker in the **Ticketing** panel, then **Set up** in its drawer. The example dataset's Jira Data Center destination uses these values: jira.hfr.internal:443 REST API v2, POST /rest/api/2/issue Project REL, issue type Task secretsmanager:foxborne/int/jira-pat L0 Select **Send test**. For Jira, the test is an authentication check with no body: `GET /rest/api/2/myself` on Jira Data Center, or `/rest/api/3/myself` on Jira Cloud. A good token answers `200 OK, authenticated`. Select **Save**, then the switch in the **Egress** column and **Turn on egress**. The audit log records **Configured integration** and **Enabled egress**, for example `L0 to jira.hfr.internal:443`. Go to **Alerts**, select **Edit** on R3 and tick the tracker's route under **Delivers to**. A1 and A3 use the tracker once it is on. ## Check the result [#check-the-result] On the **Delivery ledger** tab, the issue appears as, for example, **Created REL-418 for INC-0142**. A status comment appears as **Comment on REL-418, INC-0142 in review**. The drawer's **About** row links the incident, the run, the alert firing and the automation run. On the incident, the **Activity** tab shows that A1 "opened REL-418 in Jira Data Center". ## Troubleshoot [#troubleshoot] **The test fails with an authentication error.** Jira Data Center takes the personal access token as a bearer token. Check the secret the **Credential reference** points to. **Status changes never come back to Foxborne.** Only Jira Data Center syncs status back. Jira Cloud, ServiceNow and GitLab receive issues in one direction. **The test to Jira Cloud or ServiceNow answers No route.** Egress is denied at the VPC, so your network team has to open a path to the host first. **ServiceNow refuses events.** The user posting to Event Management needs the `evt_mgmt_integration` role. **No issue opened after a finding.** A1 opens one only when a finding is High, and R3's route needs the tracker's egress on. Check the firing's **Delivered** section on **Recent firings**. ## Next [#next] * [Automations](/integrate/automations) covers A1, A3 and A4, which write to your tracker. * [Alerts](/integrate/alerts) routes R3 and sets the severities that decide when A1 opens an issue. * [Egress, data classes and the delivery ledger](/integrate/egress-controls) explains what L0 and L1 carry.