Share This:

When planning to install any multi-tenant capable application, like Remedyforce, there are many things to consider. One of the most impactful choices is whether to separate functional areas as their own entities or to manage them in a more hierarchical fashion.  On the platform, this comes down to a decision between single or multiple orgs, something customers often ask me about.

There is no "best answer" for this question, it all depends on what is going to be the best fit for your organization.  Below are just a few of the considerations that customers would need to be aware of while making these decisions.

Single Org -

Greater Management Visibility

–Allow for Reporting Visibility in a single location


–Provide insight into all user activity & account information

–Productivity tools such as Chatter

–Avoid duplicate effort & conflicts within accounts

Centralization and Standardization

–Utilization of existing centralized Application Administration & Change Control

–Integration Infrastructure

–Managing Data Cleanliness

Departmental Personalized Configuration Capability

–Granular security model, multiple profiles, records types, page layouts, sharing groups

–Translation Workbench



More Flexible Regional Personalization

–Each region can do what they want with no global constraints

–Lower likelihood of reaching configuration limitations

Simplified Configuration

–Minimize org complexity e.g. sharing rules, record types, etc.

Localized Change Management

–Local admin team can be more responsive to local users


Adoption of new features that are all or nothing

Here is a scenario that may help you determine which of these two options may work best for your organization


Customer 1 is a large multinational customer with an existing Salesforce instance.  This customer has 3 internal departments utilizing Salesforce today.  They want to add Remedyforce for their Internal Help Desk so that they can have all their Incident Tracking in one location, they want to utlize Single Sign On, and they also want to keep their data separate from the other groups that are actively working with Salesforce today.




Their options are to install Remedyforce into their existing Salesforce instance and create sharing rules for the Remedyforce objects.  This will allow for the customer to have a single Salesforce instance.  There may be some internal issues that will arise with this option.  The existing Salesforce administrators may not want to give applicable access to the Remedyforce Administrator to accomplish the functions that they need to perform to configure Remedyforce effectively.  The Remedyforce Administrator needs access not only to the Remedyforce objects, but the shared objects that would be used within Salesforce, i.e, Users, Accounts,Contacts, etc.  They will also need to create workflows and approvals which could be limited if the Salesforce Administrator does not give sufficient access.  If this is not a concern and the customer allows the Remedyforce Administrator full access to the Salesforce instance, the next thing to consider would be the sharing rules and role hierarchy within the organization.  Most customers have an existing role hierarchy setup, this gives access to the data within Remedyforce as well as the other applications running on the Salesforce instance.  If the role hierarchy does not fit into the Remedyforce schema, it may cause some issues with data that is being displayed.



Second option would be to have a stand alone instance of Remedyforce , which would be Multi Org for this customer.  Having a stand alone instance of Remedyforce would allow the internal Help Desk the flexibility to the Salesforce platform without having to contact the existing Salesforce Administrator every time they needed something change within Remedyforce .  They could setup their own role hierarchy specific to Remedyforce  that would allow for individuals to create Incidents on behalf of other employees.  Some things to be aware of in considering the multiple org environment would be that If you are not going to implement Single Sign On with the multiple Salesforce orgs, then you and the end user community will have to maintain separate User Ids and passwords across the multiple orgs.  Each User Id and Password must be unique across the Salesforce Platform. Also, Chatter functionality would need to be taken into consideration.  You cannot utilize Chatter functionality across multiple Salesforce Orgs.  This collaboration functionality would only exist between users on each Salesforce Org.

Hopefully this gives you an insight into the pros and cons of Single Org versus Multi Orgs. Again, there are many different scenarios that would go into making the decision that would best fit your organization and I have only highlighted some of the items to take into consideration.  This should at least get you on the right path to make the correct decision moving forward. 

Eric Cobb

Senior Consultant