The introduction of Excel Online within Dynamics CRM was one of those big, exciting moments within the applications history. For Excel heads globally, it provides a familiar interface in which CRM data can be consumed and modified, without need to take data completely off CRM in the process. It is also a feature that can easily be used by CRM Administrators in order to perform quick changes to CRM data. It’s also one of the benefits of using CRM Online over On-Premise, and probably something I should of included as part of my previous analysis on the subject.

As great as the feature is, like anything with CRM, it is subject to occasional issues in practice; particularly if you use bespoke security roles as opposed to the “out of the box” ones provided by Microsoft. We encountered an issue recently where one of our colleagues had a problem importing modified data from Excel Online back into CRM. Our colleague had no problem opening the data in Excel Online, with the problem only surfacing when they clicked the Save Changes to CRM button. The rather lovely looking error message looked something like this:

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Principal user (Id=0c6ff908-a6c9-e511-8144-c4346bac5e0c, type=8) is missing prvReadImportFile privilege (Id=fe46d775-ca5c-4a09-af93-99a133455306)Detail:

<OrganizationServiceFault xmlns:i=”” xmlns=””>


<ErrorDetails xmlns:d2p1=”” />

<Message>Principal user (Id=0c6ff908-a6c9-e511-8144-c4346bac5e0c, type=8) is missing prvReadImportFile privilege (Id=fe46d775-ca5c-4a09-af93-99a133455306)</Message>


<InnerFault i:nil=”true” />

<TraceText i:nil=”true” />


When approaching any type of error message for the first time, it can be quite daunting figuring out what it is saying. Fortunately, in this case, there is only one line we really need to be concerned about, which is the <Message>…</Message>. To translate to plain English, this line:

<Message>Principal user (Id=0c6ff908-a6c9-e511-8144-c4346bac5e0c, type=8) is missing prvReadImportFile privilege (Id=fe46d775-ca5c-4a09-af93-99a133455306)</Message>


I cannot complete this action for Joe Bloggs, because they are missing the Import Source File Read privilege!

(Note: To help translate the above, I made use of the Security role UI to privilege mapping table on MSDN – a handy link to have in your browser favourites)

Giving the user just this privilege did not resolve the issue, producing a completely different error message in the process. Rather then spend an inordinate amount of time replicating the action over and over again, we did a quick Google search to see if there if we could find a list of the minimum level of permissions required in order to complete We were directed towards this forum post, with an answer from CRM MVP Jason Lattimer on what permissions were required in order to resolve the error message:

Required permissions:

* Data Import (all)
* Data Map (all)
* Import Source File (all)
* Web Wizard (all)
* Web Wizard Access Privilege (all)
* Wizard Page (all)

Problem solved you’d think? Well, unfortunately, in this case not. Although at first we thought that things were working fine, as no error message cropped up. When we then monitored the data import job in background, however, it was stuck at Parsing. At this point, we were really beginning to struggle to think of how to resolve the problem. It was at that point we rather desperately took a look at other, successfully completed, System Jobs to see if there was anything obvious we could observe. We noticed that successfully completed Data Import jobs had 3 System Job Tasks associated with them, whereas our stuck had only 1. At this stage, we asked: Could we be missing privileges on the System Job entity? And, lo and behold, when we took a look at the users security role, there were no privileges configured for System Jobs. After a bit more trial and error, adding permissions one by one onto this role, we saw that the Data Import job ran successfully!

So just to confirm for those who may encounter the same problem in future, the full list of permissions required to get Excel Online Data Import working successfully are the ones highlighted above and the following additional privileges too:

Customization Tab

System Job

Create: Business Unit Level

Read: Business Unit Level

Write: Business Unit Level

Append: Business Unit Level

Append To: Business Unit Level

Assign: Business Unit Level



What this problem (and the solution) I think demonstrates is the best way in which to approach day-to-day problems that may crop up within CRM:

  • It is reasonable to assume from the outset that the problem is due to a lack of security permissions problems; try not to over complicate matters early on by assuming it could be something completely different. For example, if the task or action that you are trying to perform CRM can be performed using an account/security role with greater permissions, then this will tell you straight away what the problem is.
  • Having good “under the hood” knowledge of CRM is always helpful in a scenario like this, but this may not always be possible for those of you work with CRM sparingly. To help you in this scenario, we can refer to some of the fantastic resources online by the CRM community. Ben Hosking has a great blog post on the importance of thinking in entities when it comes to working within CRM, something which I think applies great in this particular example. By understanding that the System Job is a system entity, we can logically assume that it has its own set of required permissions.
  • In diagnosing the issue in this case, we were able to refer to some of the previous System Jobs records in the system. As part of this, we observed that a System Job that completed successfully had 3 job records related to it. This immediately told us that there was something wrong with the users access to the entity in question (going back to the above, System Job is, after all, a system Entity). Sometimes, being able to understand the difference between an action, when it works and doesn’t work, can give you the information you need to make the logical next step jump on what to investigate further.
  • And, last but not least, access to and the ability to use a search engine is always very helpful 🙂

Microsoft Dynamics CRM comes with a number of out of the box Security Roles that can be used in order to give users the correct permissions. Whilst this is helpful, they generally won’t be a good fit for most organisations and a custom security role will be required in order to get the correct mix of permissions. These can be either created from scratch or be based off one of the system defaults. Regardless of how you go about it, the dreaded risk of permissions errors is ever present and it can be very difficult at times to figure out which CRM feature relates to what security permission; it doesn’t help as well when some of the system entity logical names are entirely different from their display names!

A good case in point is Server-Side Synchronisation, a brilliant feature that takes a lot of the headache out of setting up your colleague’s e-mail addresses on CRM. But, if you decide to create your own custom security role in Dynamics CRM 2015 or earlier, you may end up running into this very frustrating error message when attempting to test and enable your users’ mailbox:


Well, at least we’ve got an error message – what does our best friend Google say? Rather annoyingly, there isn’t much that comes back search wise, not even an official page from Microsoft that provides a list of the permissions that are needed in order to use this feature.

A (not so quick) support case with Microsoft in order to find out just what permissions I need to increase/add onto my role will likely result in an answer similar to this:

“In order to resolve the issue, make a copy of an existing security role and then reduce the privileges accordingly, as there are some hidden privileges within these roles that affect this feature.”

“Hidden permissions” you say? That smells suspicious and is something that I have never come across in my working with CRM (though I am of course happy to be stood corrected). Also, what if in reducing the permissions to suit my businesses requirement, I accidentally remove the privileges that are needed for this work? Looks like I’m going to have to find out which privileges are needed the hard way.

So, after some trial and error, I can now provide a complete list of all the permissions that you need to have on your security role in order to Server Side Sync to work successfully. Please note the below assumes that you already have a separate security role setup that gives relevant permissions on the Appointment, Contacts and Activities entities within CRM:

Incoming/Outgoing E-mail

  • Email Server Profile
    • Organization level Read
  • Mailbox
    • User level Create, Read & Write


Appointments, Contacts and Tasks

  • Organization
    • Organization level Read
  • Sync to Outlook
    • Full Privileges




With all of the these privileges assigned, our test and enable of the mailbox works successfully:


Hopefully this helps someone who has spent countless hours pulling their hair out on how to get this working.

For those of you that are upgrading to CRM 2016 in the near future, there’s some good news relating to this: an extra button has been added on the error message that lets you expand it and view the system privilege name that is missing:


So based on the above message of “prvReadOrganization privilege”, we know that we need to give Read Privilege on the Organization entity! This is definitely a big help and a welcome new feature to have, as you can then go through and gradually add the permissions missing until everything is working. It’s little things like this which is making me more and more excited about upgrading to 2016 in the near future.

Does anyone else have any tips or advice on how to get certain features within CRM and what privileges are needed? Please use the comments below to share.