Jonas Nilsson | Unitlane Insider

Thanks Stavros, good catch. Appreciate you looking it up and sharing the link.

One question I would love covered in the Q&A is default groups and unintended billable access. A lot of cleanup advice focuses on workflows, fields, and schemes, but finance pain often comes from users who still have product access through default or secondary groups even after their day-to-day work changed. Better…

One thing I would add for admins is that service accounts need an explicit exception policy, not just documentation. They often look inactive in the human sense, but that is normal when they authenticate through tokens instead of interactive login. If you do not separate them from normal cleanup logic, they become false…

One practical rule that helps here is: use internally managed groups for default app access, and use SCIM-synced groups for identity-driven membership and permission mapping. Default groups need to be writable by Atlassian, so even a technically correct external group is still the wrong anchor for automatic placement. It…

"Sync disabled" often is not enough if the users and groups were provisioned through SCIM originally. If Atlassian still treats them as SCIM-managed, manual removal stays blocked until you handle it at the identity-provider side or fully break the provisioning relationship. Before doing that, I would check which…

If the group has a lock or is SCIM or IdP managed, you usually need to change membership on the identity-provider side, not in Atlassian. For cleanup and governance, I would keep two concepts separate: the synced groups that represent directory truth, and the internally managed default access groups that Atlassian can…

The key difference I would add after the MQB change is that cleanup value is less about end-of-month heroics and more about preventing avoidable users from entering the next billing cycle in the first place. The hard part in practice is not only detecting inactive users. It is explaining why they are still billable and…

Inactive ownership review and billable-access review really belong together. When I find abandoned filters or dashboards, I also want to know whether the same account still consumes product access and through which groups. Otherwise I can clean up ownership drift and still leave the cost and governance problem untouched.

Strong breakdown. The part that usually gets messy in Atlassian is not producing one export, it is explaining why a user is still billable when the same account may sit in default groups, secondary groups, or unmanaged-account edge cases. For me the strongest control is not just a quarterly list, but a repeatable review…

I would avoid deny-style workflow properties for this use case. The cleaner pattern is a dedicated project role like "Can Comment" and then grant "Add Comments" only to that role in the permission scheme. That preserves view access while keeping comment rights scoped per project. Separate point for later cleanup: once…

Really glad to see more cleanup tooling and guardrails. One gap I still run into is safe group cleanup: admins can spot unused objects more easily now, but it is still hard to answer "what breaks if I delete this group?" before changing permissions. A dependency-first view for group impact, especially across permission…

My hidden #1 is access cleanup safety. Everyone agrees stale groups should be cleaned up, but the painful part is proving what a group still affects before changing it. That turns what should be a 5-minute cleanup into half a day of checking permission schemes, project roles, and then manually cross-checking other shared…

One cleanup risk I keep seeing is group cleanup specifically. Field and scheme sprawl are visible; group impact usually is not. Before removing a group, I now treat four checks as mandatory: permission schemes, global permissions, project roles, and shared filters or dashboards. The hard part usually is not deleting the…