Hello everyone.
This time, I've run into a problem with the specifications of the Excel data import process for Dynamics CRM (Dynamics 365), so I'd like to share it on my blog as a memo.
If you are someone who has been stuck in the same situation, I hope this blog will help you to solve the problem.

The gap between what you want to achieve and what is actually happening

• Execution environment
  • Microsoft Dynamics 365
  • Version 1612 (8.2.0.720) (DB 8.2.0.720) Online
• What you want to achieve
  • When registering a new case (support issue) record, automatically link the machine master information to the machine's serial number and register it.
  • When registering to the database, a custom plug-in is run, which references the machine master using the serial number as a key, retrieves the matching machine record, and sets it as the related item (Lookup field) of the case (in other words, input assistance that automatically links machine master information when the serial number is entered).
  • However, if both the machine serial number and machine master information are specified (①), the search results using the machine serial number as a key will be prioritized (the specified machine master information may not be the latest and will be ignored).
  • The above also supports record registration via form screen and Excel data import.
• The actual gap
  • In case ①, the plugin works fine when registering records via the form screen, but when registering via Excel data import, the machine master information specified in Excel is registered.

Regarding the results of the investigation into the incident

It turns out that Dynamics 365 performs two processes when importing Excel data　
One is the caseRegister attribute information (subject, status, etc.) (Create)To
The second is the case after registration.Update only related information (Lookup fields) (Update)To

In this case, the machine serial number was processed as case attribute information in step 1, and the machine master information was processed as case related information in step 2, so they were processed as separate transactions.
As a result, even if input assistance was provided using a custom plugin at the time of registration, the data would be overwritten in subsequent update processes.

Time series
① Excel data import Machine serial number: A Machine master information: X
② Refer to the machine master using plugin A as a key and obtain the latest information on the machine master: Z
③ Register the case Machine serial number: A Machine master information: Z
→ Expected results
④ Update the case. Update only the related equipment master information to X (the value specified in ①).
⑤ Record status of the case = Machine serial number: A Machine master information: X
→ Actual results

If you set up auditing and change history for these entities, you can understand the flow of operations in the audit summary view, so why not give it a try?
As you can see in the Audit Summary view, creation and updates are performed separately for case records.

Other concerns

The `case` entity is a standard entity provided by Dynamics 365. In the Excel data import we confirmed, only standard entities performed both the create and update operations . When we tried creating a custom entity, even when specifying related fields (Lookup fields), it only performed the create operation at this time . We also confirmed that the form screen operation also only performed the create operation, which is not a problem.

Is the processing divided depending on the number of fields the entity has? I don't know the exact specifications, but it seems like I'll need to keep an eye on the Excel data import processing specifications for standard Dynamics 365 entities. If I run into any issues, I'll post them on my blog.

Contact Us

*The content of this article is for personal reference only. Please use the content of this article at your own discretion.