## Resources - [Overall Account Data Architecture plan](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/architecture/data_architecture.md) - [Sisense Dashboard for this Iteration](https://app.periscopedata.com/app/gitlab/1081849/WIP---Fulfillment:Platform---Align-CustomersDot-BillingAccounts-and-Users-to-Zuora-objects) ## Purpose In the parent epic, https://gitlab.com/groups/gitlab-org/-/epics/8331+, we are looking to improve the data architecture of CustomersDot by better aligning to Zuora, our subscription management vendor. This involves creation of new models (`BillingAccount` and `BillingAccountMembership`) and adjusting associations with existing models like `Customer` (to be renamed `User` [in Iteration 4](https://gitlab.com/groups/gitlab-org/-/epics/8949)), `Order`, `License`, etc. In this sub-epic, the focus is on the first steps towards this new data architecture vision. This should cover the following topics (among other pre-requisites): - Build the new data models - Associate new models with existing models - Creation of new data model objects after purchase For this first iteration, the backend will be updated to use the new data models but keep with the same behavior before. This means a `Customer` (to be renamed `User`) can still only belong to one `BillingAccount` (and Zuora Account). Instead of using `zuora_account_id` and `salesforce_account_id` on the `Customer`, these same fields on `BillingAccount` will be used. For this iteration, a `Customer` (to be renamed `User`) will only have one `BillingAccountMembership` at a time. The reason for this restriction is that it allows us to step into the new data architecture in an iterative way. The feature flag `account_data_structure` introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4794 in this sub-epic will gate the usage of the new data models, but we will still keep the old data architecture (it won't be cleaned up until https://gitlab.com/groups/gitlab-org/-/epics/8949). This allows us to turn off the feature flag if needed. It also means we can start capturing data in the new models immediately, allowing us to gather feedback quicker, but we won't fully switch to using the new data models until we have backfilled and are ready to enable the flag. ## Value to the customer Once the issues in this epic are completed and the `account_data_structure` feature flag is enabled, CDot should be in a position where the new models, `BillingAccount` and `BillingAccountMembership` are being used. **This iteration won't be a noticeable shift from a UX or behavior standpoint**. However, it does set the table for lots of nice feature improvements in Iteration 2 and 3 like clearer management for one or multiple Billing Accounts. Even without those future improvements, there are plenty of reliability improvements and bug fixes that will be addressed in this iteration (some of which are already completed): - **Reliable Portal User (`Customer`; later renamed to `User`) creation using the Zuora Account's Sold To Contact when processing amendments**. This was a known problem in CDot for a long time and was especially problematic at renewal when the Sold To Contact is known to change. (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3626) - **License generation will be more reliable about using the Sold To Contact for license generation**. (https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5483) - **Subscription and Licensing emails will be reliably delivered to the Sold To Contact in Zuora**. Previously, the email address from the `Customer` (to be renamed `User`) record in CDot was used for this delivery, and there was no guarantee the correct `Customer` (to be renamed `User`) was selected. (https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5555, https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5396) - **Improved accuracy/consistency when Zuora Contact information is updated via CustomersDot form**. It is a known problem that if a Zuora Account has more than one contact, there is no guarantee the correct Zuora Contact is updated when using the update form in CDot. (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4970) - **`BillingAccount` information in CDot (like account name and Salesforce Account ID) will stay in sync with Zuora**. Currently this information lives on `Customer` (to be renamed `User`) and there is no guarantee it is in sync with Zuora. (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4797) ## Status * [2022-12-08 update](https://gitlab.com/groups/gitlab-org/-/epics/8950#note_1200922017): ~ 79% complete * [2022-12-01 update](https://gitlab.com/groups/gitlab-org/-/epics/8950#note_1192373199): ~ 64% complete * [2022-11-17 update](https://gitlab.com/groups/gitlab-org/-/epics/8950#note_1175669701): ~ 59% complete