Issues integration
Jira and Pacia
Jira is what unlocks the delivery and QA half of Pacia. It is also the integration where getting the configuration right matters most, because every Jira site has its own vocabulary and a guess is not a small inaccuracy — it silently changes the number.
What Pacia reads from Jira
Sprints, boards, epics and issues, with their full changelogs
Issue links, including those written by Xray and similar add-ons
Statuses, resolutions and issue types, for the mapping step
Story points, where you identify which of your custom fields is the real one
Connecting it
Create a Jira API token 2 min
Generate an API token for a read-only account in your Atlassian settings.
Connect and select projects 3 min
Add the site and token in Providers, then choose which Jira projects each Pacia team maps to.
Confirm the mapping ~10 min
Pacia reads your site and proposes how statuses map to phases, which issue types are genuine defects, which link types indicate a defect relationship, and which resolutions mean "not really a defect". Somebody who knows your process confirms it.
Delivery sync runs hourly
A full sprint and epic pass costs roughly 1.6% of one hour’s Jira API quota. Pages state when they were last read rather than implying live data.
Limits, stated up front
Every integration page on this site lists what the integration does not do. Finding that out during a trial is worse for both of us than finding it out now.
Read-only. Pacia never writes to Jira — nothing on your board changes because you connected it.
Jira Cloud. The mapping step is required before defect and QA rules produce numbers; until it is done they show as unconfigured rather than as zero.
Xray and Zephyr are read through the Jira issues and links they write, not through their own APIs, so add-on-only test execution detail is not pulled through.
Unset custom fields are null-checked explicitly rather than coerced — otherwise every unestimated issue stores as a real zero and reports 100% estimate coverage over half-estimated work.