locked
Different types of Contacts RRS feed

  • Question

  • Hi

    We have a CRM that is mainly used by our sales team in managing their client relationships and consequently the Accounts\Contacts sections are filled with their data. In addition we have other, smaller teams - eg communications, exec office etc - that also have contact records that they'd like to manage. Does anyone have any advice on the best way to manage these records that all share common contact-like features and yet in various ways need to be kept secure and separate etc. I'm aware we could use different crm instances and/or different business units and/or custom entities but I'm also aware of the drawbacks with each of these eg outlook client can only integrate with one instance, custom entities lose out on core tracking functionality etc etc.

    What do people generally do in this situation when needing to house different types of contact record?

    Thanks

    Tuesday, February 24, 2015 11:24 AM

All replies

  • Hi 500,

    Simply you can create one new field on both Account and Contact entities to separate which team has created that record. For example you can create field with name Division on account and that will have your teams as drop down options and tell your teams whenever they create new account they need to select there Division.

    After that you create views with filter criteria of division for each team so that they can view there accounts separately.



    Deepak Jangra

    Tuesday, February 24, 2015 1:26 PM
  • Sure, thanks - that's one way. Do others do this? Is this a 'recommended' approach? What happens when one contact class requires certain mandatory fields or associations with other records (eg accounts) that would not make sense for the other contact objects? Do we just go ahead and have to create 'holding place' values to satisfy these other records?

    My ideal, I think, would be for CRM to cater for subclassing a generic Contact record but I'm not aware of this functionality in the pipeline...

    Tuesday, February 24, 2015 1:37 PM
  • Hi,

    We do something fairly similar ourselves and we manage it with business units and multiple security roles. These roles apply to the various business units to determine how they behave within these teams.

    So, for example, any accounts or contacts that are owned by a sales person can be read by anyone in sales but only written to by the owner. They also don't have visiblity of any other business unit's accounts. However, tech staff need to manage their own contacts but also create work records against sales's accounts can see everything.

    To be honest, I don't think there's going to be any other way to accomplish this. I would have said that the recommended approach to limiting access is done via security roles and these are closely linked to the business unit set up.

    Field level security is another area to consider but, from what you've said, I don't think it would be relevant here.

    Wednesday, February 25, 2015 11:38 AM
  • So the consensus seems to be store everything in the Contact\Account buckets and to use BUs and security groups etc. That's fine because we've, to date, chosen that method. The purist in me is still a little uncomfortable with having some mandatory columns that won't mean anything for some types of contacts\accounts etc but I guess we just have to fill them with holding values as necessary.

    Thanks all.
    Wednesday, February 25, 2015 11:52 AM
  • Don't forget you can use business process to make fields mandatory only for certain types of contacts/accounts.  That way they're only filled out on relevant contact types.

    The postings on this site are solely my own and do not represent or constitute Hitachi Solutions' positions, views, strategies or opinions.

    Wednesday, February 25, 2015 5:09 PM
  • and.. if you have distinct groups of users who want/need to enter different data for their particular contacts, you can build specific forms that show different fields with differing mandatory/non-mandatory states then enable that form for a particular security role.

    As a general design tip when using multiple forms, try to 'lock' a single form to each security role. That way you aren't relying on the end user to remember to toggle the form. Forms are 'sticky' meaning the last form you use gets remembered and displayed the next time you open a record from the same entity.


    MCTS. GAP Consulting Ltd. Microsoft Community Contributor Award 2011 & 2013

    Thursday, March 26, 2015 9:38 PM
    Answerer