Author note 8/16/2010—when this post was written, there was a potential conflict with having contacts and users with the same email address—this conflict has been resolved in update rollup 12.
Many people use Microsoft Dynamics CRM to manage contact information for people outside of their company and provide a central address book of business critical external contacts; however, what about internal contacts?
CRM can also be a very useful tool for internal contact management. Like with external contacts, there is huge benefit to having a central shared address book of internal contacts with up-to-date contact information. Sure you have the Exchange Global Address Book; however, this typically is not updated frequently and does not always contain complete information, such as telephone numbers.
There are a couple of main approaches for managing internal contacts in CRM, and the one that you choose should be based on your requirements.
User Records
If your company uses CRM, you already have a start on user contact record management—the User record. This record is used to control access to the system, but it also serves the purpose of recording employee contact information. Like contacts, users can be included as recipients or attendees on appointments.
But, as much as we wish they would, not all employees use CRM, and most companies don’t want to buy user licenses for employees who don’t use the application. How do you manage contact information for non-user employee contacts?
Administrative Users
In Microsoft Dynamics CRM 4.0, there are several type classifications for users:
- Full
User will have full access to any part of Microsoft Dynamics CRM that he or she has the security roles ( Defined sets of privileges. The security role assigned to a user determines which tasks the user can perform and which parts of the user interface the user can view. All users must be assigned at least one security role in order to access the system. ) to access. - Read-Only
User will have read-only access of Microsoft Dynamics CRM that he or she has the security roles ( Defined sets of privileges. The security role assigned to a user determines which tasks the user can perform and which parts of the user interface the user can view. All users must be assigned at least one security role in order to access the system. ) to access. - Administrative
User will not have access to Sales, Marketing, and Service areas. This access mode allows your organization to create an account for a member of the IT department for administering and customizing Microsoft Dynamics CRM without using up a seat from your Microsoft Dynamics CRM license.
With that in mind, the following approach will allow you to include your non-user employees in the User entity without giving them access to CRM or adding to the cost of your licensing:
- Add the non-user employees as users in CRM
- in the Access Mode picklist select “Administrative”
- Save the user record, but do not give them a security role
Now non-user employees will be in the user entity, and can be selected as activity parties, but won’t have a license fee or be able to log in to the system. The nice thing about this approach is that all internal contacts will now be in one place. I like to add a link to the user entity from the workplace and give it the title “Employees.” This makes logical sense to most users, as they know to look in Contacts for external contacts and Employees for Internal contacts.
On Monday I’ll post about an alternative approach for scenarios where you want to have internal contacts synchronize with Outlook.
Hi Joel, the downside of using user records instead of contact records for employees is that:
* User records cannot be synced with Outlook, and some users love to be able to sync contact records for their colleagues as well as customers
* User records cannot be added to a list, and some users love to ensure that some colleagues get the same marketing information that customers do
Given these restrictions, and now that Update Rollup 12 finally fixes the problem of missing Outlook appointments when the same email address appears in a user record and a contact record, perhaps it's better to have contact records for all users?
Posted by: Neil Benson | August 11, 2010 at 11:20 AM
Neil,
You are right--I had dealt with those points in part 2 of this post.
Also, re Update Rollup 12, you are correct. Just wrote a new update to this post, and now that the conflicts have been resolved, this is a better way to go.
Posted by: Joel Lindstrom | August 17, 2010 at 03:52 PM