Cases and Jira sync
A remediation case is a unit of work scoped to a single owning team. UVM generates cases automatically: each plan's affected assets are partitioned by their owning organizational unit, producing one case per unit — plus an Unassigned case for assets with no owning unit. What you create is the Jira ticket for a case. Each case carries:
- The plan's AI-generated remediation summary and step-by-step instructions
- The list of affected assets in that unit's scope
- The risk reduction the team will deliver by completing the case
Tickets are created and updated through Data Out, JupiterOne's outbound integration surface — not through the inbound Jira integration you may use to ingest projects. Each organizational unit's routing configuration names its owner and its ticketing workflow, and that workflow instance determines the Jira project and issue type the team's tickets land in.
Case status is derived, never set
A case reflects the lifecycle states of its constituent vulnerabilities — you never set a case status directly. Work the vulnerabilities, or work the ticket, and the case follows:
| Case status | When |
|---|---|
| Open | At least one constituent vulnerability is Open, or the constituents are in a mix of states |
| Awaiting verification | Every constituent vulnerability is Awaiting verification |
| Resolved | Every constituent vulnerability is closed |
When a case's vulnerabilities share an outcome, a closure reason is derived from it: a case whose vulnerabilities are all awaiting verification reads as Patched, and a resolved case derives Compensating control in place, Accepted risk, or False positive. Vulnerabilities resolved as Fixed or Non-exploitable, or a mix of resolutions, yield no closure reason — which matters for the outbound sync below.
Jira sync, in both directions
Outbound — case to ticket. Case progress updates the linked Jira ticket. An open case keeps the ticket in progress, and a case that moves to awaiting verification adds a comment rather than transitioning the ticket, because the fix is not yet confirmed. A resolved case transitions the ticket to done with the matching resolution when it has a closure reason — Accepted risk, Compensating control in place, or False positive. A case resolved by fixes, or with mixed resolutions, instead posts a comment asking the assignee to close the ticket: an automatic close with no resolution would echo back through the inbound mapping and reopen the case. A case that reopens from resolved transitions the ticket back to in progress.
Inbound — ticket to lifecycle states. When a linked ticket closes in Jira, its resolution translates into a proposed transition for the case's constituent vulnerabilities:
| Jira resolution | Proposed lifecycle state |
|---|---|
| Fixed, Patched, or Done | Awaiting verification — the close is a claim, and the vulnerabilities close as Fixed when scanners confirm |
| Won't Do or Accepted Risk | Accepted risk, with a 90-day expiry |
| Not Exploitable | Non-exploitable, with a 180-day expiry |
| False Positive | False positive |
| Mitigated | No change — a mitigation requires a linked control, which a ticket cannot name. When the vulnerability already carries a stored decision, the conflict is flagged in the Inbox. |
| Any unmapped resolution | No change — the closure is ignored until you add the resolution to the status mapping |
Ticket closures never override a decision a person made in JupiterOne. A conflicting closure is refused and surfaces as a Ticket disagreement in the Inbox, and reopening a ticket only withdraws a claim the ticket itself made — it never revokes a settled decision.
Set up the sync
The sync is delivered by Data Out workflow instances, so setup spans a few surfaces. Work through them in this order:
- Create a Jira connection. From Integrations > Data Out > Connections, authorize your Jira workspace with an Atlassian site, account email, and API token. See Configure a Jira connection.
- Create a workflow instance for each Jira project and issue type your cases route to. The instance is what actually writes and updates tickets — creating a ticket for a case requires selecting an instance, so no instance means no ticket. See Create an instance.
- Confirm case routing. Each organizational unit needs an owner and a ticketing workflow in its routing configuration — the selected workflow instance determines which Jira project and issue type the team's tickets land in.
- Configure the status mapping for each project and issue type (below).
- Verify with a test round trip before relying on the sync — see the warning below, and Test an instance.
Configure the status mapping
You configure the mapping between case statuses, Jira statuses, and Jira resolutions per Jira project and issue type, so the sync speaks each project's workflow. Both directions are covered by the same mapping: which Jira status and resolution each case status writes outbound, and which lifecycle state each Jira resolution proposes inbound.
JupiterOne cannot validate your Jira workflow at configuration time. If a mapped transition is not allowed in the target project's workflow, the update fails silently on the Jira side — the ticket stays put while the case in JupiterOne moves on. After configuring a mapping, verify it with one test round trip: create a case, resolve its vulnerabilities, confirm the ticket transitions with the expected resolution, then close a ticket in Jira and confirm the proposed state appears in JupiterOne.
Troubleshoot sync failures
When a ticket did not appear, did not transition, or a closure did not reach JupiterOne:
- Check the instance's Jobs table first. Every outbound delivery is recorded on the Data Out instance's detail page with status, timestamps, and per-job error messages. See Troubleshooting Data Out.
- A resolved case whose ticket stayed open is often by design: a case resolved by fixes posts a comment asking the assignee to close the ticket rather than transitioning it (see the outbound direction above).
- A ticket that will not transition usually means the mapped Jira status is not reachable from the ticket's current status in that project's workflow — fix the mapping or the Jira workflow, then re-test.
- A closure that made no state change may be an unmapped resolution (ignored until you add it to the status mapping for that project and issue type) or a conflict with a decision made in JupiterOne (surfaces as a Ticket disagreement in the Inbox when the vulnerability carries a stored decision).