SugarCRM SupportKnowledge BaseEmailEnabling Sugar Email Archiving

Enabling Sugar Email Archiving


With Sugar Email Archiving, messages sent to a special email address are automatically copied and linked to corresponding Sugar records. This allows for archiving from any email client without the use of a plugin or other syncing process. The service is available for commercial editions of Sugar. For more information about the service, please refer to About Sugar Email Archiving.

Note: This article pertains to Sugar versions 6.x and 7.x.

Steps to Activate

To activate Sugar Email Archiving for your instance:

  1. Navigate to Admin > Email Archiving.
  2. Read and agree to the privacy agreement.
  3. Click "Enable Email Archiving".
  4. Please note your instance's unique archiving email address via the Email Archiving Address field.
    View EmailArchivingAddress

When email archiving is enabled, you can include the unique email archiving address in the To, CC, or BCC field of any email. When you send the message, Sugar will automatically archive the email to your database and link it to any records that have a matching email address.


For activation problems, please check the following:

One Activation per License Key

Email Archiving can only be activated for one instance per license key. If you have a test instance with Email Archiving activated, deactivate the service on your test instance before attempting to activate Email Archiving for your production instance.

On-Site Instance Accessibility

Our Email Archiving servers can only work with your instance when it may be reached over the internet. Specifically, the URL http(s)://{site_url}/service/v4/rest.php needs to be accessible from our On-Demand IP addresses, and (or, with a subnet mask, and

Site URL Configuration

For on-site instances, please make sure that the site_url specified in your config.php is set correctly. This site_url value must match the publicly-accessible URL.


For on-site instances, certain firewall setups may block the activation request.  You can try temporarily disabling the firewall and attempting the activation again.

Load Balancer/SSL

SNIP supports both plain-text HTTP communication as well as encrypted HTTPS communication when properly configured. The registration process is a multi-step process that relies on several settings from the application configuration as well as the web server request environment in order to successfully complete.

When front-end proxies or load balancers are used to handle load balancing and/or the SSL offload, additional configurations must be done in order to make sure the request environment is correct:

  • The config settings for site_url and host_name must match the public name and protocol of the instance.
  • The proxy must correctly pass the Host: header to the backend server(s) and the backend servers must have the correct virtual host (vhost) setup for that name.
  • If SSL is being used, the SSL certificate must be a fully valid certificate signed by a well-known public Certificate Authority (CA) and include proper chaining as needed. Private certificates/CAs are not supported.
  • If the proxy is performing an "SSL Offload" where it passes only HTTP traffic to the backend servers, it must make some distinction between HTTP and HTTPS requests and pass that distinction on to the backend server. If the backend server does not understand between HTTP and HTTPS requests, it will default to generating HTTP URLs in the OAuth token, regardless of the site_url setting.
  • HTTPS distinction can be performed in a number of ways for the Apache web server, for example:
    • Insert the header X-Request-Was-SSL: Yes into the request when sending it to the backend servers and use SetEnvIf to set HTTPS to "on" if the header is there.
    • Run an additional vhost on a separate port of the backend server(s) that uses SetEnv HTTPS on to imply HTTPS, and direct the HTTPS-offloaded traffic to that port from the proxy.


Last modified: 2017-07-05 10:53am