Jonas Nilsson | Unitlane Insider

Monday, 9:10. A customer writes "any news?" on a request that says In progress. You open it. The assignee is stuck on a firewall rule. The firewall task belongs to another team, and nobody has asked them anything for a week. That request isn't slow. It's waiting, and nothing on the screen says on whom. Plenty of late…

月曜の朝、チームのボードを開くと何も表示されません。ボードの設定は誰も変えていません。変わったのは 1 つだけです。2 週間前に削除の手続きをした退職者のアカウントが、週末に完全に削除されました。 退職者のアカウントを定期的に削除するのは良い習慣です。問題は削除そのものではありません。Jira の中に、まだその人を指しているものが残っていることです。 まず、誰がライセンスを使っているかを確認する Jira のライセンスは、使っているかどうかではなく、アクセスできるかどうかで数えられます。一度もログインしていない人も請求の対象です。 * 一覧を出す: アトラシアンの管理で [ディレクトリ] > [ユーザー] を開き、画面上部の [•••] >…

It's Monday morning. Someone on the support team tries to create a work item and Jira says a user "does not exist". Nobody touched the space. What changed? On Friday, the account of someone who left a month ago was deleted. Deleting leavers on a schedule is a good habit. The delete is rarely the problem. The problem is…

One user-governance problem I keep seeing in Atlassian Cloud is that finding inactive users is only half the job. The harder part is explaining why the seat is still billable before anyone removes access. Atlassian's own documentation says users are automatically placed in default groups when you give them access to a…

The group had zero members. That was the whole reason it looked safe. No current users. An old name. Maybe a contractor team, a migration artifact, a temporary project, or a department that has been renamed twice since the Jira site was created. So the cleanup question feels simple: Can we remove it? That is where Jira…

The spreadsheet looked convincing. Names. Emails. Last activity dates. A clean list of people who had not used Jira in months. Then the renewal question arrived: Why are these users still billable? That is where the spreadsheet stopped being enough. It could show who looked inactive. It could not explain the access path.…

The spreadsheet looked convincing. Names. Emails. Last activity dates. A neat list of people who had not used Jira in months. Then the renewal question arrived: Why are these users still billable? That is where the spreadsheet got quiet. It knew who looked inactive. It did not know the access path. It did not know which…

The group had zero members. That was what made it feel harmless. No one was in it. The name looked old. Maybe it came from a contractor project, a migration, a temporary launch team, or a department that had been renamed three times since the Jira site was created. So the cleanup question seemed simple: Can we remove it?…

Deleting a Jira group should not feel like guessing. But in many Jira sites, that is exactly what it becomes. Someone finds an old group. The name looks obsolete. Membership looks stale. Nobody remembers who created it. Nobody is sure whether it is still used. So the cleanup request sounds simple: Can we delete this group?…

Jira license cleanup: inactive users are the easy part Most Jira license cleanup starts with the same thing: An inactive-user export. It feels like the right place to start. You get a list. You sort by last active date. You find old users, former employees, duplicate accounts, test accounts, and accounts nobody recognizes…

Deleting a Jira group sounds simple until you are the person who has to approve the change.The risky part is rarely the delete button.The risky part is not knowing where the group still matters.Before renaming or deleting a Jira group, I would want a small evidence checklist:- Is the group referenced in any permission…

Inactive-user exports are useful, but I do not think they are enough for a good Jira license cleanup workflow. The export tells you who has not logged in recently. It does not always tell you: - why the seat is still billable - which product access path keeps it active - whether a default group is involved - whether the…

When you are about to rename or delete a Jira group, what do you personally need to see before you are comfortable making the change? In a lot of environments, the click itself is easy. The harder part is proving where the group still matters across project roles, permission schemes, and inherited access before someone…

For teams on Maximum Quantity Billing, what still stops billable-access cleanup from becoming a monthly routine instead of a quarterly project? The cost pressure is clear. What often stays messy is the review step before changes go out: what still makes a seat billable, what should be excluded, and what is genuinely safe…

What actually stops Jira seat cleanup from being fully automatic in your environment? For a lot of teams, it is not the idea. It is the exceptions: unmanaged accounts, service-account-like users, inherited access paths, and approval requirements that make teams hesitate. I am building in that exact cleanup-review lane…

What slows Jira group cleanup down most in your environment: finding exact references, getting approval, or explaining afterward why the change was safe? My bias is that deletion itself is rarely the slow part. The friction usually sits in the review step before the change, or in the explanation after it. Context for why I…

Every admin can spot stale-looking accounts. That part is easy. The stall starts when someone asks the question that actually matters: why is this seat still billable, and what happens if we remove access? That is where cleanup turns political. An account that looks like easy savings can still be billable through the wrong…

Every Jira admin has had this dropped on them: can we delete this old group? It sounds like ten minutes of cleanup. The delete is not the scary part. The hour after it is. If that group is still sitting in a permission scheme or a project role, a simple cleanup stops being cleanup. Now you are tracing permissions,…

I keep coming back to the same Jira Cloud cleanup problem: group cleanup. Deleting the group is the easy part. Figuring out what it still affects before making the change is the part that gets messy. Atlassian’s own documentation says the UI does not directly show whether a specific group is used in a permission scheme,…