Party model and global address book solution
The party model and global address book solution is a feature for dual-write that primarily covers three different scenarios.
Scenario 1
This scenario is where a person or an organization can play more than one role in a business and will need to switch roles based on the context.
For example, an employee of Contoso US has their own personal ID information, and because they’re an employee in the US, they can sign in to an e-commerce portal and purchase products. Because they can be a consumer of these products, they’re therefore a customer. However, they can also sign in to the e-commerce portal and create and build apps and then sell these apps through the portal to US and Canada markets. In this scenario, this user is a customer, but they’re also a vendor.
The key complexities for this scenario include the ability to:
Represent a person as a contact, as a customer, as a vendor, or all these options.
Represent an organization as a customer, a vendor, or both.
Allow each person or organization to transact in more than one market and then track the transactions against each market, end to end.
Scenario 2
This scenario is related to the transactions that the user can complete. A user or company might need to have several different profiles for addresses, taxes, and the rules and regulations for each country to transact in each. Having a generic profile and several financial profiles for each different country or set of transaction needs is essential. Each financial profile is considered as the customer on a transaction and not the generic profile. However, if a change occurs on the generic profile, such as a change in name or address, it would become available to all financial profiles of that customer.
For example, the customer can transact in many countries, but the citizenship status and personal identification remain the same. However, based on which country/region that the user is transacting in, different rules and regulations might be established for taxes that are specific to each country/region. The United States has different rules and regulations than other countries/regions, and this customer needs to make transactions in several.
The key complexities for this scenario include the ability to:
Separate a generic profile from specific profile information.
Store and retrieve as many addresses as possible of each type.
Have changes in common properties become available for each customer without data duplication.
Scenario 3
This scenario deals with a customer becoming an organization, whether the organization has multiple locations, if specific clients of the organization are at the different locations, and the ability to address each option. For example, consider a hospital scenario with a doctor and patients. A doctor treats one or more patients at the same time. Each patient is also referenced based on the doctor whom they’re assigned to. The doctor can sign in to a hospital website, track patient records, and give them directions for prescriptions and treatments for their individual needs. The doctor could be practicing at multiple locations, and each hospital has multiple departments that operate in each of the multiple locations. The doctor can also become ill and then become a patient as well.
This situation has several key complexities, including the ability to:
Associate the contact with one or more customers without duplicated data, and then track the customers’ records based on the contact.
Convert the contact to a customer.
Allow the contact to sign in to several Power Pages and access all customer records across all locations.
Summary
All the mentioned scenarios in the party and global address book solution are in Power Platform and in the data for Dataverse. Overall, a customer can be represented as a person or an organization. The contact can have several addresses, financial profiles, and a generic profile. The customer can be associated with one or more contacts, and they can be associated with several pieces of information, such as a customer group, payment terms, payment method, payment schedule, and so on. This factor doesn’t only affect customers; vendors have these abilities as well. Each company is a company, and key complexities have been established to classify customers, embellish customers, and give them more details, such as payment terms and payment methods, among many more.
An upgrade path is available from the original pre-party model solution to the party model and global address book solution model. Separate templates are available for migrating the party data and contract data, and separate templates are available for postal and electronic addresses as well. All templates and the upgrade path are based on the Microsoft Azure Data Factory templates, and you can use them for the update scenario.
For more information, see Party and global address book.