Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
I have some customers and corresponding addresses and contact information in the system. The task is to add new customers (with their additional information like addresses and contact details) and update the existing ones - customers with their addresses and contact details. Importing is easy with the Data Management workspace (by using Customers V3, Postal addresses, Party Contacts or Postal address electronic contacts entities). The good thing is that for each customer I have only one address (which will be primary) and thus I can update already existing addresses via the Customers V3 entity, as it's not possible to update this information via the Postal addresses entity. But for the contact information the scenario is more difficult as I have both primary and no-primary contacts - using the Customers V3 entity will update only the primary information - phone, fax, email, etc... and using the Party Contacts or Postal address electronic contacts entity generates a new record instead of updating the existing one in case of data change (i.e. Description). The reason for this is that contacts don't have a unique ID (a combination of fields - Description, Type, Locator, etc... is being used for the uniqueness). I hope this information could be helpful to someone, but I also hope to get some ideas on how to overcome the impossibility of bulk updating the contact details (in particular the "no primary" ones). Manual update record by record is always an option, but it's not esteemed, when having thousands of customers.
You have to export your data with the Location ID generated by the system, do your update in Excel, then import back with the existing Location ID. It goes into the UPDATE mode rather than INSERT mode.
For Party contacts entity the LocationID has the same value among all the records for one customer (PARTYNUMBER), which means that by using the LocationID the specific contact record cannot be identified:
For Postal address electronic contacts entity the situation is similar - one LocationID for all the contacts records under same address.
I checked - there is no Data Entity that will allow you to bulk update non-primary electronic addresses for any party (reasonably sure, but under correction). I agree that it will be a handy feature.
If I understand you correctly, you are looking for an entity that will have fields (core fields): PartyNumber, ElectronicLocationId, Locator. Then we can bulk update contact details.
I think this is maybe possible - Locator & PartyNumber & LogisticsElectronicAddressMethodType should (in practice) be unique. So then we have a key - and then we can create an entity.
In summary: I think this is possible with a reasonable amount of development time.
You are right. I checked the LogisticsPostalAddressElectronicContactEntity. The LOCATOR is a key field there, i.e. the e-mail address itself is a primary key. I.e. you cannot update them without making a new record.
That is correct. And most probably one of the reasons that the Data Entity does not exist yet. But as I mentioned - creating a logical key for this data structure is possible, even though it is non-existent on the table.
Business Applications communities