Personally, I'd suggest you not separting them and instead mimicing 2 different databases (from an end user perspective) while allowing you to administer a single Salesforce environment.  Having a single Salesforce environment will make life easier for you as you add apps to it whose access may need to cross the 2 user groups you have in there today (e.g. an Expense system or mapping tool).

You need Enterprise or Ultimate Edition to do what I am talking about.  It's not that hard, but takes some thinking by your admin.  Areas to look at are:

1. Set all your Default Sharing Settings to Private
   
2. Create 2 Parallel Role Hierarchies
3. Do whatever sharing rules you need to share data amongst each hierarchy.  Once you've completed this, you have essentially split your database in 2, but all within a single Salesforce org.
4. OPTIONAL You want want to have 2 sets of Profiles for each user group so you can administer them easily.  Have a profile naming convention to make this each (e.g. Profile Name = Usergroup.Purpose (e.g. Sales.Rep))
5. OPTIONAL Use Field Level Security to hide fields from the groups that don't need to see them.  This helps lessen confusion so users don't see fields of other groups in the UI or when creating reports.
   
6. OPTIONAL Create separate page layouts for each group.  If you use Field Level Security correctly, you might be able to share the layout and let FLS remove fields from it based upon their visibility settings.
7. OPTIONAL Separate your reports and dashboards into folders that only certain groups can see (basd upon role or public groups)

Completing step #3 will get you where you want to be.  There is really no reason to split the database in 2 unless the user groups are from completely separate companies that have no relationship to one another.  If any of the 2 groups use similar internal functions that you might want to bring into Salesforce or if they may both benefit from an app on AppExchange, then I'd suggest keeping them in the same org and use Enterprise or Ultimate Edition and the above steps.

I wouldn't recommend having any of those users actually conduct their business in a Sandbox environment (like another replier suggested).  It will come back to haunt you someday.  You won't have as good an SLA from Salesforce on that.

Thank you so much for this reply - it really is helpful!

Yes, that all sounds great, and since I am admin I think I could do all of that.

The only problem that we see in keeping it together is many duplicates: since one sales group sells to local sites (<1B), and other group sells to HQ (1-5B). That creates many dupes by name, and also many incompletes since it is not essential for them (small group) to verify the data they enter, and for us (large group) is essential.

Also, how will your suggested solution reflect on reports (used for marketing purposes for example)? And also what will happen with any new data import? Where it will go? If for example you have JP Morgan Chase as a HQ and many (many) local branches and then you purchase a list on contacts…. To which account record they will get uploaded?

How about mass transfers, and other similar tasks?

Sorry if I am asking too much, but customer support also have a struggle in finding the best solution, and I know that we are not the only company with this issue.

 

Thanks so much….

 

Well, I understand your dilemma a bit more now and I still say that your starting point should be making it work within 1 org, if possible.  In keeping with 1 org, it sounds like you'd also need to use Record Types to help segment your data.  Doing this will allow you to use the Record Type field as a factor in Validation Rules for Large Group and in reports to ensure data is filtered properly.  This field along with the Role of the Owner would be important for groups that see data spanning sall and large group (e.g. Marketing).  From the sales user perspective, they won't even know of the confusion you deal with at the admin level b/c they only see what they are supposed to see based upon the role hierarchy and sharing rules.

As for data uploads, you will have the same problem whether in 1 database or 2.  This comes down to your business process and how you define an "Account".  Salesforce only goes so far and is really just a database to store the data.  You'll need to come up with some convention for uniquely identifying an Account record in order to know which Account to link imported Contacts to.  When you buy a list, those sources don't know your rules and don't have your customer numbers, so you can't match things up easily.  Like I said, this problem will exist regardless of database you load into (1 or 2).  When buying a list, you'll need to ask yourself which group this applies to.  This answer will help you define a record type to use and you now have 1 more filter to help you match to an Account.  At this point, it's the same as being in a different database.  You still need to match the rest.  Some options are:

• Import it as new and then use a tool like Demand Tools to merge Accounts as your next step.  That tool offers a lot of capabilities for matching including fuzzy logic.
• Do the best matching you can and create new Accounts for the rest and use Demand Tools to help merge accounts.
• Look into something like D&B to scrub the lists you buy and append their DUNS number onto the records.  Use the DUNS number as your matching criteria when loading.

I guess it all comes down to a matter of preference.  Based upon my experience, it's better to try and stick within a single org if you can.  A lot of the questions you have won't go away by having 2 databases.  The only distinction between them is Large Group vs. Small Group.  And I can all but guarantee you that your executives will be asking for Enterprise Reporting showing Large and Small Group in the smae report.  This request will lead to you either combining your databases or making a 3rd that acts as a data warehouse.

So my suggestion is to do config work and think about things like naming conventions to make your job of separating the data easier from the Admin / Marketing / Executive perspective.

If you must get a 2nd Org, you might want to ask Salesforce to "clone" the one you have and make a second.  Then delete the stuff you don't need from each org.  Depending upon your situation, this might be easier than starting from scratch.