Looking to simplify my power-users' "user management" pages - what are best practices?

lrodman
Rank
Userlevel 7
Badge +5

Hello,

 

We have 5000 powerusers and 100,000 users across 600 companies in our Docebo.

As we roll out, power-users are pointing out that people who have quit, been terminated etc show up in their user management page.

 

I know we can deactivate members but they will still show up on user management and potentially reporting (if people run the reports without unchecking inactive users, which I’m sure they will).

 

I was thinking of moving all inactivated users to a branch “former members” - which is also where I put branches for companies that no longer are members with us. I don’t want to lose completions data for those former members, even the terminated ones.

 

I was also thinking of moving a large group of inactive members to another branch “inactive users” - and let SSO move them back to their proper branch on their next login. Would this work? SSO is mapping their branch code. We’d have to test this though.

10 replies

Bfarkas
Rank
Userlevel 7
Badge +3

We do a similar setup with a seemingly redundant ‘Inactive’ branch to cover the issues of the inactive setting. Our SSO doesn’t bring them back automatically (it is not that fancy) so we do a batch job every morning of all new users, all updated users, all inactive users, etc. which re-activates and updates these users to the right branch.

Sounds like your SSO moves people around normal branches already? So in theory should just work right? Although if they are marked inactive they wouldn’t be able to log in? In theory sounds doable though, definitely worth a couple of test accounts though.

Bfarkas
Rank
Userlevel 7
Badge +3

It’s actually our top level branches:

So that everything systemwide can get filtered easily this way.

lrodman
Rank
Userlevel 7
Badge +5

Sounds like your SSO moves people around normal branches already? So in theory should just work right? Although if they are marked inactive they wouldn’t be able to log in? In theory sounds doable though, definitely worth a couple of test accounts though.

Well, my SSO is feeding branch codes into docebo, which are locked, but I can then move users around and they seem to stay put on subsequent logins, so I suspect it won’t move them around. TBD. I do have a call with Auth0 professional services today and plan to ask.

It does deposit users in the proper branch on first creation via JIT.

Bfarkas
Rank
Userlevel 7
Badge +3

Ah Ok, so they don’t shift around. Wouldn’t they be inactive anyways so wouldn’t be able to log in? Would think you would need a re-activate process that updates their info including their branch?

lrodman
Rank
Userlevel 7
Badge +5

No, they would be active but in that dummy folder.

 

Inactivating users just blocks them from login, right? We already have SSO to do that, so I’m telling people not to inactivate users (since it is pointless and might later cause an issue down the line if someone returns and the training admin doesn’t know about inactivation)

Bfarkas
Rank
Userlevel 7
Badge +3

No, they would be active but in that dummy folder.

 

Inactivating users just blocks them from login, right? We already have SSO to do that, so I’m telling people not to inactivate users (since it is pointless and might later cause an issue down the line if someone returns and the training admin doesn’t know about inactivation)

Ah ok, it hides them from some other places too so we use both.

I wasn’t thinking re-activation would be a person doing manually, should be a process.

lrodman
Rank
Userlevel 7
Badge +5

Well, I probably need to define (I’ve been saying this for a while) not just what we call xchangeID (branch code) but docebo_branch-code as a variable in Auth0 to pass in. But yeah once they exist they seem to stay put, it’s just JIT that deposits them in a branch.

 

Presumably we could set Auth0 on each login to send an API command moving branch in realtime - or just on first login to docebo. That could work.

lrodman
Rank
Userlevel 7
Badge +5

 

Ah ok, it hides them from some other places too so we use both.

 

Oh? What else does inactivation do? 

Bfarkas
Rank
Userlevel 7
Badge +3

Well, I probably need to define (I’ve been saying this for a while) not just what we call xchangeID (branch code) but docebo_branch-code as a variable in Auth0 to pass in. But yeah once they exist they seem to stay put, it’s just JIT that deposits them in a branch.

 

Presumably we could set Auth0 on each login to send an API command moving branch in realtime - or just on first login to docebo. That could work.

Or, depending on the flexibility of that API setup...on login check branch of user, if the inactive, update branch. Then your manual moves in other branches remain uneffected.

Bfarkas
Rank
Userlevel 7
Badge +3

 

Ah ok, it hides them from some other places too so we use both.

 

Oh? What else does inactivation do? 

I don’t remember them all, but the one that used to get me was any time doing a user enrollment or search in a specific area, not user management or reports, especially where they just show the names, was useful to eliminate as many incorrect users as possible.

Notifications also stop I believe right?

Reply


Terms & ConditionsCookie settings