Maintaining Two Separate Sales Divisions Within CRM? RRS feed

  • Question

  • Let me see if I can give the short version:

    I'm the acting CRM Admin at my media company, which contains two completely separate Sales Divisions.  One sells one type of product and the other sells another.  The products have no real relationship to one another from a technical standpoint. 


    We currently have one Sales Division using CRM 4.0, with loads of custom entities and attributes, soon to be upgraded to 2011.  The other Sales Division is to be introduced to CRM 2011 for the first time in a few weeks.


    We have one IT, one Marketing and one Research Department, as well as one set of upper-level execs, all of which support and interact with all Sales Users on a global level. 


    We currently have each Sales Division set up as its own Organization on two separate instances of CRM, but I am starting to think this isn't the right solution.  From an Admin standpoint, I don't see how maintaining and supporting both environments will be feasible and Execs will have to log into two different environments in order to see each Sales Division's progress.  Also, there may come a time down the line where we will want users from both Sales Divisions to interact with one another.


    My questions are: 

    1. What is the best practice here?  Is having two separate Organizations appropriate?
    2. Can I make entities and attributes only visible to certain business units?  If so, is there an easy way of doing this?
    3. Do companies typically enter their IT department into CRM as its own Business Unit? What are the pros/cons of doing so?

    Thank you!


    Friday, August 5, 2011 1:03 AM

All replies

  • 1. We have come across this many times and unfortunately you are correct in that splitting up the organizations makes it more difficult for executives to get a full picture of the business. It also makes it difficult for shared marketing and support personel as well as they then have to market to two different sets of data or look up a customer in two databases. In this case I would make each sales org a discrete business unit underneath the global organization. Assign the appropriate sales users to the correct organizational unit and then ensure that their user roles only allow them to see data within their own organizational unit (or further down their organizational unit).

    2. This is all based upon the security role. You can make security roles specific to a business unit and disable the entities with which they don't need to have access to. You can also enable field level security (only on custom fields however) so that only the fields that pertain to their role are available for them to see. Finally, you can create custom form layouts and assign them to those specific security roles that you created for the business unit that will allow you to tailor a form design for that set of users.

    3. Being in a seperate business unit only really matters if your security role locks you down to the information stored within. In most of the businesses I have worked with, the IT group typically has organizational read access. You might consider putting them into their own organizational unit if they have specific contacts/accounts/other entities that pertain only to them and you want to curtain those records from the other users. You might want to do this if you end up implementing service tracking for technical support issues within the organization to limit the view that other users have of those tickets within the system.

    • Proposed as answer by Rob Wenstrand Friday, August 5, 2011 2:05 AM
    Friday, August 5, 2011 1:54 AM