Picture a Monday-morning access request landing in your queue: "Hi — can you give me access to the Marketing space?" Simple enough, until you realize you've become a detective. Is that the Jira space where the marketing team tracks campaigns, or the Confluence space where they keep their brand guidelines? They might have nearly identical names. They might have exactly identical names. Welcome to the one genuinely tricky consequence of everything we've covered — and the subject of our finale.

This is part three of our series on Jira spaces. We started with the rename and creating your first space, then moved on to templates and reuse. Today we get to the grown-up stuff: who's allowed to create spaces, how to keep a sprawling estate navigable, and how to stop the word "space" from turning every request into a guessing game.

Who gets to create a space?

Governance starts at creation, and Jira gives you two levers. Creating a company-managed space requires the Administer Jira global permission — deliberately a high bar, because these spaces carry shared schemes that affect everyone. Creating a team-managed space is governed by its own "Create team-managed spaces" global permission, which by default is granted broadly, so most users can spin one up on their own.

That default is a choice you should make consciously rather than inherit by accident. Wide-open team-managed creation is wonderful for autonomy and challenging for anyone trying to keep a tidy estate; locking it down protects consistency but routes everything back through admins. There's no universally correct setting — only the one that matches how much sprawl your organization can tolerate. Worth knowing, too: a space admin (someone with the space-scoped Administer Spaces permission) is not the same as a Jira admin. You can hand someone the keys to their space without handing them the keys to the building — and you usually should.

Space categories: a map for the estate

Once you have more than a handful of spaces, you need a way to see across them. That's what space categories are for: group related spaces together and your teams can view work across all of them in one place — every space belonging to a department, a portfolio, or a business unit, surfaced together instead of scattered. It's the difference between a filing cabinet and a pile.

One governance note: changing a space's category requires the Administer Jira global permission, so categorization stays an admin-controlled decision rather than something that quietly drifts. Use that to your advantage — a deliberate category structure, maintained centrally, is one of the cheapest ways to keep a large Jira estate legible as it grows.

The two-spaces problem (and how to survive it)

Here's the headache the rename created, and there's no point pretending otherwise: Confluence has always had spaces, and now Jira does too. Both can carry similar — or identical — names, which means "the Marketing space" is suddenly ambiguous in a way it never was when Jira had "projects" and Confluence had "spaces." Atlassian has acknowledged this directly and said it's working on ways to make the distinction clearer in the experience. That's reassuring, but you don't have to wait for it.

The practical defense is a naming convention, and it's worth agreeing on one as a team. Make the tool obvious in the name, or use a consistent prefix, so a Jira delivery space and a Confluence knowledge space never collide in conversation or in a search bar. Encourage people to name the tool in access requests — "the Jira Marketing space," not just "Marketing." Small habits, but they quietly eliminate a whole category of daily confusion before it starts.

Spaces vs. Atlassian Projects: the other lookalike

There's a third "project-shaped" thing in the mix, and we promised back in part one we'd return to it. A Jira space is your execution layer — the container where work items live and teams get things done. Atlassian Projects, which live in Atlassian Home, are something else entirely: a high-level, cross-tool view of an initiative, complete with goals, timelines, stakeholders, and status updates. One is where the work happens; the other is how you tell the story of that work to everyone who needs the big picture.

Getting this distinction into your teams' heads is genuinely useful. When someone says "project," it's now fair to ask which kind they mean — and once everyone shares the mental model of space for execution, Atlassian Project for oversight, a whole class of cross-purposes conversations simply stops happening.

What about JQL, APIs, and Data Center?

For the technically minded, the governance news is mostly reassuring. JQL still accepts "project" as a term, with a "space" alias on the way, and your APIs, Forge apps, and automation rules are unaffected — so the message to your automation-heavy teams is "nothing to rewrite today." The work that does need doing is human-facing: update your documentation, runbooks, and training so your language matches the interface, rather than leaving new hires to reconcile a tool that says "space" with a wiki that says "project." And if you run a hybrid estate, keep one fact in view — this change is Cloud-only, with no plans for Jira Data Center, so your self-hosted instances will keep saying "project." Your trainers and documentation should account for both dialects.

The Avaratak Take

Here's the throughline of the whole series. Technically, renaming projects to spaces is about as low-risk as a platform change gets — nothing breaks, nothing needs rebuilding. Linguistically and operationally, though, it's an invitation to get your house in order. The organizations that handle it well do four unglamorous things: they decide deliberately who can create spaces, they use categories to keep the estate navigable, they adopt a naming convention that keeps Jira and Confluence spaces distinct, and they teach their teams the difference between a space and an Atlassian Project. None of that requires new software. All of it prevents a thousand small confusions.

A rename, in other words, is the cheapest governance prompt you'll ever get. The clarity is free if you reach for it — and genuinely expensive in wasted time if you don't. That's the work we love most: not the click-by-click configuration, but the naming conventions, permission models, and shared mental models that decide whether a Jira estate stays legible at scale or slowly becomes a place where nobody's quite sure which "space" anyone means.

That wraps our three-part tour of Jira spaces — from what changed and how to create one, through templates and reuse, to governing it all today. If you'd like a second set of eyes on your space governance — creation permissions, categories, naming, the works — that's exactly what we do as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com. We'll help you keep every space straight.