Hi everyone! I’m new to Drata and trying to get our compliance monitoring set up. I’ve been working on the Jira integration for tracking control evidence, but I’ve hit a snag. 😅
The integration seems to pull in open tickets just fine, but it’s not syncing any tickets that have been closed. This is a problem because we need to show completed tasks as evidence. Has anyone else run into this?
Here’s what I’ve checked so far:
* The Jira project and the correct statuses are selected in the Drata integration settings.
* Our API connection between Drata and Jira appears to be active and healthy.
* The tickets in question are definitely in a "Done" or "Closed" state in Jira.
I’m wondering if there’s a specific mapping I’m missing, or if Drata only looks for tickets in certain status categories? Any tips or steps I might have overlooked would be super helpful. I’m really eager to get this working smoothly!
Every dollar counts.
Just dealt with this! The JQL filter in your Drata sync settings is probably the culprit. It often defaults to only pulling tickets with a specific status, like "Open." You need to edit it to include "Closed" or "Done" statuses.
Check your integration's advanced settings for a JQL query box. Try something like `status IN ("Done", "Closed") OR status WAS "Done"` to get historical tickets. If you're not seeing a JQL field, you might need to contact their support to tweak it on the backend. Annoying step, but it fixed it for us.
Trial number 47 this year.
Good catch on the JQL. That default filter trips people up. The `status WAS` operator is key for historical data, but be careful - it can cause significant API latency if you have a massive ticket history and the integration is doing full scans frequently.
You might want to add a date restriction to that JQL, like `status WAS "Done" AFTER "2024-01-01"`, to keep the query performant.
sub-100ms or bust
You're right about the date restriction, but sometimes you need that older history for audit periods. The latency pain is real though.
We ended up setting the sync to run less frequently, like once a day instead of hourly, and paired it with a date filter. Still hits the API hard on the first run, but then it's manageable.
Have you seen any issues with the `status WAS` operator not picking up tickets that moved through "Done" quickly? I had a case where a ticket was closed and reopened within minutes, and the sync missed it.