Power User Permissions

Kind of what I thought, but wanted to make sure I wasn’t missing anything.  Thank you so much!

@lrnlab Can you please explain more when you say you have separate PU profiles from the actual user profiles? We are encountering the same issue. Once a PU enrolls in an ILT, they no longer can enroll anyone else. How exactly do you handle this?

Thank you!

we create manual accounts for our PUs so they have at least 2 accounts with the same email. One is their employee account where they completed the required training etc and the other, the “Admin” account is one we create to grant power user permissions. they have the same email address but one is a user and the other a PU. When the PU enrols themselves in a course they cannot perform certain function so we keep them separate.

If they need to complete the course as part of their training plans, they can use thiner “user” account but when they want to enrol other employees, they would login with their PU account. This keep things nice and neat…

Hope that makes sense...

Makes total sense, thank you again. 

Interesting, we have Power Users with profiles like this for years, no second accounts and we have not run into anything like this. 

Do I understand correctly that this only occurs when the Power User has enrolled themselves in the course and then they try to enroll someone else into the same course?

If so, does this happen a lot in your use case?

That is correct, once a PU has purchased/enrolled in an ILT course, it is not possible to purchase the course for another user as the option to purchase is no longer available. The PU only sees that they are enrolled. 

Our PUs will typically purchase/enroll several learners at a time and this works fine as long as the PUs don’t want to purchase for themselves, or purchases after they have purchased for all other learners first.

Thanks for the explanation @lrdeardoff I am seeing why this does not impact us. We drive the majority of our learning from PUs or Enrollment Rules assigning Learning Plans. The LP enrolls the user in the class. Then PUs can enroll a user in a session as needed.

We would like to do this, but with SSO through Okta, our IT department does not want us to create duplicate Okta accounts because the username is also the email address. We only allow sign on through SSO. So if we were able to get past IT and create the second account, we find issues with the Browser Cache getting confused when a user tries to login with their first account, forgets they were logged in, then tries to login with their second account. The platform gets confused with which account to actually use, and the user experience goes off the rails in some instances. So we have to archive the Power User’s enrollment for them long enough to purchase the course for others, and if they were not yet complete, we have to re-enroll them. When these are eCommerce courses it gets worse because when a Superadmin manages the enrollment, there is no associated eCommerce transaction or way to indicate that it was a re-enrollment that should not be charged another fee. We have tried many alternate solutions, and have yet to find something that does not require manual workaround by a Superadmin behind the scenes.