How give space admin rights in Confluence with plug-ins, simple integrations (API) management?
Asked by Moez_Ben_Dhahbi:

Hello, within a big organization (1000s of users), people in countries need to have local admin rights with possibility to manage plug-ins, copy/paste pages, manage simple integrations (JIRA for instance).

This could not be done with space admin rights.

We do not want to create several instances and give syst admin to each entity instance because we want Confluence to enable sharing between countries...

\> How do big organizations manage this?

Thanks :smile:


Answers:
author: Nic Brough -Adaptavist-
body: No, seriously, you do not want to delegate rights for add-ons and global integrations. Any add-on or integration is a potential risk as well as a benefit. It could be adding functions that some teams don't want, it could be introducing changes, or worse, bugs, and you'll find it breaks stuff for one team and because it's another team's admin, they haven't even been warned, let alone had a chance to consider and approve it.  

I've seen this happen several times, and had to clean it up. The screaming you get when one admin makes a change that clobbers other teams stuff is horrendous. Do NOT do it.

You need to establish a small team of admins who work **very** closely together to serve the global needs of your users. Build them a JIRA project to track all change requests and allow all your confluence users to see it. Build a proper process so that your administrators can analyse any requested change and assess the impact, publicising any changes that might affect teams other than the one raising the request. Give them the authority to say "no" to as much as possible, and the right to delegate discussion to any teams where conflicts might arise.

comments: author: Moez_Ben_Dhahbi
body: thanks!! :smile: I understand by this that there is no possibility to have local system admin who add addons / integration only for some spaces without impacting the others.

I thought it was possible like in GitHub Enterprise, Slack.

Is my understading correct?


author: Nic Brough -Adaptavist-
body: The plugins for those systems are much more simple and run for just the current area, so it's possible there.

Most add-ons for Atlassian systems are sweeping across-the-board add-ons with global effects. Although you'll find many delegate functions down to projects/spaces, it's more efficient and coherent to install globally and use locally.

A good example would be a Confluence theme - you can make a total mess of someone's space with a theme, but you install globally, and then the space admins can choose to use a theme if they want it. You'd want to control the global elements to make sure you don't trash everyone's space, but they still delegate the local stuff to space admins.


author: Moez_Ben_Dhahbi
body: Thanks for this answer, I would have some further questions

How big companies manages Conflunce use across their different entities? Our entities end by asking their own instance (let's say 200 to 500 users each) in order to have enough freedom to do local integrations be able to do local template that space admin can chosse either to apply or not.

Our pb is that we want to use Confluence as the sharing space across the entities, will they be able to do achieve this sharing once they are in several instances??

Do we end with a labyrinth solution if we add a search engine on the top of all Confluence pages?

Thanks!


author: Nic Brough -Adaptavist-
body: \>How big companies manages Conflunce use across their different entities?

They either run separate instances or, as we've said already, You need to establish a small team of admins who work **very** closely together to serve the global needs of your users.

They will find sharing quite hard if they're in separate instances, hence having one is a good idea.

I'm not sure what you mean by the last question. An external search engine will be a layer of complexity, but it'll work.


Tags: confluence-administration