I might be a bit confused on your use case, but I can share our procedure.
We give clients their own branches to run their training sites. Menus, dedicated homepages, Power user visibility, are tied to the individual branches.
This all takes place under a single root extended enterprise.
We only create additional enterprises for clients who wish to utilize additional features such as SSO, or a dedicated domain name - and then we just tie these to their branch.
However, the client doesn’t need their own extended enterprise if not using these features. Everything can be controlled by visibility such as dedicated homepages, courses, etc.
Thank you for the quick response.
That’s currently how we’re using the root external service. Creating visibility for branches, with custom pages and menus. I just want to isolate internal content from external customers. With that, I’ll just establish an internal branch with sub-branches representing the organization on a single new client. This client will be SSO.
@cmanrique sub domains can also allow you to brand the site which is also useful especially with internal and external clients...there are many ways to configure Docebo...while branches work great for simple things like managing catalogue access, PU access and the like, the sub domain allows you to manage different privacy and T&C, headers, footers, branding, etc. which might be best in your case.
@JZenker / @lrnlab - we bought into extended enterprise after our implementation was done.
And so - when spinning off a new domain - any best practices to keep in mind?
@dklinger big question, lol...all I can say is test, test, test and track your configuration changes for each sub domain...other than that they work great and give you lots of flexibility. If you need any specific info, let me know.
@JZenker/ @lrnlab - we bought into extended enterprise after our implementation was done.
And so - when spinning off a new domain - any best practices to keep in mind?
@dklinger When I was working with extended enterprise - to help organize all pages/menus etc, we used codes to help us differentiate which part of Docebo was designated for each domain. For example:
- Client Domain -
- all pages/menus/catalogs etc that were designated for the client domain had the code prefix of “CL”
- Non-Client Training Portal -
- all pages/menus/catalogs etc that were designated for the client domain had the code prefix of “TP”
When it came to pages, even if there were similar pages shared between domains, we would create duplicate for each domain, because we would encounter instances were one domain needed a small change on a page.
@cmanrique - We use each of our Extended Enterprise domains the way you describe in your first scenario. That means that your learner only has to log in once to access all of their compliance, professional and regulatory training and they see the branding that is appropriate for them.
Each one of our “academies” has its own space/branding, but they are all built similarly. We build branches that roughly parallel departments and we use groups and enrollment rules to automate content assignments within each domain. We customize SSO, email, notifications, and branding by domain. We have naming conventions that all groups have to work with so that we can share across domain as needed.
The secret to our success is a model built on trust. We are fortunate to have a very high degree of trust in our L&D leaders distributed across our family of companies, so we included them all in our initial onboarding training, and now our daily updates, and monthly check-in meetings. They serve as SuperAdmins and take care of the needs of their branches or domains, respectively. We come together to share, problem-solve, celebrate and grumble, which increases the sense of ownership and partnership. There’s no need for one person to be “the expert” since that’s a near impossible task, and we all grow together.
