Users & Roles

Bulk Role Manager

Assigning a user or group to a space role across 50 spaces one at a time is tedious enough that most admins either skip it or write a script. The Bulk Role Manager handles it in a 4-step wizard.

A common scenario: a new team lead joins, and they need Developer role access across all 30 of their team's spaces. Without this tool, that's 30 separate "Project Settings > People" operations. With the wizard, it's done in about 2 minutes.

1. Select Spaces The space list loads with the same search and filter controls as the Scheme Manager — filter by type, style, or search by name. Select individual spaces or use Select All Matching to grab all spaces that match your filter. Team-managed spaces can be selected but will be skipped during execution (same API limitation as scheme management — they don't support bulk role assignment via REST API).
2. Select Role A dropdown lists all global Jira roles — Administrators, Developers, Viewers, Service Desk Team, and any custom roles you've created. Team-managed-specific roles are filtered out since they don't exist at the global level.
3. Select Members Two tabs: Users and Groups. In the Users tab, type a name in the search box and pick from the results — it searches your Jira user directory. For each user you add, the app shows their current role status across your selected spaces: "In all 12 spaces" (already assigned everywhere), "In 7 of 12" (partial), or "Not assigned." This preview tells you what the operation will actually change before you confirm it. You can add multiple users and remove any with the X button.
4. Confirm & Execute The review screen shows the role, selected spaces, and members. Team-managed spaces show as Skipped. Click Execute to run it. A progress bar processes each space and shows success or failure per space. "Already a member" is treated as success — it won't throw an error if a user already has the role in a given space.

Role Membership Report

A read-only auditing tool — it doesn't change anything, it just shows you who has what roles and how they got them. There are three search modes.

By Space

Select a space from the dropdown and see all its roles with every member listed under each. The key column is Assigned Via — it shows whether each member's access is Direct (explicitly added to the space role) or via a group name (and which group). App and bot accounts are automatically excluded from the results since they're usually not relevant to access audits. Use this when you want to answer "who has admin access to this space, and how did they get it?"

By User

Search for a user and see every space and role they have access to across the entire instance. The scan works in batches with a progress bar — on a large instance with thousands of spaces it takes a couple of minutes. The Assigned Via column shows direct vs. group-based access for each space. This is the "show me everything this person can see and do" query, and it's what you run before offboarding someone to understand the scope of their access.

By Group

Search for a group and see all the spaces and roles that group is assigned to. Useful for understanding the blast radius before changing a group's membership — if you're about to add 50 people to a group, this shows you exactly what spaces and roles they'd gain access to.

User Management

User Management loads your Jira user directory and adds the information you need for lifecycle management — product access, last active dates, group memberships — then gives you bulk actions to act on what you find.

Loading users

Click Load Users first. This fetches the basic list — names, emails, account type, active/inactive status. It's fast even on large instances — under 10 seconds for most. Once loaded, you'll see the table with all users. At this point there's no product access or last-activity data yet.

Click Load Access & Activity to add that data. This is the slow scan — it checks every user's group memberships, product access, and last login date per product. It runs in chunks of 100 users with a progress bar showing where it is. The table updates as each chunk finishes, so you're not waiting for the whole scan before you can start looking at results.

User types

The table shows three account types. Atlassian accounts are regular human users with Atlassian accounts — the vast majority. Customer accounts are Jira Service Management portal users (they don't have full Atlassian accounts, just portal access). App accounts are service/bot accounts created by Forge apps or integrations. App accounts are hidden by default since they're usually not what you're managing — toggle them on if you need to see them.

Filtering and searching

Search is instant and client-side once data is loaded. The Activity filter is particularly useful — you can find all users who haven't logged into Jira in the last 90 days, or filter for "never logged in" to find accounts that were created but never used. The App Access filter shows who has access to specific Atlassian products. Combining these filters is how you build your list for a user access review.

User detail panel

Click any user's name to expand their detail panel on the right. It shows their group memberships, product access per product (with access level), teams, and last active date per product. This is the "tell me everything about this person" view — useful before making decisions about suspending or removing access.

Bulk actions

Group Management

Group Management requires the Organization API key configured in Settings. It uses the Atlassian Admin API v2, which also requires the Org ID and Primary Directory to be set. The Primary Directory is auto-detected when you save your API key, but you can change it in Settings if you have multiple directories.

What the group list shows

Once configured, the group list loads with: group name, member count, type (Local or External/SCIM), and whether the group is editable or read-only. External groups managed by Azure AD, Okta, Google Workspace, or another identity provider via SCIM are automatically detected and marked read-only — you can see their members but can't change them through the app. Changes to SCIM-managed groups have to go through the identity provider; attempting to edit them here will fail.

Bulk add and remove members

Select one or more local groups, search for the users you want to add or remove, and apply. The app processes each selected group in sequence and shows a result per group. This is useful for things like adding a new hire to their team's groups, or cleaning up a departing employee's group memberships in bulk before deactivating their account.

Group usage analysis

Before deleting a group, run Check Where Used. It scans permission schemes, notification schemes, global permissions, issue security schemes, space roles, saved filters, and dashboards to find everywhere the group is referenced. The results show you exactly what would be affected — which permission schemes lose a member, which spaces would lose role access, which filters become unshared. This is not a trivial check to do manually; it takes minutes in the app and would take hours by hand.

Once you've reviewed the usage impact, if you still want to delete the group, select it, confirm in the dialog (which shows the usage summary), and delete. The deletion is immediate and irreversible.