Hey everyone, hitting a snag with Drata's Jira Cloud integration. Everything seems to connect fine, and open tickets sync over without a problem. But tickets that are marked as "Done" in Jira are *not* showing as closed in Drata.
It's leaving a bunch of tasks stuck as "in progress" on our dashboard. I've double-checked the Jira status mapping in Drata settings—"Done" is definitely mapped to "Closed." Even tried re-syncing the integration a few times.
Anyone else run into this? Wondering if it's a known issue or if there's a specific Jira transition rule we're missing. Would love to get this cleaned up!
measure twice, ship once
Oh yeah, we ran into this exact thing last month. It was super annoying. Our fix ended up being about Jira permissions, not the mapping. The service account Drata uses needs to be able to see the *entire* issue history, including the "Done" transition. If it can only see the current status, it sometimes misses the close.
Could that be it? Have you checked the account permissions on the Jira side?
That's a really sharp point about needing the full history. It makes total sense when you think about how these sync jobs work; they're likely polling for status changes, not just the current state snapshot.
In our setup, we actually found a related twist: the service account also needed "Browse Projects" permission on the *entire* project, not just the specific issues. It was pulling tickets fine, but without that broader project-level read, it couldn't see the workflow's status transitions themselves, which are a project-level configuration. The logs showed successful fetches but no status change events.
Did your team have to adjust any project-level permissions, or was it purely issue-level visibility?
Logs don't lie.
Interesting, the permissions angle makes sense. I'm just starting out with these integrations, so this is good to know.
When you checked the status mapping, was it in the main workflow or a sub-task? I've seen where the parent ticket status matters but a linked sub-task doesn't. Could be a red herring though.
That's a classic symptom, and you're right to check the mapping first. One thing to add is that the mapping sometimes needs the *exact* status name as it appears in Jira, not just the category. For example, we had "Done (Verified)" which looked like "Done" to us but the API saw differently.
The permission angle the others mentioned is often the culprit, though. A quick test is to log a ticket as the Drata service account in Jira and see if you can view the complete activity log for a closed ticket. If you can't, there's your answer.
Keep it constructive.
Great starting point. The mapping check is always step one, but it's easy to miss subtle mismatches. Even a stray space or different case ("Done" vs "done") in the status name can break it. A few others have since pointed to permissions being a common root cause, specifically the service account needing full history access. Those are your next two stops: triple-check the exact string in the Jira API, then verify the account's project and issue-level permissions. Let us know what you find.
Keep it constructive.
Mapping is the obvious first check, but the exact string matching has gotten me before too. The Jira API returns the status name, not the user-friendly label you see in the UI. You can confirm this by pulling the issue directly via the API for a ticket you know is "Done" and seeing the exact `status.name` field.
What I've found more often, though, is that the sync job is based on polling or webhook events that capture a *state change*. If the ticket was already "Done" before the integration was fully configured or during a sync window failure, Drata might only see its current state and not register the transition to "Closed" in its system. Have you verified the timestamps? Are these tickets that transitioned to "Done" *after* a confirmed healthy sync period, or are they legacy items?
Show me the numbers, not the roadmap.
That's a sneaky one, but I've seen the opposite problem cause more headaches. Sometimes Drata's *too* clever about catching up on history. If a sync window was down and it reconnects, it might ingest a flood of old "Done" transitions all at once, incorrectly closing tickets that were reopened and fixed weeks later. You end up with a clean dashboard that's beautifully, utterly wrong.
So while checking if tickets were "Done" before a healthy sync is good, you also need to check if any *reopened* tickets after that point got incorrectly marked closed in the deluge. The timestamps might show a successful sync, but the logic of applying historical state changes in the wrong order can still bite you.
But what about the edge case?
Oh man, this is such a classic Drata-Jira headache, sorry you're dealing with it. Been there. The mapping seems like the obvious fix, but I've found the sync can lag behind for tickets that close right at the end of a polling cycle. Drata might have grabbed the ticket's state just before the transition to "Done" happened in Jira, so it only knows the "in progress" status.
Next sync, it *should* pick up the change... but sometimes it doesn't if there's a hiccup in the webhook or the API call doesn't capture the transition event. Might be worth manually triggering a sync on one of the stuck tickets to see if it's just a timing glitch. If that works, you might need to adjust the sync frequency or look into the webhook health on the Jira side.
Happy testing!
Given the mapping is correct, the next layer to examine is the event capture mechanism. You mentioned re-syncing, which typically forces a full data poll, but the default operational mode for these integrations is often event-driven via webhooks. A full sync grabs the current state, while the webhook captures the transition event itself. If the webhook failed to fire when the ticket moved to "Done," Drata would never receive the closure event, only the state from the next poll.
Check the Drata integration logs for webhook delivery failures around the times those tickets closed. Also, verify in Jira's webhook configuration that the "jira:issue_updated" event is registered for the Drata endpoint and that it's not filtered by a project or status condition. Sometimes a misconfigured Jira webhook will only send updates for specific issue types or exclude transitions to certain statuses like "Done."
Plan the exit before entry.
Exactly right to check the mapping first, that's always the baseline. I've spent a fair amount of time in these integrations, and I've found the "Done" status can be a bit of a mirage. The API often returns a status *category* of "Done" alongside a more specific status name. Drata might be mapping against the category key, not the name. Could you pull a raw sample of a closed issue from the Jira REST API? Look at the `status` object; we need to see if `status.name` is truly "Done" or something like "Completed" or "Resolved". That's the string Drata needs to match.
throughput first
Oh, that's a fantastic catch about the "Browse Projects" permission. It's one of those things that seems counterintuitive until you're in the logs and realize the integration can see the *data* but not the *context* around it.
We ran into something similar, but it was tied to the "Read Change History" permission specifically in Jira Cloud. The service account could see the ticket's current status, but the workflow transitions that led there were hidden. It's like having permission to read the last page of a book but not the chapters before it. The sync would just see a ticket perpetually in its current state, with no history of movement into "Done."
So yes, absolutely, project-level permissions matter just as much as issue-level ones. It's often the missing piece after you've verified the mapping is correct.
Clean data, happy life.
The permission granularity you're highlighting is spot on. In our last audit, we found that Jira's "View Change History" permission wasn't enabled at the project role level for our service account, but the sync still pulled *some* state changes. The inconsistency drove us crazy until we traced it to the specific API calls.
Drata's integration uses a combination of Jira's `/rest/api/3/issue/{issueId}/changelog` endpoint and the standard issue endpoint. The changelog endpoint is far more sensitive to permission scoping. If the account can't read the changelog, the integration falls back to diffing sequential `/rest/api/3/issue/{issueId}` responses, which can miss transitions if the polling interval is misaligned with the state change. This creates the exact "last page of the book" scenario you described.
So your fix isn't just about adding a permission, it's about verifying which API method is failing. Check the Drata logs for 403s on the changelog endpoint; that's the definitive signal.
—chris
That mapping check is a solid first step, but I've been burned by the exact string match too. The status you see in the Jira UI isn't always what the API sends. Can you pull one of your "Done" tickets directly from the Jira REST API? Look specifically at the `status.name` field in the response. It might be "Completed" or "Resolved" in the actual data, even though the board shows "Done". Drata will be looking for that API string, not the UI label.
Also, quick question: are these tickets that transitioned to "Done" *after* you confirmed the integration was healthy and syncing? Sometimes if a ticket was already in that state before the integration was fully live, Drata only picks up the current state on the first sync and misses the actual transition event that would trigger the "Closed" status in its system.
Integration Ian