Summary:

A customer may have a requirement to install Self Service on a separate web server to their main CRM web server. This would be the case where (for example), Self Service is to be placed on a server on a DMZ, while CRM is to be kept on the internal network.

This is a supported configuration; in effect, another copy of CRM would need to be installed on the server hosting Self Service.

More information:

The CRM Self Service Guide, states the following:

Prerequisites for Self Service Implementations

To run CRM Self Service you will need:

  • CRM installed on the same server with a valid Self Service license key.
  • The same server software as for a typical CRM installation. Refer to the System Administrator

This raises the question of whether running Self Service on a separate server is supported.

Self Service can be installed on a separate server by, in effect, installing another copy of CRM. This is supported, though there are a number of considerations that will need to be taken into account.

Self Service architecture 

The above diagram shows that two installs of Sage CRM are needed to allow the Self Service site to be housed on a web server beyond the corporate firewall.

The Self Service database (containing the Visitor and VisitorProfile tables) can be hosted on a different SQL server to the main Sage CRM database which holds the application and metadata.

The system administration documentation further discusses Self Service installs, and how the main CRM systme can exist on a separate server.

https://community.sagecrm.com/adminhelp/Default_CSH.htm#Self%20Service/SA_SSConfiguration.htm

The architecture detailed in the above diagram is supported by Sage with the understanding and warning that the architecture requires careful change control management.

Considerations

  • Licensing considerations are a matter for the local Sage office.
  • Metadata for the definitions of the Lists and Screens referenced by the Self Service install reside on the main CRM server's database.  Metadata is only loaded on the initial instatiation of the Self Service object. Since there would be no facility to automatically update the metadata on the Self Service install, any changes made to screens, lists, fields or views that are used by Self Service would require a restart of the Self Service application pool. The Self Service installation should not be affected by other metadata updates, such as changes made to email templates, reports, other CRM screens, etc.
  • Patches to the self service server would have to be manually coincidental with the patching of the main apllication server. The Self Service server, as a secondary instance of Sage CRM, would have to have patched as any install of Sage CRM.  This is not an automatic process.