How do you say no? Governance for Power Users vs. Superadmins

Oh, do we get push back.

In our use of Docebo, we have a federated model, where Global Office (GO) - that’s me and my team  - controls the system with our member organisations (MOs) having only Power Users to ‘do things’.

The main reason they want to be superadmins is that they want to create their own pages and not have to rely on a superadmin, but we do tell them that they can not be superadmins because we can’t let an MO see another MO’s information - so that settles it quickly.  They also feel that ‘it’s not fair’, but it is what it is.

And hopefully with some upcoming changes to Power Users (fingers crossed) some of the things they want to do but have to rely on GO will not be an issue anymore.

Good luck and Battle On!  :-)

Do you have a governance document that states what warrants each type of level or the rules and responsibilities around each level? If you can set the standard for who can have each role, that might help you long term. You can guide the standards to be what you see as a superadmin vs. a power user. If a role doesn’t fit as a superadmin then at best they can be a power user. For my company we can usually use the word “security” and it solves any discussion about permissions. 

We’re going through implementation now and anyone that wants to be more than a user has to submit a proposal with what they need and why. At best it’ll be power users except for a very small number of superadmins….because of security. 

Thanks for posing the question, @Dahveed. 

One response to push back from a few users has been to set them up with Super Admin rights in our Sandbox instance and see what they do. It’s a safer space if you’re concerned about anyone breaking anything and, from what I’ve seen, it quickly demonstrates whether users are actually interested in using the rights vs. simply having the rights.

I really like the idea of a governance document to outline who gets what permissions and a proposal process to understand the responsibilities needing to be covered by specific system rights, @steveninfinger!

I’d say our approach has been mostly top-down in terms of expanded rights and really extends from our culture. We moved from a system where most members of our internal team had nearly unlimited rights but didn’t use them because functionality hadn’t been explained or the critical nature of certain functions were highlighted with a “you break it and we’re screwed” kind of approach. As a result, many members of our team are pretty comfortable sticking to what they know. 

Not to be too melodramatic, but there is a greater burden in having Super Admin rights than prescribed Power User rights so you can always play the martyr card and tell folks you’re saving them much anguish….

@steveninfinger We don’t, but I like the idea of a governance document!

Once it is written and approved. I can just point to the document  and say...”it’s the rules!”   ¯\_(ツ)_/¯ 

@Dahveed, exactly! If someone from the impacted teams has buy-in and they agree to the documentation, then anyone else that wants SA permissions has to push a bigger rock up the hill to get the permissions.

Hi all! Great question and some wonderful responses. We are currently working on a course for Governing Your Docebo LMS with lots of great information to share but I would say that this really is an issue of governance. 

Here is an amazing article about LMS governance.

Tips and Ideas

1. Create a certification plan for Admins. If they want to be a super admin they should receive training, enablement, and pass a certification demonstrating they can properly manage the functions they will be given, whether that is Power User or Super Admin. 
2. Have a governance plan in place. With multiple admins, you should document your existing configurations and rationale along with ownership and any governance considerations. For example; Why did you set those Advanced Settings that way? Did your security team say you had to and you CANNOT change it or was it just what made sense when you set up the system and it can be adjusted if needed? Who owns the decision to change the setting?
3. Understand what they really need to do. If a stakeholder is looking for Super Admin or Power User access make sure you know why. What specific things do they need to do in the system and how does that tie to business results? Create a request form/process, understand the capabilities of Power Users versus Super Admins so you can map their request to the right User Level, and draw lines. Super Admins can do it all. Power Users can do a lot but there are some things that aren’t covered in Power User permissions that create that grey area. Technology always has limitations, it is what it is, so lean on the capability of the system to reinforce necessary boundaries. Risk vs Reward. 
   *Document needs and share with your Customer Experience Manager or Docebo point of Contact and add an IDEA in the portal. 

Keep an eye out for more information around governance planning and resources to come from your Docebo team!

Attached is a resource that will help with documenting for governance.

All comments above are 100% provided that Superadmins have the flexibility to configure PU profiles with all necessary permissions.

There is however another dimension I would like to introduce to the discussion.

What if they don’t want to be a Superadmin per se, they just need to be able to ‘do things’ that Power Users can’t do in the world of Docebo?

We’re assuming that Power Users shouldn’t be allowed to do those things but that’s not always the case.

For example one of the issues we’ve encountered is that Power Users can create users but they cannot send activation notifications retrospectively.

This means that when they create a user they can either:

1. leave the option to ‘Send Activation Notification’ toggled on and only create users at the exact moment when it is appropriate for the notification to be sent or
2. turn it off so they create users and set up their subscription access in advance of onboarding etc and then bother the Superadmins to send Activation Notifications.

Has anyone got a good work around for this?

Hi David,

great discussion you’ve got going here.  On the original questions, we use two things to help limit who has access 

1. rules around GDPR and data protection, you have to be approved and have been trained to have access to account information (even if you don’t intend to look at it)
2. I pull out my Spiderman speech “great power comes with great responsibility” and many baulk once they realise that there are responsibilities and tasks that come with superadmin access, especially when one of those is helping support other power users.

On your follow up question above, we’ve got exactly the same problem with pages and activation notifications as you.

• for pages: we’ve taken the hit on this one and changes have to come to us superadmins (there is an idea in the portal for pages to be edited by power users LMS-I-3685 - please vote for it!).  This means that pages have to be kept as simple as possible.
• on activation emails: I believe these do go out on activation if it’s part of the account creation process.  However, they can’t send a new one and have to ask a superadmin to do it.  Again there is an idea in the portal LMS-I-3302, please vote for it.

Joanna

This was a major issue when I joined my organization. Power User profiles had not been sorted out, so everyone was either a normal user or a superadmin. I actually interviewed each person to see how they were using the system currently and then made Power User profiles that ensured they would not lose access to the features they were actually using. Very few users experienced any meaningful change on their end, and the few that did I simply explained that for system integrity, I would be happy to complete those tasks (adding a new branch/group/automatic assignment) for them.

Two things! 1. @steveninfinger is spot on with a Governance Document, we have one that works well. 2. I believe that  “No” is a complete sentence!

I took my executives and a few others through the Power Users capabilities and showed them everything they would have time to do, was at their finger tips and they could leave the rest up to me! I used some time logic and focus on the job roles, I don’t need them spending time micro managing Education, leave that to me and allow them to focus on the coaching they can do with their own staff in their departments or branches if their time isn’t tied up in the platform. 

As nice as this is, the discussion of roles and responsibilities comes in to play.  For our organization HRIS owns the superadmin roles, but L&D are the ones actually using the system.  So for functions such as enrollment rules, dynamic group creation, content repository access, Category creation which are all L&D responsibilities, this necessitates the need for L&D to have the superadmin roles to perform their job functions as LMS admins. 

The fact that power users cannot do these tasks is mindblowing!! 

Furthermore, when looking on how to implement controls to support the need for expanded SA permissions, it came to light that the audit trail does not log all actions as it relates to system config!  How can you have an audit system that doesn’t track when a foundational change is made to the system??

This has caused a lot of friction because now L&D are handcuffed and unable to perform their responsibilities and HRIS is now saddled with L&D tasks which are out of scope for HRIS.  Very poor design in my opinion, I sure hope Docebo gets their act together when it comes to enhanced PU permissions and SOON

Thanks Joanna and apologies for the delayed reply. I’ve been trying to extinguish several fires caused by Docebo’s eCommerce module and had to withdraw from Community activities and contemplation of improved future states.

I understand the ‘great power, great responsiblity’ Spidey speech ;)

My point was that there are a number of functions (like the ones that you have in the Ideas Portal) where the decision as to whether that power can be delegated should be left up to the Superadmin based on their use case. If Superadmins assign too much power to PUs then they will have to live with the consequences.

But there are several permissions which cannot be assigned to PUs and this has the effect of hamstringing their effectiveness and creating bottlenecks because Superadmins are the only ones able to perform the tasks.

For example, PUs can’t create or even rename branches which precludes us from delegating management of our subscription transactions.

For this reason @Jtischler’s comments above really resonate with me. Superadmins are ‘saddled with tasks’ which should be able to be assigned to operational PUs.

We had already voted on LMS-I-3302 but you may want to get it merged with https://doceboportal.ideas.aha.io/ideas/LMS-I-445 in the hopes that it gets more attention. (Don’t hold your breath though, LMS-I-445 has been open for 32 months and it’s still only at the ‘Product Owner Review’ stage.)

Thanks

David

Tell them NO.

I mean even with lots of pressures and organizational drivers around you, remind them being the expert that becoming a PU or SA comes not only with tools but it assumes responsibilities and will pass along functions that you cannot manage when they are beyond your reach. Too many cooks and the pot.

They (whoever THEY are) will not be happy - prepare for an escalation and work the political circle accordingly.

THEY need to remember that you are (potentially) living this every single day….and their request cannot be met for the betterment of the organization - it has nothing to do with them (unless it does).

 OH and a plus 1 on a governance document surrounding roles.

@Dahveed IMHO, there isn’t an easier way. I’m assuming that you are the “top” super admin and as such, you have the responsibility to your company and to the rest of your users to meet the goals of your migration to Docebo - to provide consistency, process, compliance, better user experience, etc. in your platform. If these persons can’t see or agree that you’ve been tasked with this responsibility, then it’s their problem not yours.

I would suggest, however, that you listen closely to their complaints. Think about how processes might be changed to address their concerns, etc. In my case, I had a couple of instructional designers who wanted to load their courses into the platform. Problem was, they couldn’t remember the steps for doing so so I would get interrupted by them to do a job I wanted to do myself; but, I had been directed by my manager to let the instructional designers have their way. I gave it six months; and, after that, I went to my boss and changed the process to what I wanted. I also reworked some of my other responsibilities so that I could offer a much shorter SLA for course publishing and then I over-delivered. It took about 3 months for the peanut gallery to quiet down and now it is settled process.