We discovered the reason for this. In this case the client wanted centralized contact management. Meaning they did not want the ability for any of the end users to be able to update the contact record other than through a central admin user to protect the integrity of the contact data. They were not satisfied with data audit or alternative workflow/notification options.
And in addition they also wanted the ability to have the contacts be synced with the end users' Outlook clients. Since there is nothing preventing a contact from being updated in Outlook via the end users, we had to prevent any contact updates from hitting the CRM server during the syncing process by removing the contact update privileges from these end users.
And therein lay the problem with the contact icon. The following is a scenario where a CRM contact in Outlook can have it's contact icon flip back and forth between the standard Outlook contact icon and the CRM contact icon:
- The Outlook client user actually updated one of the CRM contacts in Outlook.
- During syncing the user would first get a permission error (that can be ignored) and then the icon would change to a standard Outlook contact icon (as the sync process would presumably think that since the contact can no longer be updated that the contact is no longer a CRM contact).
- The icon will remain a standard Outlook icon until a change is made again to the contact on the Web client at which time the change would be synchronized to the Outlook client and the contact icon would update again. Note that a duplicate contact would not be created since even though the contact was no longer showing as a CRM contact in Outlook, the CRM contact GUID wherein the actual link to the CRM server contact is housed, would remain intact and hence the sync process could still locate the contact record in the client.