Use case: Send transactional emails with attachments transactional-email-with-attachments
The purpose of this use case is to add email attachments on the fly to outbound dispatches.
Key steps key-steps
In this scenario, you will learn how to send transactional emails with individual and/or personalized attachments. The attachments will not be pre-uploaded on the Transactional messaging server: instead they will be generated on the fly.
When you capture customer interactions or details, you may need to send this information back to the customer at the end of the process, for example in a PDF file attached to an email.
Below are the main steps of this scenario:
- The customer enters the website, finds a product that they want to purchase.
- The customer selects the product and customizes some options.
- The customer completes the transaction.
- An email is sent to the customer confirming the transaction. Because it is not recommended to send PII (Personally Identifiable Information) out in the email, a secure PDF is generated and attached to the email.
- The customer receives the email and its attachment containing the relevant data.
In this scenario, the attachments are not pre-created, but added on the fly to the outbound emails, which offers the following benefits:
- This allows you to personalize the content of the attachment.
- If the attachment is associated with a transaction (as in the example scenario described above), it may contain dynamic data that is generated during the customer process.
- Attaching PDF files optimizes security as you can encrypt them and send them over HTTPS.
Recommendations and guardrails important-notes
To avoid performance issues, images included in emails cannot exceed 100 KB. This limit, set by default, can be changed from the NmsDelivery_MaxDownloadedImageSize option. However, ÃÛ¶¹ÊÓƵ strongly recommends to avoid large images in your email deliveries.
ÃÛ¶¹ÊÓƵ also recommends to limit the size and number of attached files. By default, you can only add one file as an attachment to an email. This threshold can be configured from the NmsDelivery_MaxRecommendedAttachments option.
Learn more in the list of Campaign Classic options.
Before implementing this scenario, read carefully the guidelines below:
- The Transactional messaging instances should not be used to store, export, or upload files or data. They can only be used for event data and related information. They should not be considered as a file storage system.
- Since there is no direct access to the Transactional messaging instances or servers outside of ÃÛ¶¹ÊÓƵ, there is no standard way to push such files on these servers (no FTP access).
- It is not contractually correct to use the disk space on the Transactional messaging instances to store files of any sort, not even for attachments.
- You need to use another online disk system to host these files. You need an FTP access to this system and you must be able to write and delete files.
Implementation implementation
The diagram below shows the different steps when implementing this scenario:
To add an email attachment on the fly to a transactional message, follow the steps below:
-
Start by designing your attachment. For more on this, see this section.
This allows you to have the files attached to an email, even if they are not hosted on the execution instance.
-
You can send emails via a SOAP message trigger. In the SOAP call, there is a URL parameter (attachmentURL).
For more information on SOAP requests, see Event description.
-
When designing your email, click Attachment.
-
In the Attachment definition screen, enter the SOAP attachment parameter:
code language-none <%= rtEvent.ctx.attachmentUrl %> -
When the message is processed, the system will get the file from the remote location (third-party server) and attach it to the individual message.
Since this parameter can be a variable, it should accept the fully formed remote URL variable of your file, sent via the SOAP call.
