Quote to Cash

1. You are here:
2. Quote to Cash

On this page

• Overview
• Q2C Teams
  • Product Monetization and Fulfillment
  • Sales
  • IT Enterprise Apps
  • Data
  • Finance, Billing, and Revenue
• Q2C Project Management Process
• Q2C System Architecture
  • Equivalent Data Objects Across Q2C Systems
  • CustomerDot Object Model
  • Zuora Billing Object Model
  • Zuora and Salesforce Integrated Object Model
  • Fulfillment data architecture plan
    • CustomersDot BillingAccount management
      • Background
      • Problem
      • Examples of issues this could benefit
      • Plan
      • Why do we need the ability to associate a CustomersDot User with many CustomersDot BillingAccounts?
      • Source of Truth
    • GitLab.com SSO as the only sign in option for CustomersDot
    • Align CustomersDot Orders to Zuora subscriptions and trials
  • Snowflake Data Warehouse and dbt (data build tool)
    • Data Architecture Plan
    • ERDs (Entity Relationship Diagrams) for Business Process Modeling
    • dbt Data Lineage Diagrams and Data Dictionaries
    • Business Insights and Analysis

Overview

This is a cross-functional page which is meant to be the source of truth for our Quote to Cash (Q2C) teams, project management process, and system architecture.

Q2C Teams

Product Monetization and Fulfillment

Sales

IT Enterprise Apps

Data

Finance, Billing, and Revenue

Q2C Project Management Process

To be added

Q2C System Architecture

The Fulfillment Team is re-architecting our Quote 2 Cash Systems, in particular CustomersDot, in a way that promotes more reliability, sustainability, and flexibility. This handbook page serves as the SSOT for the Q2C systems with links back to functional department pages and artifacts.

Cross-Functional SSOT Architecture Plans:

1. Fulfillment SSOT Plan: data_architecture.md
2. Central Data Team SSOT Plan: data_architecture
3. Sales Systems SSOT Plan: To be added
4. Enterprise Apps SSOT Plan: To be added

Zuora serves as the source of truth for Zuora Account and Zuora Contact data once a Subscription is purchased. Prior to a purchase, a user can register for CDot which creates a CustomersDot User record that isn't associated with an CustomersDot BillingAccount (because it doesn't exist yet). Once purchased, the CustomersDot BillingAccount record is created along with the related CustomersDot BillingAccountMembership.

Given that CustomersDot User/Zuora Contact and CustomersDot BillingAccount/Zuora Account information can be edited by users directly in CDot or directly in Zuora (or indirectly via SFDC), we need to be mindful of syncing this data between CDot and Zuora. In particular, if we can't use Zuora callouts to keep the CustomersDot BillingAccount and CustomersDot User records in sync, we will explore Zuora Custom Events.

A CustomersDot User record in CDot is tied to one email address. This email address can be associated with multiple Zuora Accounts, and therefore have multiple Zuora Contacts. Each of these Zuora Contacts could be modified independently. For instance, a billing admin may choose to change the address for Contact A for the billing entity in the US, but not choose to change the address for Contact B (associated with the same email address) for the billing entity in Europe. For this reason, contact metadata could eventually be stored on the CustomersDot BillingAccountMembership model, but we are choosing to keep this lightweight to begin with to reduce scope. We will start by fetching this data from Zuora.

Equivalent Data Objects Across Q2C Systems

This table shows the equivalent data objects across systems:

Note: In SFDC, a SFDC BillingAccount is not the same as a SFDC Account. A SFDC Account can have many BillingAccounts.

Note: The Order object in CustomersDot is not the same as the Order object in Zuora, they have different definitions. Orders in CustomerDot are more like subscriptions in Zuora than they are Orders in Zuora. More architecture and definition work needs to be done on the Order object in CustomersDot.

More information about the User and Contact objects shown in the table above, and how they interact together, can be found in this workflow documentation.

CustomerDot Object Model

The following is a focused view of the database ERD for the newly proposed data architecture.

Zuora Billing Object Model

Zuora provides a diagram of the relationships of Zuora's Billing Object Model

To reduce the amount of data issues across our systems, our goal is to try to ensure we have a 1:1 mapping between Zuora Billing Object Model and CustomersDot.

Zuora and Salesforce Integrated Object Model

Zuora CPQ is used to connect Zuora with Salesforce.

Fulfillment data architecture plan

CustomersDot BillingAccount management

CustomersDot BillingAccount management

• BillingAccount: Introduce a BillingAccount and BillingMembership object
  • Sisense Dashboard
• BillingAccount: Update CDot navigation to display new data structure to customers - Link to be updated
• BillingAccount: Multiple CDot customers can manage one BillingAccount
• BillingAccount: CDot customers can manage BillTo and SoldTo contacts
• BillingAccount: One CDot customer can manage multiple BillingAccounts
• BillingAccount: Clean up legacy data objects

First, we want to focus on improving the data architecture alignment with Zuora Billing Accounts. The Customer model in CDot has known design flaws as it represents a combination of both a Contact (individual user) and an Account (organization). Research for this epic can be found in this Spike issue.

Background

In this epic, the focus is on improving the data architecture of CustomersDot to better align with Zuora Billing Accounts. The Customer model in CDot has known design flaws as it represents a combination of both a Zuora Contact (individual user) and a Zuora Account (organization).

Problem

Currently CustomersDot (CDot) has a data object for Customer (e.g. customers DB table) which serves a few different functions:

• A user (with a unique email address) that can login CustomersDot
• Contact information related to a physical person within a Company with metadata like first and last name, email, mailing address, etc.
• Company information that is associated with a Zuora Account with company name.

It is important to note that a Zuora Account maps to a company/customer account which can have many users or contacts. It should not map to one user in particular. In the current architecture, a zuora_account_id can be shared with more than one Customer but this isn't ideal. We need to have an architecture that accurately reflects the data structure from Zuora and our business model. In CustomersDot, we need to have a data architecture that accurately reflects Zuora's Billing Objects Model).

Examples of issues this could benefit

1. CDot Issue #3626
2. GL Issue #332236
3. Epic #2160
4. CDot Issue #242
5. CDot Issue #695
6. GL Issue #338546

Plan

We recommend adding a few new models to the CustomersDot data architecture to better reflect the Zuora data structure.

Most importantly, CDot lacks a model for the CustomersDot BillingAccount (aka. "Company" / "Billing Entity"). Adding this model will allow us to separate the data currently in the CustomersDot Customer model that belongs at a BillingAccount level (see below for an example). We will also be renaming CustomersDot Customer model to CustomersDot User as the current naming is a bit confusing due to Salesforce having a different definition for what a Salesforce Customer is.

• zuora_account_id
• company_name
• vat_code
• salesforce_account_id

Additionally, we can add a join table (e.g. billing_account_memberships table) between the CustomersDot BillingAccount and CustomersDot User models which will allow a CustomersDot BillingAccount to have multiple CustomersDot Users. Likewise, a CustomersDot User could be associated to many CustomersDot BillingAccounts.

With this data structure, CDot should consider the data structure of CustomersDot BillingAccount and CustomersDot User as a way of determining which users of CDot should have access to view / manage subscriptions for a Zuora Account. CDot could rely on Zuora for providing the source of truth for who the contacts are for the Zuora Account and likely their metadata (e.g. name, address).

Currently, CDot creates a CustomersDot User record for the SoldTo contact associated with the Subscription Account. In this epic, we could also create a CustomersDot User record for the BillTo contact as well for the same Subscription Account, but this isn't a requirement. This will effectively allow both types of contacts to login to CDot and manage the Account's subscriptions.

Why do we need the ability to associate a CustomersDot User with many CustomersDot BillingAccounts?

We considered only allowing a CustomersDot User to be associated with a single CustomersDot BillingAccount, however, we determined that we should build a many-to-many mapping capability because:

1. Zuora currently allows for a single user to map to multiple billing accounts.
2. We see examples in production where this is already happening (over 1800 user accounts in Zuora currently map to multiple Billing Accounts).

Enabling this will bring parity between CustomersDot and Zuora.

Source of Truth

Zuora serves as the source of truth for Zuora Account and Zuora Contact data once a Subscription is purchased. Prior to a purchase, a user can register for CDot which creates a CustomersDot User record that isn't associated with an CustomersDot BillingAccount (because it doesn't exist yet). Once purchased, the CustomersDot BillingAccount record is created along with the related CustomersDot BillingAccountMembership.

Given that CustomersDot User/Zuora Contact and CustomersDot BillingAccount/Zuora Account information can be edited by users directly in CDot or directly in Zuora (or indirectly via SFDC), we need to be mindful of syncing this data between CDot and Zuora. In particular, if we can't use Zuora callouts to keep the CustomersDot BillingAccount and CustomersDot User records in sync, we will explore Zuora Custom Events.

A CustomersDot User record in CDot is tied to one email address. This email address can be associated with multiple Zuora Accounts, and therefore have multiple Zuora Contacts. Each of these Zuora Contacts could be modified independently. For instance, a billing admin may choose to change the address for Contact A for the billing entity in the US, but not choose to change the address for Contact B (associated with the same email address) for the billing entity in Europe. For this reason, contact metadata could eventually be stored on the CustomersDot BillingAccountMembership model, but we are choosing to keep this lightweight to begin with to reduce scope. We will start by fetching this data from Zuora.

GitLab.com SSO as the only sign in option for CustomersDot

With GitLab.com SSO as the only sign in option for Customers Portal, we can eliminate the legacy sign up (email and password) and prepare CDot for future integration with a third party e-commerce provider. Our goal is to streamline the experience between SaaS/self-managed and web direct/sales-assisted customers in how they access their subscription information.

Overall, this will lead to a more secure environment for our customers in CDot and allows us to establish a 1:1 relationship between a CDot customer and a GitLab.com account.

GitLab.com SSO as the only sign up option for CustomersDot

• CDot SSO: Remove email and password sign up
• CDot SSO: Enhance experience for first time login to CDot
• CDot SSO: Migrate more CDot customers to use the GitLab SSO for login

Align CustomersDot Orders to Zuora subscriptions and trials

Align CustomersDot Orders to Zuora subscriptions and trials

• Update Zuora Subscription API integration to more accurately determine subsription state
• Further iterations - TBD

This iteration focuses on breaking apart the CustomersDot Order table to more accurately reflect its representation of Zuora Subscriptions + Trials. In the future, we could explore moving the reference for GitLab Namespace from being stored on the Subscription (and Order) to a Zuora Account. See this LucidChart for more details.

Snowflake Data Warehouse and dbt (data build tool)

We extract data from the Quote to Cash systems towards Snowflake and use dbt to transform the data into data models for reporting and analysis.

Data Architecture Plan

The Fulfillment Team is re-architecting our Quote 2 Cash Systems, in particular CustomersDot, in a way that promotes more reliability, sustainability, and flexibility. The plan is described in this data_architecture.md file. A significant result of the new architecture will be to have the same customer definition in CustomerDot, Zuora, and Salesforce. This definition is based on the Billing Account in Zuora and the key for the customer is the billing_account_id. It is necessary to re-architect the data model in Snowflake and dbt in order to align the customer definition to CustomersDot data tables. The data models built that model the Zuora and Salesforce systems have the correct customer definition and no rearchitecting needs to happen for those models at this time.

Important Callouts for the Customer Definition in the Unified Q2C data model:

1. The unified customer key is the Billing_Account_Id which joins the systems together. The Billing_Account_Id appears on Q2C systems as follows:
   1. Zuora.Account.Account_Id
   2. CustomersDot.Billing_Accounts.Billing_Account_Id
   3. Salesforce.Billing_Account.Billing_Account_Id
   4. DRAFT: GitLab_Dotcom.Organization.Billing_Account_Id The Organization Entity Object has not been created yet in GitLab_Dotcom and is still in the validation process. The Billing Account Id Foreign key needs to be determined.
2. The source id data (where the data is originated and is considered the SSOT) for billing_account_id lives in Zuora.
3. The customer definition is only unified for billing accounts that are in Zuora and Salesforce which are generally limited to paying and formerly paying customers and edu/oss customers.
4. The target state for trials is to put them into Zuora. At that time, we would be able to have a unified definition for customers across CustomersDot, Salesforce, and Zuora for their trial to paid activity.
5. The target state for how to unify the customer definition for free customers across the Q2C systems needs to be determined. The quantity of free users presents challenges for putting them into Salesforce and Zuora. This area needs further exploration.
6. The Account object in Salesforce can have customers that will have a billing account or it can have prospect accounts that do not have a billing account.

Below is the Entity Relationship Diagram for the Re-architected data model in Snowflake. The Target State tab shows how the business entities we extract from the CustomersDot, Zuora, Salesforce, and GitLab.com source systems connect with each other.

ERDs (Entity Relationship Diagrams) for Business Process Modeling

These ERDs illustrate how we model data from the Quote to Cash Systems in the Snowflake Enterprise Dimensional Model.

dbt Data Lineage Diagrams and Data Dictionaries

Quote to Cash Data Lineage Diagrams illustrate how the data from critical Quote to Cash source tables flow through the Snowflake data models.

Quote to Cash Data Dictionaries provide definitions for the Quote to Cash fields used in the Snowflake Enterprise Dimensional Data Model.

Business Insights and Analysis

Our Data Catalog provides access to Analytics Hubs, Data Guides, ERDs, and Analytics projects relating to the Quote to Cash business processes.

• Lead to Cash Data Catalog
• Product Release to Adoption Data Catalog