Using an Intermediary service to send email from Storyline

There are a lot of instances when you might want to send an email from within a Storyline course module...

• sending a completion certificate
• sending course notes the learner has made during the course
• sending self-assessment survey results

...are just a few common requirements discussed on this community site. The most common approaches are:

(a) use the 'send email' trigger available within Storyline - this is great but doesn't allow you to set the subject or content of the email.

(b) use JavaScript to send the email - here variables can be set to create the subject and body of the email and these can be used within the 'mailto:' construct. - mailto:`{email}`?subject={subject}&body={body}

The problem is

• you can't do a lot to make the emails look great - the most you can do is get a string of text from your dynamically added content.
• mailto will always open a device's default email client, even if it's not the provider that the user typically uses. Some users (like me) don't have an email client server installed on any of their devices. In this case mailto won't have anything to open at all and it won't work.
• Finally, some spammers use bots to search the web for mailto links and then use those bots to spam mail servers.

So, is there an alternative?

It would be tempting to think that you might be able to send the email from the JavaScript directly - bypassing the user's own email client. However, to send an email, you must use SMTP (Simple Mail Transfer Protocol) - the protocol that governs how email traffic is handled. JavaScript run in the browser cannot access the ports that the protocol uses. This is to prevent attacks from malicious actors and spammers. You'll need to send your email data to an SMTP server.

Theoretically, you could write JavaScript that communicated with your own email server (like gmail) and send the email that way. However, you would need to pass through your authorisation credentials in your JavaScript code and that would expose those credentials to anyone running your code (just keying F12 would open up the browser debug function and the user would be able to steal your email credentials).

This is why you would need an intermediary service...

An intermediary service (which will charge you a subscription) is one that provides you with a JavaScript code library and an Authorization key that will allow your JavaScript client app code to communicate with the service via an API. You send the details of who you want to send the message to, what the subject is and then trigger a pre-defined email template into which you insert your message. You register your email SMTP server with the intermediary and it then sends the message via that email server. So the email comes from your email account but is sent from the client-side JavaScript.

Is it secure?

Surely, you ask "isn't the authorization code the intermediary service gave you exposed in the same way your email credentials would be?" Well, potentially yes! (there are ways you can make it a bit more difficult to get to - but it is a risk). However, since you can only trigger emails based on predetermined templates and they come through the SMTP server you specify then the risk is negligible. Some intermediary services also offer further checks and security restrictions to prevent a hacker triggering spurious emails maliciously.

If you are interested... Clearly, this approach is not trivial - but we have used it for a couple of our clients and it is working well. I can't put up a demo here because if you all viewed it, you would be sending emails to yourselves from my email server! But I may put up a video demo of it working on our website and post the link here if anyone would like to see it. Feel free to ask questions here in the meantime.