As part of a recent project I have been involved in, one of the requirements was to facilitate a bulk data import process via a single import spreadsheet, which would then create several different CRM Entity records at once. I was already aware of the Bulk Data Import feature within CRM, and the ability to create pre-defined data maps via the GUI interface; what I wasn’t aware of was that there is also a means of creating the very same data maps via the SDK or an .xml import. This was a pleasant surprise to say the least and, from the looks of it online, there is very little in the way of resource available for what is, arguably, a very powerful out of the box feature within Dynamics CRM. Expect a future blog post from me that dives a bit deeper into this subject, as I think the capabilities of this tool could fit a variety of differing requirements; if only the instructions within the SDK were a bit more clearer when it comes to  working with the raw data map .xml!

Whilst attempting to perform a proof of concept test, I uploaded a data map .xml into CRM, which contained references to four different entities. When I then attempted to run the data import using a test file, I encountered a strange issue which meant I could not proceed with the import. This occurred when CRM attempted to map the record types specified as part of the data map:

DataMap_Error

Can you spot the two issues?

The first, more obvious, problem is the yellow triangle on the 3rd entity option and the fact that the Record Type is empty. Whereas the 3 other options will display clearly the Display Names of the entities (e.g. Account, Lead), the Display Name of the problematic entity is not visible at all.

The more eagle-eyed readers may also have spotted the second, more serious issue; the next button is grayed out, meaning we have no way in which to move to next step as part of the data import. With no means of figuring out, exactly, what may be causing the problem based on the above screen, you can potentially expect a long-haul investigation to commence.

As it turns out, the issue was both simple and frustrating in equal measures. It turns out that because the third entity on the list of the above had the exact same Display Name value as another entity within the system, CRM got confused and was unable to display and map with the correct entity. So, for example, lets say you create a custom entity to record information relating to houses, called “Property”, with a Name of “new_property”. Without perhaps realising, CRM already has a system entity called “Property”, with a Name of “dynamicproperty”. It doesn’t matter that the Names of the entities are completely different; so long as the Display Names are, then you will encounter the same issue as highlighted above. So, after renaming the entity concerned with a unique Display Name (don’t forget to publish!), I was able to proceed successfully through the data import wizard.

So why is this frustrating? If, like me, you have worked with CRM for some time, your first assumption would be that the system would always rely on the Name of objects when it comes to determining unique entities, attributes etc. The above appears to be the exception to the rule, and is frustrating for the fact that it throws out of the window any assumed experience when it comes to working under the hood of CRM. Perhaps it was (fairly) assumed that, because the logical names must always be unique for entities, that the data map feature could just use the Display Name as opposed to Name when attempting to map record types. I would expect that CRM is performing some kind of query behind the scene at the above stage of the Data Import wizard, and that the Display Name field value is included as parameter for all entities included in the data map. In summary, I would suggest that this is a minor bug, but something that would be difficult to encounter as part of regular CRM use.

Hopefully the above post will help prevent anyone else from spending 6+ hours from figuring out just what in the hell is going on 🙂 As a final side note, what this problem and solution demonstrates is an excellent best practice lesson to avoid; be sure to provide distinct Display Names to your custom entities.

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=8.0.0.0, 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=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”>

<ErrorCode>-2147220960</ErrorCode>

<ErrorDetails xmlns:d2p1=”http://schemas.datacontract.org/2004/07/System.Collections.Generic” />

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

<Timestamp></Timestamp>

<InnerFault i:nil=”true” />

<TraceText i:nil=”true” />

</OrganizationServiceFault>

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>

Means:

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

e.g.

SystemJobMinimumPrivileges

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 🙂