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.
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.
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
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.
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
We used Atlassian Forge and the rovo:agent
module. Here are some highlights:
REST APIs:
/rest/api/3/user/groups
/rest/api/3/project/{key}/role
/rest/api/3/group/member
Required scopes:
read:jira-user
read:jira-work
manage:jira-configuration
Everything was deployed through the Forge CLI.
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.
NOTEThis 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. |
Akhand Pratap Singh
Systems Integration Advisor
NTT Data
Pune
30 accepted answers
3 comments