When configuring security roles in Dynamics CRM, a system administrator is situated between Scylla
, allowing users things they shouldn’t do, (and, believe me, the users will do it very soon once permitted) and Charybdis
, blocking users’ work. And K.I.S.S. advices, like leave only read permissions just to the entities we use, or use only out-of-the-box CRM permissions, or their copies with minimal changes may lead the user to one of these beasts.
To perform an action within CRM, the user may need various permissions that don’t necessarily link link with each other, and which are located far away from each other in the user interface Security Roles.
To choose the right permissions you need an understanding of processes within Dynamics CRM.
This post lists the minimal permissions for several important functionalities of Microsoft Dynamics CRM and explains the backgrounds of them.
In general it is advised to test each new security role with an alter ego user having this role.
- Business Management – User Settings – Write – User
Even if you create a 100% read-only user, let him write his user settings. If a user doesn’t have this permission, on the first login he gets an Insufficient Permissions error, because CRM cannot set & save his default entity in UI.
If you still have a good reason for blocking users to save their settings (via Tools - Options), you can block this permission. But then you have to follow these steps for every new user:
- assign System Administrator security role to the new user;
- log in as the new user;
- in Tools – Options slect the default enityt for the user(e.g. Accounts) and save user settings;
- log off;
- remove System Administrator security role and assign the actual security roleto the user.
Create an Activity
Looks simple: Core Records – Activities – Create – User. After it, the user can create an activity. But when saving, the user gets an error message The logged-on user does not have the appropriate security permissions…. First of all, activities require Append To rights (don’t ask me why). Good enough for tasks.
Letters, faxes, phone calls and e-mails always have another party: a lead, a contact, a user (to send correspondence to your colleagues), and possibly an account. They have to be appended to other entities, so they need Append rights. And recipients’ entities need Append To.
It goes well with all types of activities except appointments. On saving an appointment, the user gets the same error message, followed by General Failure in Scheduling Engine. The first error happens because other users will not see the appointment if it is not shared. The second means that all appointments in the CRM have to be checked with the service calendar for availability, even if users don’t use the service calendar directly.
Add Core Records – Activity - Share (at least for business unit, not just for user) and Service management – Search Availability permissions and get it working:
Track an Activity in CRM
Was the above adventure enough to track Outlook entities in CRM? Oops, we get The logged-on user does not have the appropriate security permissions… again. Business Management – Sync to Outlook? Right, but not sufficient. You also need Write access to activities.
Some sources (e.g. http://social.microsoft.com/Forums/en-US/crmdeployment/thread/3451e18a-4afd-4436-b0b9-8ebd94156f67
) refer to the necessity of read access to all of these records: account, contact, lead, user, and queue. The test shows that some of these entities, like account and queue, may be blocked, and the user still can track the activity (possibly changed by a rollup). The entities you select for Read & Append To access will be available in user’s Set Regarding dialog.
Send Mail Merge Letters
The obvious selections are:
- Business management – Mail Merge (from Outlook) and/or Web Mail Merge (from web interface);
- Core Records – Mail Merge Template – Read;
- Core Records – [used recipient entities, e.g. Lead, Account, Contact] – Read;
Then users have to select the recipients in one of the ways:
- Advanced Find: Core Records – Saved View – Read – User, or
- Marketing List: Marketing – Marketing List – Create – User, or – Read – Business Unit, or
- Quick Campaign: Marketing – Create Quick Campaign.
They still don’t get Word icon on your workspace? Ah, like monsieur Jourdain
didn’t realize that his speech was prose, we don’t realize that mail merge is an activity. Moreover an activity has to be appended to the entities to which we send the letters. So we have to add the following permissions:
- Core Records – [used recipient entities] – Append To;
- Core Records – Activity – Create, Read, Append – User.
Create Queck Campaign
As well as Mail Merge, Quick Campaign requires permissions to create, write and append activities. Otherwise the Quick Campaign wizard starts looping.
Create Reports with Report Wizard
When a user with custom security role tries to create a new report, he gets Insufficient Permissions error. The security role has all permissions regarding reports, but Report Wizard still doesn’t start. It happens in Microsoft Dynamics CRM 4.0 environments which have been migrated from 3.0.
The problem is that the new security role is missing some permission(s) and the same time the user interface is missing a control to change them. You can create a copy of System Administrator role and make the needed security role by removal of redundant permissions. (luckily all to nothing change takes just one click) This witching works like a charm.
There may be other permission issues solved the same way. (I saw a reference but can’t find it anymore)
Conclusion: by preference use (copies of) standard CRM security roles rathen than creating security roles from scratch.
Use Custom Entities
If a new custom entity is created, by default only the system administrator gets access to it. Other users will not see the entity. Even worse, they will not see any related values, lookup fileds in other entities,which use the custom entity. So whenever you create a new custom entity, give permissions to this entity for all security roles which are expected to use it, or any entities related with it. Configure the permissions on Custom Entities tab.
Run Automatic Workflows
An action taken by the user may start a workflow which will create or update other records. For example, creating an opportunity may start a workflow which creates a follow-up task. Whenever you set up such a workflow, control that the user who may perform the original action cal also run workflows and take actions upon entities affected by the workflow.
Deletion of Records – The Rule and The Exceptions
The last but not the least, and it’s different. You can do anything but lay off of deleting blue suede CRM records.
Block deletion of records for all security roles except for System Administrator. By deleting records users will not only produce orphan records of other types. If a deleted record (like account) has parental relationship with other records, they all will be deleted.
Advise users to deactivate records, or to close activity records instead. One of many advantages is that you get undo. You can reactivate lead / customer records. In principle you can reactivate other types as well, but that’s another story.
The action to deactivate records has several reincarnations:
- Cancel (orders, invoices, cases and campaigns);
- Close (activities, opportunities and quotes);
- Convert (leads);
- Unpublish (workflows, duplicate detection rules and knowledge base articles).
And there are still quite some entities which cannot be deactivated:
- E-mails (it’s completed only when it’s sent. To delete an unsent draft, you have to enable deletion for all types of activities);
- Customer Relationships;
- Saved Views (Advanced Find);
- System jobs, like import, duplicate detection,…
- Reports (only revert to personal);
- Sales Literature;
- Quick Campaigns;
- Security Roles;
- Teams (neither deleted);
As exception, deletion of some of them may be permitted for few power users.
Still don’t know what to do?
If this post does not cover your situation, or the advises don’t help, go for an advanced action.
- Enable tracing: http://support.microsoft.com/kb/907490
- Reproduce the error.
- In trace log search by error code and find the permission GUID:
Error: Server was unable to process request.
Error Number: 0x80040220
Error Message: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: e65023ae-54d1-da11-8e39-00145e3d5192 and PrivilegeId: a8ecac53-09e8-4a13-b598-8d8c87bc3d33
- Identify the missing permissions by querying the permission GUID in the CRM database, as advised by Microsoft: http://support.microsoft.com/kb/953962
select Name, * from PrivilegeBase where PrivilegeId = 'a8ecac53-09e8-4a13-b598-8d8c87bc3d33'