sadly there is not...whether you expose the root url or they end up there as a result of an issue, etc. all users have access to the root domain. Not sure if there some config options that may be able to lock it down though. Since you can create a sub domain using folders or a different URL, perhaps the latter would be your best option.

https://help.docebo.com/hc/en-us/articles/14652235582994-Domain-Management-Configuring-custom-domains#h_01HDK50XPPD7TVN3BARH4A7SE9

https://help.docebo.com/hc/en-us/articles/360020124899-Managing-the-Extended-Enterprise-app#h_01HAKQ6PQT9JG5N68WH5P2BSF3

See if anything here is helpful.

Maybe I am missing something, but it seems very likely that users, especially if they are moving to the new sub-domain, will enter the old one. Possibly seeing things they should not have access to.

I will have to read some more, maybe there is something in Manage Pages that could help.

@dwilburnWhile I am not as learned as @lrnlab, I’ve been using Extended Enterprise for 5 years now, and I’ve never found a user who, when properly configured, sees content that he shouldn’t. Here’s some of the things I do that might help.

• Make sure that you communicate ONLY the sub-domain name that they need to sign in using. Don’t communicate “<your company name>.docebosaas.com” … use a custom URL that is setup in Domain Management to work only with the appropriate top level branch/folder.
• Make sure that user creation (either by self-registration or by admin registration) is done while signed in to that custom URL.
• Assign catalogs and learning plans to groups or branches related to the sub-domain.
• Remember that Pages assign content, and Menus govern visibility so be really specific with both.
• Remember that a public catalog replaces the “home” page for every branch in your instance (<your company name>.docebosaas.com). Public catalogs don’t play well with Extended Enterprise in my experience.

You may end up with a complex instance (from an admin’s perspective) but I think that each one of these measures helps to reduce the chance that something goes astray.

Thank you @KMallette  and @lrnlab . @KMallette I think many of my concerns are in that first bullet. I have read through the domain stuff but I’m not sure what it is telling me. I keep thinking of it as alternate domain names. 

I 100% agree with only communicating specific domains, but we will be moving current users from company.docebosaas.com to company.docebosaas.com/internal, company.dcebosaas.com/external and others. It is very likely that existing users will come back to old bookmarks.

I am hoping to find a way to redirect them when they end up in the wrong place.

Yes, I absolutely believe Extended Enterprise is going to seriously complicate our lives. I’m just hoping it is worth it.

@dwilburn The domain stuff is VERY confusing. You can only go down 3 levels so you have to plan things carefully.

Here’s what I do

Level 1: docebosaas.com
Level 2: <my company name>.docebosaas.com (which we give a custom URL of viasatdiscover.com). Domain management calls this the Main Domain.
Level 3: my custom URLs based on the Extended Enterprise tenants. For example, bbs.viasatdiscover.com … this is a tenant called BBS. Domain management calls this a Secondary domain.

THEN:

Within each tenant, the first level of plain folders (no customer URL, just a folder) are two folders External and Internal. And from there are hundred (sometimes thousands) of more sub-folders. None of these have custom URLs.

The magic of Docebo is that when the learner signs in with their username, the platform first determines what branch and which groups the user belongs to. If you menu is set up for somebody External, then that’s the menu, catalogs, learning plans, and courses that pertain to that person BECAUSE that’s where you’ve assigned those menus, catalogs, etc.

Good luck!  Feel free to DM if you want to talk it through some more.

Thank you @KMallette, I may take you up on that dm.