Saving attachments as Content documents has the advantages of file duplicates prevention in Salesforce storage and file keeping optimization, so it is the recommended way, while the other way is only used when saving attachments as Content documents cannot be enabled.

For Admin level/setup information about handling of attached files, please refer to this article.

Note

Pay attention that SmartCloud Connect does not share in Salesforce items attached to emails as OneDrive or another cloud location links or ones added to the message inline.
There is also another limitation on saving of attached files: email attachments cannot be saved in Salesforce from an email opened in Compose mode.

Please note that several specific aspects of attachment saving/linking mechanisms can be adjusted upon request sent at [email protected]; the patterns described in the article are valid for default setup.

If the attachment is an image (only .jpg and .png formats are supported), you can click the 👁 (preview) icon next to it in the Save attachment dialog to preview the image.

>>> Click to expand <<<

If you save an attachment by assigning the Salesforce category to the email/event containing it, it will be shared in Salesforce by SmartCloud Connect synchronization. In this case the attachment can be linked only to the corresponding Task/Email message object, while the Task/Email message itself will be linked via the Name and Related to fields to the relevant Lead/Contact and Account and available Case or Opportunity records (with linking to Opportunities enabled) found by SmartCloud Connect Initial Search, and the record Owner’s profile.

Note that unlike in the case of manual email/event saving (see point ( 1 ) ), there is no way to get the “default attachment” (the email message in .eml format) saved when the email is shared in Salesforce by synchronization.

If email/event autosharing is enabled in sync settings and an email/event containing attachments is received from or sent to a known (registered in Salesforce) contact, on the following synchronization session the email will get shared in Salesforce along with the attachment(s). In this case the linking patterns will be the same as in point ( 3 ). Note that auto-sharing of messages containing attachments should not consume an excessive amount of Salesforce storage space since prevention of storing of duplicates and specific file type/size filtering is applied.

Note

Please pay attention that the patterns described in points 3-4 are only applicable for saving attachments as Content document files; if Attachment objects are used instead the files will be linked only to the corresponding Task/Email message object.

save an exact copy of the email message including all technical data and headers, for example to use it as legal evidence

if Salesforce Enhanced email is not enabled in your Salesforce Org and you need to save special HTML formatting in the email (e.g. inline tables, diagrams, and so on), or the email’s body exceeds the 32,000 characters limit and you need to share the message in Salesforce without truncation applied

in these cases you can attach an exact copy of the message in .eml format to created Task or Email message Salesforce object, to do that select the checkbox next to the “default attachment” {email subject line}.eml generated for every email message; note that you can also rename the .eml file according to your preferences.

Important

Please note that an email attachment cannot be auto-shared in Salesforce by SmartCloud Connect synchronization in the following cases: 1. if it exceeds the file size limit in Salesforce, 25 Mb for a single file; 2. if the file’s extension is blacklisted in the Global settings managed by our Support team or is not whitelisted in local Admin panel settings. However, in the latter case the file can be shared in Salesforce manually.

Note

Please note that with Salesforce Enhanced email enabled, due to a technical limitation, when you save an email along with its attachments in Salesforce via the Add-In, the created Email message object’s HasAttachment field does not convey accurate information about the presence of these attachments, so this flag/field should be disregarded.