Hi dlaborie Well, our current approach is a mix of event-driven automation, agent-assisted workflows, and human validation. We have not implemented one single, fully automated Jira → Dust → Jira loop for every ticket, but we do use several Jira-related workflows for ticket intake, troubleshooting, prioritisation, escalation tracking, coverage monitoring, reporting, and ticket creation from other business systems. For longer-running workflows, the Jira issue key is the main correlation ID. The agent first extracts the issue key from the incoming request or event, then retrieves the issue again before taking any action. Once the analysis is complete, it can add a comment, update a dedicated field, apply a label, or transition the issue, provided the relevant write permissions are enabled. We would typically use a dedicated status or label, such as AI_REVIEW or READY_FOR_VALIDATION, to make the workflow visible. We also kept write actions restricted during the initial rollout, test them in a limited project, and retain human validation for changes that could have a material operational impact. It is important to add safeguards against loops, so that an update made by the agent does not unintentionally trigger the same workflow again. Regarding knowledge enrichment, we do not treat every Jira ticket as an automatic knowledge-base entry. Jira remains the system of record, while Dust is used to make validated knowledge easier to find and reuse. A typical process is:
A ticket is resolved and the solution is validated by the relevant team.
The useful information is extracted into a structured format: problem, context, root cause, validated solution, scope, limitations, and links to the original ticket.
A reviewer checks the content and removes confidential, case-specific, or obsolete information.
The approved resolution is added to a curated semantic knowledge base or Space.
Support and operations agents can then search that knowledge when handling similar requests.
This approach allows us to build reusable FAQs from recurring Jira topics, while avoiding a noisy knowledge base full of unverified or duplicate answers. We would ideally use the Jira issue key as the document identifier, so that an updated resolution enriches the existing entry instead of creating a duplicate. At this stage, I would describe this as a curated enrichment workflow rather than a fully native, one-click Jira-to-Space synchronisation. The main principle for criteo is to keep Jira as the operational source of truth and Dust as the layer for orchestration, semantic search, and reuse of validated knowledge.
Hi dlaborie, Yes, we implemented Dust’s native Jira MCP, which includes 22 tools. I’m a contractor and a Dust admin at Criteo, and we have more than 1,500 members in our workspace, so we wanted to make sure the rollout was secure and scalable. Here’s how we approached it:
We connected Jira using personal accounts, ensuring that Dust mirrors each user’s existing Jira permissions.
We initially made the integration available to everyone, but restricted it to read-only actions, such as retrieving issues and project information.
We then created a restricted space for the Jira tool owners and enabled the tools that can create or update tickets.
Together with our Security team, we verified that actions performed through Dust generated the appropriate audit trail in Jira and that changes could be monitored.
Once Security approved the setup, we made the full set of tools available more broadly.
To make the experience smoother, we configured the tools as low, so agents could perform routine actions without requesting approval every time.
Jira has become one of the main tools in our workspace, and users really like it. We have not experienced any issues so far, and more than 359 agents are currently using it. Globally I've found native MCP hosted by dust itsefl way more reliable than the one developed by Atlassian
