Every guide published on this site, listed newest topic first. Each one answers a single question end to end rather than surveying a subject, and each is written from delivered Atlassian work rather than assembled from other people’s posts. There are 8 so far, and more are being written.
What does Rovo actually do in Jira? • What is the difference between Rovo MCP, Rovo agents and Rovo in automation? • What happens when a Rovo request needs a configuration change? • Can Rovo read configuration it has no way to change? • When is Rovo the right answer on its own? • What you shouldn’t expect Rovo to do
Rovo works on the contents of your Jira, not its configuration. As of 15 August 2026 Atlassian publishes fourteen Jira tools for its MCP server, all of them operating on work items. None creates or updates a custom field definition, screen, workflow, permission scheme, request type, board or automation rule.
What is actually inside a GDPdU export? • Why does one question about it take so long? • Keep working where your auditors are • How does the GDPdU agent work? • What are the security measures for the GDPdU agent? • What can it not answer?
The setup is the cost, not the question. Importing and field-mapping a whole accounting export to answer one thing, then splitting anything complicated into separate queries and reassembling them by hand, is why most questions an auditor thinks of never get asked at all. This is what a GDPdU export holds, how the agent answers against it inside the engagement, and what keeps the records in Germany.
How can Jira Service Management be used in an audit? • What has been built for German audit firms so far? • Where does the client’s data actually sit? • When does this not pay for itself?
An audit engagement is a request cycle against a deadline, which is the one shape Jira Service Management is unambiguously good at. The audit-specific parts sit on top of it: proving independence before the mandate is accepted, opening a new year without disturbing the closed one, and asking the questions that belong to this audit type rather than a generic set. This page separates the configuration from the build work.
What is Forge? • When to choose a Forge app? • When to choose a Marketplace app? • Forge development by a 3rd party? • The honest case against building
Build a Forge app when the requirement is narrow, specific to how you work, or priced against a Jira far larger than the group who uses it. Buy from the Marketplace when the problem is a whole category of work other companies need in the same area. The comparison itself is misnamed: most Marketplace apps are Forge apps too, and the real choice is between somebody else's product and one that lives only in your site.
How much of this can you solve without writing code? • When does a requirement actually need custom code? • Should you configure it, buy it, or build it? • When is building the wrong call? • What does a delivered Forge app look like?
A Forge app earns its place only where configuration genuinely cannot reach the requirement, and most requirements that arrive sounding like code turn out not to be. This guide runs the decision in that order: what Jira already does, what a private app buys that a Marketplace licence does not, and where an app’s data ends up living. It closes on the cases where building is the wrong answer.
What can you cross off the migration plan on day one? • What stays behind even when the copy succeeds? • Which apps can you migrate, and what happens when it’s not possible? • Where do your custom scripts go? • What happens to your users, their emails and sign-in? • Will your data volume block the move? • How do you test the migration? • Should you move everything, or decide first what moves? • Can you run the migration yourself?
Copying the data is the part Atlassian already solved — free, automated, done. Some sites can move to Cloud in a weekend on that tooling alone; the rest carry what the assistant won’t touch: apps without a path, DC scripts, tangled user directories, sign-in that has to keep working. Find out which kind of site you have, and what to do about it either way.
What can Jira automation do on its own? • Where does do-it-yourself automation stop? • What happens to thirty rules nobody owns? • How is a designed rule structure different from recipe templates? • Who should not hire an automation consultant? • What does this look like in practice?
Jira’s automation engine handles far more out of the box than most teams use, so the value of a consultant is not knowing which action to pick. It is rule design that survives contact with a real process: where do-it-yourself rules stop, what becomes of thirty rules once nobody owns them, and how a designed structure differs from stacked templates. There is also a section on who should not hire anyone for this at all.
What Monday is actually good at • Which Monday product fits the work • Where Monday is weaker • Where Monday usually comes out cheaper • What a build looks like in practice • When a spreadsheet was already fine
Usually yes. Monday started as a work OS and modelling work is still what it does best, so a long process with dependencies, timelines and cross-board reporting is ordinary ground. Pick the right Monday product first. The three real limits are automation depth, boards that get harder to work in as they fill, and the fact that Monday can show a rule but not enforce it.