Skip to main content

Existing Course Enrolments for new Extended Enterprise

  • February 26, 2026
  • 7 replies
  • 110 views

A few weeks ago we launched some eLearning to a recently acquired business previously not on our LMS. We created the users in a new branch at the root folder. We have since configured Extended Enterprise with an instance for the new people as a subfolder of the main domain. 

Users were using a link in an enrolment email notification to jump to their courses, however since switching on EE, outlook is throwing a wobble as the URL they’re trying to access doesn’t match the one they exist on within the LMS.

Is there a way around this? Is the most painless route to re-enrol so they get the new URL? Can we do anything with re-directs? Should we reconfigure the EE to be a sub-domain or it’s own domain?

7 replies

Forum|alt.badge.img+5
  • Helper III
  • February 26, 2026

If you use the Send Email action from inside the course, you can include the Course Link code which will give them the correct new URL.  So you can send an e-mail to everyone who hadn’t completed the course that they should use this new link instead.


Aegesi
Novice II
Forum|alt.badge.img+1
  • Novice II
  • February 26, 2026

Once you moved to Extended Enterprise, the URL to access the training is now different from the URL they had access to.  I imagine they are getting a 403 error or something of the sort now.  I think, the only way to get around this would be to archive any open enrollments and re-enroll to get the new URL.  

Maybe someone else has ideas, but the old link will not work.  A new link will have to be issued now that they have been moved.


Thanks for the quick replies, if we were to leave this unticked (it’s currently selected)

would that be a workaround in the interim? Once we’re through this batch of new people anyone else will have the correct (new) URL sent to them instead.


martindunne
Novice II
  • Novice II
  • February 26, 2026

​@daniel_smith_9678
 The email that was in the initial email will be wrong now as the EE URL will have the brach name in the email. IE for us we have “Customers” and “Partners” in the URL. Whatever youre branch name the URL will have that. What I would do is to send all “Not started” and “In Progres” Users a REMINDER email.

When sending the email use the shortcodes for names and importantly the course

Hello {{first_name}},

This is a friendly reminder to complete the {{course_link}} training course.

other relevant information about course

If you have questions about the content, or if you experience technical issues, please reach out.

 


@daniel_smith_9678 If the courses are not being used by anyone else in the main domain you can set up redirects. Under course properties > SEO Settings > Redirect URLs

As others have mentioned above you can also re-issue an email from your EE to all enrolled users that the URL has changed. 


Moshe.Machlav
Guide I
Forum|alt.badge.img+2

This is a genuinely tricky situation that touches on a few interconnected issues. Let me break it down.

What's actually happening

When Extended Enterprise is enabled, each portal has its own URL context. Your users received enrollment emails with a link to the main domain, but they now need to authenticate and access content through the EE domain. Docebo doesn't have a native redirect between EE portals and the main domain, so those old links simply won't resolve correctly for EE users — which is what Outlook's security scanning is picking up on.

Also worth flagging: Docebo's architecture means a user account exists within one domain context at a time. If those users were created on the main platform and then the EE was configured around them, it's worth confirming whether their accounts have been properly migrated into the EE portal — or whether they still technically "live" on the main domain. That distinction matters for which URL will ever work for them.

Your options, ranked by pain

The least disruptive option is to resend the enrollment notifications rather than re-enrolling. From the course enrollment management screen you can resend the enrollment email to selected users — this will push out a fresh email with the correct EE domain URL without touching their progress or status.

Re-enrolling is more disruptive because it can reset enrollment status and may affect any progress already recorded. Avoid this unless the resend route doesn't give you the correct URL.

External URL redirects at DNS/server level are theoretically possible but aren't something Docebo supports natively, and in a SaaS environment you don't control the web server — so this path is essentially closed off.

On the architecture question — yes, reconsider the setup

"Subfolder of the main domain" isn't standard Docebo EE configuration. EE is designed to work with proper subdomains (e.g., newco.yourdomain.docebosaas.com) or a fully custom domain. If your current setup is unconventional, that may be the root cause of ongoing URL friction and worth correcting now rather than later. A clean subdomain setup will also make SSO configuration, notifications, and future branding much more manageable.

Recommended path:

  1. Confirm user accounts are correctly scoped to the EE portal (not still "living" on the main domain)
  2. If EE URL structure is non-standard, reconfigure with a proper subdomain
  3. Resend enrollment notifications to push correct URLs to affected users

Forum|alt.badge.img+1
  • Helper II
  • March 12, 2026

This is one of many reasons we stopped using EE/multidomain. We implemented it back in 2019 and stopped using it around 2023, so I assumed things had improved since then.

For us, this happened due to one of our admins setting up notifications *while he was logged in to the non-custom domain, i.e. yourcompany.docebosaas.com*. In order to fix this, we had to login to the particular domain for the users we were targeting with the notification and re-save the notification there. I suspected at the time that, upon save, the shortcode would capture the current domain the person setting the notification was logged into, and that that domain was “hard-coded” into the actual notification. One would assume it would be dynamic and the URL would be set based on the recipient but alas, at that time at least, no. Sounds like it still may be the same issue.