Occasionally, I encounter a customer who has absolutely no need to track Leads. They start the relationship using Accounts and Contacts. In order to maintain a clean user experience, we usually just remove all rights to the Lead Entity so that it will be removed from the CRM user interface.
In CRM 3.0, this practice works as expected and produces few, if any, side-effects. However, with CRM 4.0, we have run across an interesting issue associated with email tracking. Depending on how you configure email tracking, CRM can automatically track an email without using the CRM tracking token by locating the email address within CRM. It does this by performing a search within Leads, Accounts, and Contacts.
The problem arises when you have access to Leads disabled. Outlook ( or more correctly, the CRM Add-in ) will start generating errors related to security, permissions, etc. because if you don't have at least read access to an Entity, you can not query against it.
1) Modify the various Security Roles and remove all access from Lead with the exception of Read.
2) Export the SiteMap.
3) Modify the SiteMap using WordPad or Visual Studio. For each location where you find Lead, you will need to add a Privilege Node, as shown below:
<SubArea Id="nav_leads10" Entity="lead" DescriptionResourceId="Lead_SubArea_Description">
<Privilege Entity="lead" Privilege="Write" />
</SubArea>
4) Import the modified site map.
By removing all privileges from the Lead Entity ( with the exception of Read ) you effectively remove from the users, the ability to create new Leads. Leaving Read access enabled allows the CRM Client to properly query Lead for emails. None will be found, of course, since there is no data, but it will not generate an error.
Modifying the CRM SiteMap allows us to remove the Leads Entity from the CRM user interface. The Privilege node we add to each instance of Lead instructs CRM to only display the Lead Entity if the user has the Write Privilege. Since users only have the Read Privilege, this effectively removes Leads from the UI.
If you would like to carry this further, you may also wish to modify the Account and Contact forms to remove the references to Originating Lead.
One Response
Maged M. Assabri
03|Sep|2008 1I'm facing a similar problem, and i tried your solution to solve it but no luck.
i posted it in the CRM newsgroups but i didn't get any answers.
i'll post here for you in case you have any solution.
thanks.
I configured some security roles for my client to fit his security policies.
However all the users assigned one of these roles can’t use track in CRM
option in the Outlook client.
When I tried to give them some access rights to leads and contact and
accounts it works, but this is not accepted at all by our client or by us or
by logic, because some users should not have access to anything but the cases.
I was thinking that track in CRM feature is depending on (the user have
access to any entity that can have e-mails related to it) and I think it
should be that way.
Consider this scenario (A support user don’t have access to leads, accounts,
contacts and opportunities, because they are support users for internal
helpdesk, but they have access to Cases, so they should be able to track
e-mails to cases ONLY).
Making track in CRM depending on access rights to customers records, leads
and opportunities elements the possibility to create security roles to fit
some scenarios as mentioned above, and this is a disaster.
If anyone knows what is the least required privilege to be able to use track
in CRM feature please provide us with that information.
And I think Microsoft should document these dependencies somewhere.
Leave a reply