Issue using [course_link] in notifications for external users

I can confirm. You must be logged into the EE and create the notification in that EE for it to have the correct link. Additionally, the person receiving the notification must be logged into the correct domain. 
 

What I keep proposing as a fix (it’s in ideas somewhere):

If an EE person clicks or enters a non-EE link, bounce them to the EE version of that page. 
 

There’s a SIMILAR option in the platform but it just locks people out, it doesn’t redirect intelligently. 

Confirming as well. @lrodman hit the nail on the head.

Lets say links feel tricky right now.

I do think the story has been improving, but the greatest challenge is once a person is a authenticated - their permissions are checked relative to the course and a few things happen:

• if a person has been enrolled, they should be working with a specific url
• if a person has not been enrolled, they should be working with a different url
• There is also a saml-sso url (a shortcode is avialable for it)
• The one url that trumps all for a course is the one that autoenrolls someone into the course.

I do know that the product team has ideas slated to improve this - (I would need to find the article, but it involves a universal url format is what I believe I read up on).

We battled this alot in the beginning and have been moving over to using the autoenroll deeplinks.

I wont lie to you? As we gear up with more of an extended enterprise implementation, we are going to have to figure out those shortcodes even more. But I feel your pain? And if at all possible? I would recommend the autoenroll deeplinks to drop people off at the right content.

2nd best - would be to pass along a deeplink to a page versus a course. You can still maintain strong permissions with that approach.

The universal url would be a huge fix. It is hard to explain to power-users that they can’t just use their browser urlbar url. Obviously once they can, this will be SO wonderful for us!

@dklinger @lrodman great news… Universal URLs for Courses and Learning Plans are now available via the new Course and Learning Plan player! We covered this in the March 2023 Release Readiness Webinar (see 8:40 for an overview of how the new links work). I’ve shared a screenshot that highlights the new link format below.

The new URL functionality is reverse-compatible with old link behavior, so shortcodes in email notifications will still function as designed once you’ve activated the new Course & LP Player in your platform.

Thanks for your responses. However, I just ran a series of tests that contradicts this functionality.

While in the EE, I created a new notification with [course_link], then enrolled in the associated course from the EE and got the EE link. But, then enrolled in the course from the Root and got the Root link.

Then, while in the Root, I created another notification with [course_link]. And, similarly, while in the Root, I got the Root link, but while in the EE, I got the EE link.

This should support the idea that it matters where the user is logged in, not where the admin creates the link. But, we are still getting some EE users who are getting a Root link. But not all. That’s what has us scratching our heads.

Has anyone else encountered this inconsistency? Thanks!

Interesting. If it is where the user is logged in to, that would be way better for me.

@FredTacon  when we started using the EE we came across with the same struggles and when went through the same path trying to resolve it. And after a lot of testing, we came up with the assumption that the domain listed in the notification is generated by the domain where the enrollment is processed.

The issue seems to be resolved by having the notification built within the intended EE and processing the enrollment from that same EE.

So, I was taught by docebo that if you make the notif in the right EE instance you should be good.

However, Fred indicates his testing shows otherwise - that it is usually, but inconsistently, based on the domain the user is in when they complete the course - NOT the EE instance that the notif was coded in.

Obviously making this clearer to superadmins when looking at notifs at a glance would be lovely :D

We had the same issue as well - we were advised to not only to create the notification logged in on the EE domain but to also schedule with a 1 hour delay instead of immediately.  If the notification sends immediately it picks up the domain of the creator - a little bit of a delay allows it to pick up the domain of the learner

@michelebanks - I think I may experiencing what you’re describing. I created notifications in my EE domain. I am now in my Root domain. I am assigning a course to people in the EE. They are receiving links that go to the Root not the EE. And they can’t get in. It’s not a brand new course though.

What should I be doing differently?

@JKolodner Our extended enterprise is in a single branch - we restrict the ILT notifications to that branch. 

We also created the ILT notification for the EE while logged into the EE as admins.  We basically placed the EE URL in the browser and from that admin screen created the notifications for the ILT classes. We then placed the send time on an hour delay because our EE is Mountain Time but the main system is Central.  The hour delay allowed the notification to pick up the time zone of the EE user where if it sends immediately it uses the time zone of the creator’s PC.

For the courses, we did use the regular course link on the notifications and not the course saml link. As our EE is on a different sso domain.

Can you tell me what the difference is between these two links? We are using the short code called [course_link]

The course saml link shortcode is useful if you have  Okta SSO.  When your users click the link - it kinda bypasses the login page and automatically signs the user into Docebo via SSO.  For the user, they go instantly to the course bypassing the login screen