Role-based access for apps

Patrice Champet

Hey everyone!

The rollout of Role-Based Access on Confluence has been a great step forward for managing user permissions more granularly — really loving it so far!

That said, it got me thinking about how to best handle app access on spaces, and I'd love to hear how others in the community are approaching this.

Specifically:

• Are you using one of the standard roles provided by Atlassian for your apps, or did you find them too broad?

• Did you create dedicated custom roles for apps — either a single generic one or several depending on the app's purpose?

Any feedback, tips, or real-world examples are welcome. Thanks in advance for sharing! 🙏

 

Sami Shaik

@Patrice Champet , good question, and it is the one the RBAC rollout leaves for admins to answer on their own, because app access is where the "role equals a bundle of permissions" model meets a user that is not a person.

What I have landed on: one custom role per app purpose, never a standard role, and never one role for all apps. The reasoning:

1. The standard roles were written for people. Viewer, Commenter and the content roles bundle things a human needs together (view plus comment plus attach plus export, for example). An indexing app needs view and nothing else; a page-generating app needs create and edit but has no business exporting or deleting. Handing an app the nearest standard role gives it two or three permissions nobody intends it to have, and those are the ones that show up in an audit.
2. One role per purpose, not per app. The set of purposes is small (read-only index, content writer, macro renderer that needs attachment read, admin-level connector) and stable; the set of apps is not. Roles named after purpose ("App read", "App content write") survive an app being replaced; roles named after vendors do not.
3. Keep the role's permission list short enough to read aloud. If a role needs a paragraph to explain, it is two roles.

Two things to check before building any of this: custom roles need a plan that supports them (Premium or Enterprise), so on Standard the honest answer is the least-broad standard role plus space restrictions; and the fallback role you set for the site applies to apps too, so an app added to a space with no explicit assignment inherits whatever the fallback grants. That second one is the thing I would verify first on any site: open a space's People list, find the app users, and see which role they actually hold today. In the estates I have looked at, the answer was rarely the one the admin expected.

I would be interested in what the app vendors themselves say when you ask which permissions their app needs at minimum; the good ones answer with a list, and the list is the role.