Post

Customer Address revisited

Diesen Beitrag auf Deutsch lesen

Explains Dataverse customeraddress and leadaddress storage, two new address-management features, storage implications and backup precautions.

TL;DR

Dataverse stores account and contact addresses in customeraddress and lead addresses in leadaddress. Default creation produces two customeraddress records per account, three per contact, and two leadaddress records per lead. A new setting delays address-record creation until data exists, while another removes existing address records without deleting the parent record.

Original on Powerplatform.se. Read the original

This is our own summary, not a republication or full translation.

Governance takeaway

Admins/CoE should evaluate the deferred address-record setting for new Dataverse records, especially in marketing environments with millions of sparse leads, because default supporting rows consume storage. Admins/CoE should take a forced instance backup before removing existing customeraddress or leadaddress rows, and validate the result carefully during testing and production change; the source warns that missing address records can be very unusual in on-premises systems.

Frequently asked questions

Where does Dataverse store the addresses of accounts, contacts and leads?

Addresses of accounts and contacts do not live in the main tables but in a separate table called customeraddress. Leads use the separate table leadaddress for this.

How many address records does Dataverse create by default?

With the default settings, each account gets two address records, each contact three and each lead two, even when no address data is entered.

Why does this become a problem in marketing with many leads?

Because the empty addresses grow with the number of leads. One million leads generate two million empty lead addresses.

This post is licensed under CC BY 4.0 by the author.