Using one Salesforce.com instance for two organizations
Sometimes an organization needs to segment it’s data very clearly and essentially have two organizations using the same database. There are often good reasons where one organization needs a bright line between two divisions. This can be accomplished in Salesforce.com. Here’s what I’m building for a group I’m working on right now.
If you see any gaps in what I’m doing, I’d love to hear your comments. I haven’t had to build much security and sharing into my Salesforce.com implementations yet, so I’m surely no expert.
Set default sharing settings to Private
If you want to restrict access to data in Salesforce.com, you start by tightening things all the way down and then loosening them up where it makes sense to your model. By setting sharing to Private, we’re saying you can only see things you own.
Set up a Role Hierarchy that has two branches
Roles control what data Users can see, so we’ll use them to split the data down the middle. Right below the top level of the Role Hierarchy, create a Role for Department 1 and a sibling Role for Department 2. All Users will live in one of these two branches of the hierarchy.
Set Object-specific sharing rules for each branch of the hierarchy
For each object (like Account) create a rule that gives read-write access to all objects owned by Users in the Department 1 Role Hierarchy to all other Users in that branch of the hierarchy. You’re basically saying, share all my stuff with my side of the org, and they will do the same. Mirror that for the Department 2 side of things, and on all objects you care about.
Create Users, placing them in the right Roles
All Users must be in the Department 1 or Department 2 side of things. Systems Administrators must be in one of the two roles as well.
Create Profiles for the two sides
Create a Department 1 Standard User Profile, and a Department 1 System Administrator Profile. Do the same on the Department 2 side. We need the systems administrators for the Department 1 to only see Department 1 data, so we also have to remove their permission to “View All
Data.” This will only allow them to see the Department 1 data, whether it be in
the web interface, or when using the API. Do the same for the Department 2 sys admins.
Deal with Campaigns
As I’ve written before, Campaigns aren’t a first-class object, so you have to hack the data split a bit. Here’s what I thought I would do. Create two Record Types for Campaigns–Department 1 Campaign and Department 2 Campaign. On all the Profiles you use for the Department 1, make the Department 1 Campaign the only available record type. Do the reciprocal on the Department 2 profiles. But so far I haven’t been able to restrict visibility to the Campaign Record Types of the other side. I’d love to hear any thoughts about this one.
Like I said, I’m no expert on this. It seems like we’re very close, except for the Campaign piece. Is there any way to make Campaigns behave?
March 11th, 2007 at 3:49 pm
This sounds like it would work to me, good to hear the details.
But I guess I’m not clear on why this can’t be two separate instances. All of the users you describe here only have access to half the data, so I’m not sure why the two sides need to be in one database. Are there other users that will have access to both sides?
Or are there some objects that will be shared while most are segmented?
I don’t doubt that you have good reasons for doing it this way, just would like to understand what they are for the sake of wrapping my head around it.
Thanks!
March 11th, 2007 at 4:11 pm
There are a couple reasons for doing things this way. One is the cost of Salesforce.com. If you get a donation of 10 licenses, 2 orgs of 5 users could share the instance. I wouldn’t recommend doing this unless the two groups are very close, and maybe even legally connected (like a C3 and a C4).
Another reason to do it this way is you can create Users at the top of the Role hierarchy that can see everything. Two groups can have separate data but then there is an aggregated view possible. This is tons harder if the databases are separate instances–just ask the folks at the Salesforce.com Foundation who have their instance and use the company instance as well.
A third reason is one you pointed out, there may be some data they want to share. I’m implementing using Leads to hold a Voter File. Each org wants to use the voter file for their work. Sharing Leads to both orgs allows them to only have to keep one Voter File up to date.
March 12th, 2007 at 3:54 pm
Isn’t this similar to a previous question (here I think) about having various chapters of an org share the database but see only their own data?
A further advantage to the sharing you’ve described here is that all customization, reports, etc are done just once. If you had two instances, you’d have to build two sites.
March 12th, 2007 at 4:22 pm
And it’s amazing how long those customizations take, no?
March 13th, 2007 at 1:07 am
This is just off the top of my head, but if the Campaigns is not so much a privacy issue as just being able to separate out the data, you could at least set up two different Views, filter criteria, etc…
March 13th, 2007 at 6:45 am
It would be easy to set up one picklist that identifies a Campaign as belonging to one or the other division of the org, but I want to go farther than that. I would like the data to be private to each division. Any idea when upgrading the Campaign infrastructure is on the road map? I also have some ideas about how to make the CampaignMember table more useful. I’ll write a post about it when I get a chance.
April 24th, 2007 at 1:54 am
great post.
have an org with same type issue - except they have about 10 different projects going under one umbrella org with top role needing to see all data, sub managers see various projects, and employees seeing only their appropriate info. record type via page layout, via FLS, via profile can become a nightmare but all workable. even campaigns, i had incorporated a lot of what steve has here. my one issue we just could not get around ws when you choose a campaign to associate a contact with you get a nightmare picklist. now with apex we can clean it up a bit - ie if campaign close date a year ago, deactivate. but we have no way of customizing that picklist. Steve - in your campaign dream list (which I LOVE!) could you incorporate something like what we have with lead status process - similar idea that for a specific record type/profile - choose their campaign ‘division area’ so when they see that picklist they are only viewing their divisions campaigns.
keep posting - i love reading