If you’ve ever worked with Jira, you already know this story.
A project lead messages you and says, “Hey, John can’t access the board for Project ABC. Can you check what’s wrong?”
It sounds simple, but as Jira admins or project owners, we know this kicks off a chain of manual steps:
-
You search for the user in Jira’s user management
-
You check which groups they belong to
-
You open the project’s permission scheme or roles
-
You compare which groups are granted access
-
You try to figure out what’s missing - then you reply back and possibly raise a request to fix it
This kind of task is low-value, high-frequency. It doesn't require deep expertise, but it eats up time - for both the project lead and the Jira admin. And it happens all the time.
We wanted to change that.
The Goal
We set out to build something that would help project leads answer this question on their own:
“Why can’t this person access my project?”
They didn’t need admin access. They didn’t need to manage permissions. They just needed a way to see the gap and act on it.
So we built a Rovo Agent using Atlassian Forge.
What the Agent Can Do
The Rovo Agent sits inside Jira and listens for natural language queries like:
-
“Why can’t John access Project Alpha?”
-
“Which groups is John part of?”
-
“Is John in the jira-software-users group?”
-
“Which projects does the marketing-team group have access to?”
It then replies with real-time data, like:
Priya is not a member of any group that has access to Project Alpha.
Required groups: jira-software-users, finance-team
Missing for Priya: finance-team
No back-and-forth. No admin intervention, project leads can also use this Rovo Agent
How It Works
At a high level, here’s what the agent does when someone asks a question:
-
Understands the intent
It parses the message to identify whether the user is asking about group membership, project access, or permissions.
-
Looks up the user
It searches for the user using either their email or name (with fuzzy matching in case the name isn't exact).
-
Fetches the user's group memberships
It uses Jira’s REST APIs to retrieve the list of groups the user is in.
-
Checks the project’s roles and permissions
It identifies which groups have access to the given project by inspecting the project roles.
-
Compares and highlights missing groups
Finally, it identifies which groups the user lacks - and shows that clearly in the response.
What Made It Work
Some key things we built in:
-
Pagination support to deal with large groups that return partial results
-
Support for multiple users with the same name, so we don’t make wrong assumptions
-
Real-time processing only: No data is stored, which kept it secure and compliant
Tech Stack and Permissions
We used Atlassian Forge and the rovo:agent module. Here are some highlights:
-
REST APIs:
-
Required scopes:
Everything was deployed through the Forge CLI.
The Impact
- Project leads were able to resolve permission issues on their own in seconds.
- Jira admins spent less time answering the same types of access questions.
- Overall, we’ve saved hours of admin effort each week, improved response time for users, and made Jira a little less of a black box.
What's Next
There’s more we want to do. Some ideas we’re already working on:
-
If the agent detects missing access, offer to raise a Jira Service Management request automatically.
-
Extend the agent to support Confluence space access as well.
-
Add reporting features to show which groups have the most access across projects.
NOTE
This Rovo Agent wasn’t built for show; it came from a real problem we were facing every day. And it solved that problem better than we expected.
If you’re dealing with access issues, repeated permission checks, or just want to empower your team to be more self-sufficient inside Jira, I highly recommend exploring what Rovo Agents can do.
|
