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?
I would set it so that your sales team is in a security group that can only see contact records that are say 'owned' or have a hidden contact field that is populated with the Sales Manager.
You could then do a similar for your comms team that could do a similar process
Thanks - at the risk of cross posting (still not sure which of the CRM forums is considered current?) - someone else suggested something similar - social.microsoft.com/.../different-types-of-contacts
My follow up to them was...
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...
I wouldnt really say there is a 'recommended' approach as such.
CRM as a concept is a living breath system for 'A' company that enables their users to do their day to day job easily and more importantly, efficiently.
When we train on CRM, we talk about this and how CRM can be used (with correct training and business management/process) as an open system so that everyone can see each others 'foot prints'
As you mention, day to day, they may not need to see relevant details about a contact, but sometimes may do.
We have the system currently setup so that (within reason) everyone can see everything should they need (read/write/edit restrictions) do apply but it enables them to do their job.
Alternatively, you could set-up some custom fields that show 'Key Contacts' for that contact/Account so internally if 'Bob' in Sales needs to ask a question, he knows who go to to internally to get the information.
Hope this helps
Okay, thanks for your thoughts - at the moment I feel that the pros of having them all in the one bucket outweigh the cons but will need to consider a little longer. Also interested in any other advice...
You can have multiple Contact Forms enabled with Security Roles.
normally this separation is done with Business Units (in order to prevent people to access to records they don't belong) and separate forms (switched using Security roles as suggested by Mithilesh Kumar)
My blog: www.crmanswers.net - Rockstar 365 Profile - Follow me on Twitter
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.
Stuart, you can have separate fields on multiple forms based on the Security Roles. The Common fields will be available on all forms and the specifics fields can be separated based on the accessibility you are going to define.
Sure - however suppose you have a Business Required option set field defined because it's necessary for one set of Contacts, clearly you will end up having to put an 'unnecessary' holding value in that option set that has to be defaulted to for any other types of contacts. This ends up with meaningless/misleading data for some of your contacts.
well, you can normalize your entity until a certain point, in the end you will end up in these situations if the same entity is used for different purpose.
This doesn't mean that the entity is badly built or there are useless fields.
Default or empty values needs to be defined and normally this kind of stuff will end up inside the documentation of the project (for example: Field A: holds the SSN for contacts of the medical department, field visible only on the Medical Form, the value is empty for contacts of other departments)