Dynamics CRM Tip: Unable to Create or Resolve Cases?
By Byron C. Law, Crowe Horwath
Creating and resolving “cases” in Dynamics CRM is very important for customer service and support teams. So if you get an error code when you are trying to create or resolve cases, it can slow down productivity.
A client presented an issue where they were unable to create or resolve cases in their environment, even if they were logged in as someone with a System Administrative role. If they tried to save a case they were creating or resolve a case that was already created, they would get the following error
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Principal user (Id=033167a9f-8e1a-e911-80e6-5065f38b6141, type=8) is missing prvReadIncident privilege (Id=c2aff40c-6e68-4437-a631-488a354a1860)Detail:
The person trying to save the case had all the requisite permissions (particularly when the person attempting to do so had System Administrative privileges). To resolve this issue, it was important to determine who the principle user was. You can do this from the GUID (globally unique identifier). (Note: the above GUID has been modified).
There are two ways to determine who the user is that is associated with the GUID.
Determining a user from a GUID
The first way you can determine a user from a provided GUID is to simply go to https://[orgname].crm.dynamics.com/api/data/v8.2/systemusers([GUID]) making the appropriate substitutions. This will give you a page that provides all the data related to that particular user (including the name of the user).
The second way to determine a user from the GUID is to simply export your users as a spreadsheet and unhide the first three columns, the first of which includes the GUIDs of your users. If you do not see the GUID you are looking for, check other User views that might include an active System user (such as Administrative Access Users)
What is the Access Mode?
Once you find the principle user associated with the GUID (in my case, it was the CRM Service user), pull up their record and determine which Access Mode (Read-Write, Administrative, or Non-Interactive) they are using. The user should be Read-Write. If they are Administrative (as was the case with my CRM Service user) they will generate an error (like the one above) if they attempt modifications of entity records.
But I am not logged in as that user
If you are not logged in as the user associated with the GUID, chances are that the error is generated as a process/workflow is kicked off during the Save or Resolve process.
Bring up Processes under Settings and review any workflows/processes associated with the entity in which you are having the issue. Take a look at the Owner column and see if any are owned by the user associated with the GUID. If there is an activated workflow/process that is owned by the user, there is a good chance that it is generating the error when it is fired off on Save or Resolve. Disabling the workflow I found with CRM Service as an owner resolved my issue.
In my case, with the CRM Service user, it is an administrative user and I did not have the option to change the Access Mode to Read-Write. Disabling the workflow resolved the issue, but if the workflow is needed, you can bring up the workflow in question and change the Execute As field to “The user who made changes to the record” instead of “The owner of the workflow”.
If you are interested in support or training for Microsoft Dynamics CRM (now Microsoft Dynamics 365) contact us at 877-600-2253 or [email protected].
By Byron C. Law, Crowe Horwath, a Microsoft Dynamics 365 Gold Partner,
Follow us on Twitter: