Authors: Meenu Laul, Joseph Thomas
Summary
Microsoft has published very detailed and comprehensive procedures on how to Upgrade to the party and global address book model. It includes a list of prerequisites and detailed steps that must be in place. It’s very possible that your project does not meet all of the prerequisites. Are you still able to successfully deploy the GAB solution to your organization? Certainly! We outline some examples of discrepancies to look for and how to navigate to a successful integration with Dual-Write. It’s important to take the time to walk through the published steps and document where there might be differences between your situation and the documented steps. We have encountered some common discrepancies:
Solutions
It’s important to realize that the published procedures are specifically engineered for environments that are already live and have Dual-Write enabled in both F&O and CE. The procedures provide the Azure Data Factory templates that will help create the Party related table structure in CE, based on the table structure in F&O for Contacts and Accounts that are already synchronized between CE and F&O. If yours are not, your first step should be to follow the procedures to Enable dual-write for existing finance and operations apps. There are a lot of design decisions that need to be made as your follow these procedures that are critical to the success of being able to successfully upgrade to the Global Address Book model. Take your time, document everything, and test, test and test some more and remember to do only on subset of data to test.
It's also important to consider the current state of your implementation and choose the correct path within the documentation. The Guidance for dual-write setup provides nuanced steps depending on multiple factors such as whether F&O and/or CE is live and whether F&O and/or CE have data. Take your time and walk through these scenarios to ensure the path you are going down meets the well-defined prerequisites. For example, if you have an existing, live F&O instance and an existing CE instance with data, you’ll have to follow the bootstrapping procedures which differs from some of the other scenarios.
Do your due diligence on the size of your data. There are well documented Initial Sync Guidance steps that should also be thoroughly vetted. One we have encountered is with datasets larger than 500k rows. This is a tricky one. The stated procedures advise “If there must be more than 500,000 rows in a run when you the initial synchronization, we recommend that you migrate data into the finance and operations app and Dataverse separately and skip the initial synchronization.” As an example, let’s say you have an already live instance of F&O with 2 million Customers, and you want to migrate those into your new CE instance. The recommendation means that because of the size of the dataset you should treat this as a data migration project and utilize your organization’s ETL tool of choice to migrate your data from F&O into CE. At which point, you can follow the bootstrapping procedures to synchronize the two. Then once they are synchronized, then you can follow the procedures to upgrade to the GAB model.
Testing is absolutely a critical element. Ensure you have testers assigned who are familiar enough with the data that they will easily recognize discrepancies. For example, we’ve noticed duplicate address data appearing in CE. In one example we noticed address data being mapped directly to the Contact entities address fields. (address1_line1, address1_line2, etc.). Natively, when you type address data into these fields on the Contact record, the associated Address table is kept in sync with the address1_line1 fields on the Contact. After the GAB solution is installed, those plugins keep the Party Postal Address table in sync with the native CE Address table which in turn is natively kept in sync with the Contact address fields. The result was, address data was mapped into both the GAB Postal Address tables (where it should be) as well as to the Contact address fields (where it shouldn’t be). When the address data went to the Contact address fields, it automatically updated the native Address table and the GAB plugins fired and created associated Postal Address records as well. This had the result of “123 Main Street, Anywhere, USA 77777” showing up twice in the native Address table and twice in the Postal Address table.
We also noticed during testing that some Party record ID’s were not the same in CE as they were in F&O i.e. we noticed some Party records had a Party ID = ‘PAR-000000000’ and some looked like this ‘PTY000000000’. Upon further investigation, we realized that the GAB plugins in CE had fired and created the record with the dash. The plugins fired because the required data was missing. It’s important to ensure that the appropriate tables have been completely created in CE before moving to the next step. For example, the Party record is sync’ ed with F&O first, then the Postal Address Collection, then the Party Postal Address and then the Postal Address table. If this is done out of order the plugins will recognize the missing data and create records directly CE that won’t be sync’ed to F&O.
These are a few examples of some nuances we have encountered. Your implementation may have different details that may ultimately require you to step outside of the published procedures. We’ve found that the most important success factors are to document your specific procedures in as much detail as possible and allow for enough time for testing and for making updates to your procedures as a result of your testing. Iterating through the process thoughtfully and with as much detail as possible typically yields the most successful results!
