User tools
Copy someone's access to a new joiner, analyse your user base, and offboard a leaver properly.
Mirror User
What it does. Copies one person's groups and project roles to another person.
Use it when you get the request every administrator gets: “give the new person the same access as Marina”. Answering that by hand means checking every project role in every project.
Mirror User
Copy project roles and groups from one user to another.
| Mode | What it does | When to use it |
|---|---|---|
| Add (merge) | Adds the source person's groups and roles on top of whatever the target already has. | Almost always. This is the safe choice. |
| Replace (overwrite) | Removes the target from all current groups and roles first, then applies the source's. | Only when you want an exact copy and you know what the target currently has. This is destructive. |
After applying, the tool runs a Verification: it compares the two people and reports what matches, what is missing on the target and what exists only on the target. Read it. It is how you know the copy actually worked.
User Analysis
What it does. Analyses the CSV exports you can already download from admin.atlassian.com: the Managed Accounts export and the Users export. It validates the columns, tells you if one is missing, then produces a report.
User Analysis
Import Atlassian Admin CSV exports to analyse users, licences and generate recommendations.
- 1Download both CSVs from admin.atlassian.com: the Managed Accounts export and the Users export. The tool has the four-step instructions on screen, including which options to tick in the export dialog.
- 2Drop each file into its box. The tool validates the columns and names any that are missing.
- 3Set an Inactivity Threshold in days — minimum 30 — to decide what counts as dormant.
- 4Click Analyze.
What comes back is not a summary. It is a report you read top to bottom, and it is the part of the toolkit people underestimate.
- The headline row
- Product users, managed accounts, sites in the org, groups, org admins and Atlassian Guard billable seats — with a second line under each giving the number that qualifies it, such as how many of those accounts are disabled.
- Three alerts, each of which opens a list
- Ghost seat holders — active people holding billable seats who have never used any of them. Paid seats idle — the percentage unused past your threshold. Stale group members — suspended or deactivated users still sitting in groups, who regain access the instant somebody re-enables them. Click any of the three and the holder list loads at the bottom of the page.
- License Optimization — paid seats only
- The centre of the report: one row per product per site, with seats, active holders, a usage band breakdown, and a Reclaimable count. Filter by site and by product. A separate table lists what is included with your plans and therefore is not a seat you are paying for — Rovo, platform apps, features of a JSM tier — each with the reason.
- Who holds paid seats
- The people behind the numbers, with an onboarding note when a year's intake shows up as a wave of accounts that never signed in.
- Directory activity
- Last activity across the whole organisation directory, and how many accounts have never been active on any Atlassian product — usually provisioned-but-unused identities from a directory sync.
- Security posture
- From the managed-accounts export: how many accounts are under enforced SSO, how many sign in with an Atlassian password, how many of those passwords are weak, and how many email addresses are unverified.
- Org admins, sites footprint and groups
- Who holds organisation administration — with a badge counting the never-seen service accounts among them — how many sites the org contains including sandboxes and personal ones, and the group picture.
- Recommended actions
- Six, each with the number of users, seats, accounts or sites it would affect: reclaim never-used paid seats, trim idle access on the biggest products, clean groups of suspended users, review org-admin service accounts, close the non-SSO gap, and audit the site long tail.
Every drill-down list has Download CSV, and when the table shows only the first N rows it says so and confirms the CSV covers them all.
User Offboarding
What it does. Finds everything a departing person owns — projects they lead, components, dashboards, filters, permission grants, automation rules, boards, assigned issues — and transfers what can be transferred to a replacement.
Why. Deactivating the account is the easy part. What breaks is everything that pointed at them.
User Offboarding
Find and transfer all ownership and role assignments from a departing user to a replacement.
| Category | Found | Action |
|---|---|---|
| Project Leads | 4 | Transfer |
| Component Leads | 11 | Transfer |
| Dashboards | 6 | Transfer |
| Filters | 23 | Transfer |
| Permission Grants | 3 | Info only — manual transfer required |
| Automation Rules | 2 | Info only — manual transfer required |
| Assigned Issues | 184 | Reassign to replacement |
- 1Pick the user to offboard.
- 2Select the categories to scan. There are nine — project leads, component leads, dashboards, filters, permission grants, project roles, notifications, security levels and boards — plus their assigned issues. Select All takes the lot.
- 3Click Scan. Results are grouped by category with a count for each.
- 4Choose the replacement user.
- 5Per section, choose Transfer to the replacement user or Remove without a replacement. They are not the same decision, and for a permission grant or a notification recipient the second is often the right one.
- 6For issues, choose whether to reassign them to the replacement user. This is slow for large numbers, up to a maximum of 10,000.
- 7Click Apply Transfer. The tool reports what succeeded and what was skipped, per category.