The Customer Address entity is one of those special entities in CRM. As you probably know it stores address and shipping information for accounts and contacts. I had worked on a project where we had hoped that we could attach a custom entity to the address entity like any other entity. We found out that customer address is special. It’s one of those entities where Microsoft slaps your hands and says only we can use it so keep out, but that’s another story. The interesting thing about the address entity is that as you look at an account or contact form fields you’ll notice that there are fields for address1 and address2 addresses. You can add as many additional addresses as you want, but the first two are special. On the same project I mentioned previously we were synchronizing information between Microsoft CRM and ERP systems. We had an issue in that the ERP systems were not giving me a unique way of identifying an address. Every time I would get an update I did the easiest thing which was to remove all addresses and then add them back according to what the ERP said they should be. I found this to be problematic as for some records (specifically contacts) I was unable to save the record anymore in the interface getting an error of Generic SQL error which I love so much. After some theories and tests I discovered the issue. Despite the fact that you see both address1 and address2 fields on the contact form the addresses are not actually stored on that entity. All the addresses are stored in the customer address entity. The fields you see on account and contact are really pointers to these records. The problem saving I had was partially my fault and partially Microsoft’s. I don’t believe Microsoft ever intended for anyone to actually remove the first two addresses even though it was perfectly “legal” to do in code. I noticed that when I did this and try to add new addresses that my new addresses were pushed back to start with address 3 instead of 1. I found that behind the scenes Microsoft was automatically recreating the addresses that I deleted at least for address 1. Address 2 was never recreated (pre-rollup releases) and there was a pointer to this address 2 record that was supposed to be there for the entity. After I stopped removing address1 and 2 and instead chose to update these two addresses instead my problems went away. So the premise of this blog is that if you are going to do anything special with addresses do not ever remove address 1 or 2. These are built in and should only be updated else you may find yourself looking at a generic SQL error message that tells you nothing about what is actually happening.
We have similar issue when integrating CRM with several ERPs. After extensive analyzing we decided not to used standard entities Address for Accounts and Contacts. We create our own, workong similar as standard one - but with possiblity to make relations to other entities.
Yes we ended up creating our own address entity as well and linked our entities to it. The added bonus by having our own entity was that we could then use security on it. The downside was that the OOB reports use the primary address entity, but nothing that couldn't be "addressed" with a little modification.
We have a similar issue been reported. We are seeing that the records in customeraddress with addressnumber = 2 have been deleted. In which scenario's do the entries in customer address get deleted?
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.