■

Simpplr is a platform built on Salesforce. For customers who already use Salesforce as a CRM or for any other means, Simpplr will be installed in its own instance of Salesforce and will not be installed on your existing instance.

To make the most of your Simpplr implementation, we strongly recommend having a
separate Salesforce org built to host the platform rather than deploying Simpplr on existing
implementations.

Below are a few reasons why:

1. A separate org is faster to deploy and upgrade: In a separate org, we don’t have to
   worry about Simpplr impacting existing Salesforce apps, customizations or components.
2. It provides a clean separation from existing Salesforce and Chatter use: A separate
   org will separate existing Chatter discussions that likely are not relevant to the intranet,
   keep our discussions off of other existing Salesforce objects, and prevent duplicate
   Chatter emails or mobile notifications.
3. It’s easier to manage administration and permissions: Typically intranet admins are
   different people from CRM admins. A separate org ensures sensitive information is not
   inadvertently at risk and gives the intranet administrator tighter control over intranet
   permissions, profiles, site structures and ownership.
4. Search will not pull in irrelevant results from existing Salesforce data: Oftentimes we
   see in a combined org that old chatter posts or files show up in search results, and
   App managers cannot delete them because they're not tied to Simpplr.

Pros of having a new org installed:

1. You won’t need another Salesforce admin: Administering Simpplr is very easy (both
   within Simpplr and on occasionally on the backend with Salesforce). Once Simpplr is
   implemented, Salesforce configuration is minimal. Your designated Simpplr System admin will handle most of (if not all) Simpplr/Salesforce configuration.
2. You don’t need to buy additional licenses: Simpplr’s licenses cover the underlying
   Salesforce access. Separate orgs will not impact pricing.
3. Intranet managers can be more self-sufficient and have less IT dependency because they can be given system administrator rights. This allows them to better manage the intranet. For example, Salesforce requires System admin rights to change user photos, delete or add a new version of files uploaded by other users, or access private sites they do not already manage. But you could not give intranet managers System admin rights to your production Salesforce org, which stores confidential sales and customer information.
4. It's guaranteed that there are no adverse interactions with other installed packages or customizations.
5. Simpplr puts triggers on the user object, and so do other packages, such as Marketo. Sometimes these triggers can interfere with each other when tied to the same instance.
6. Simpplr will be easier to test, deploy and upgrade. This means shorter testing cycles because there is no need to test interactions with other installed packages. In addition, you'll have faster deployments and upgrades because less testing is needed.
7. Simpplr search yields more relevant results, weeding out the possibility of old Chatter files or posts on non-intranet objects.

Deploying Simpplr on your existing Salesforce instance does have its pros as well, including:

1. You will only have one Salesforce instance to administer and manage.
2. You can convert your existing Chatter groups into sites within Simpplr.
3. Simpplr Lightning components allow you to add the Simpplr carousel and content to Lightning
   dashboards.
4. You get increased Salesforce storage with Simpplr licenses (20MB/user for data, 2GB/user for files).

However, you may run into these issues:

1. More complicated and longer testing, deployment and upgrades.
2. More IT dependency. Intranet managers require System administrators for some
   common tasks as described above.
3. Harder to manage. Salesforce profiles and permissions become more complicated because
   you need to integrate Simpplr permission sets with existing profiles and
   permissions.
4. Users may get duplicate notification emails, which are annoying and which can reduce
   adoption as users then disable notifications. Duplicates happen if users want Chatter
   notifications for non-intranet objects such as opportunities as well as intranet notifications
   for things such as new articles or must reads. Users may also misconfigure their
   notifications, which also results in duplicate emails.
5. Potential interactions with existing triggers, installed packages and customizations as
   described above.