Skip to content

Update SFDC Contact creation during PoD email delivery

Problem

As part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/8956+ we included the complete mailing address to SFDC Contacts upon creation.

Currently in CustomersDot the SFDC Contact records are created via one of these flows:

When the Contact is created as part of the VoucherMailer logic that is our PoD (proof of delivery) email, it is created based on the passed vouchable. The vouchable can be either a customer, a subscription or a license at this point. Not all the vouchable have the mailing required information.

Another identified issue around this SFDC Contact creation flow is that currently the approach to check for if there is already an existing Contact has diverged from the approach we use during the "regular flows" (first two in the list above) that is: We try to match by Sold To Contact email address, then customer email, then placeholder email.

Here is an passed vouchable overview (have to scroll horizontally):

Mailer Usage Context email vouchable
ActivationCodeVoucherMailer 1 ActivationCodeNotificationService activation_code subscription
CloudLicenseVoucherMailer 1 OnlineCloudLicenseNotificationService renewal_notification subscription
+ 2 OnlineCloudLicenseNotificationService subscription_update_notification subscription
CustomerVoucherMailer 1 FindOrCreateCustomerService new_customer customer
+ 2 SaasPurchaseNotificationService unlinked_saas_purchase subscription
LegacyLicenseVoucherMailer 1 LegacyLicenseNotificationService trial_license_email license
+ 2 LegacyLicenseNotificationService license_email license
OfflineLicenseVoucherMailer 1 OfflineLicenseNotificationService license_email license
SaasVoucherMailer 1 SaasPurchaseNotificationService renewal_notification subscription
+ 2 SaasPurchaseNotificationService subscription_update_notification subscription
+ 3 SaasPurchaseNotificationService standalone_add_on_renewal_notification subscription
+ 4 SaasPurchaseNotificationService standalone_add_on_notification subscription
UnifiedVoucherMailer 1 ActivationCodeNotificationService transaction_notification subscription
+ 2 ActivationCodeNotificationService transaction_notification subscription
+ 3 SaasPurchaseNotificationService transaction_notification subscription

Important open questions

We need to find out:

❓ Given PoD emails are used for revenue recognition, do we want to send these for Leads?

❓ Given we have the Provision Tracking System now, should we advocate to move to use that for PoD and drop all the PoD email logic from our codebase?

Proposal

We need to review this logic altogether and:

  • Identify in which scenarios a Contact doesn't exit at this point.
  • Try to reuse the CreateSalesforceContactService to create a contact at this point based on the vouchable, for this we need to agree on a way to get to a contact / customer via any of the possible vouchable provided.
  • Or we can decide we want to drop SFDC Contact creation at this point altogether as it shouldn't be the mailer responsability.

⚠ The SFDC Contact is required during the PoD email delivery as the ID for the SFDC Contact needs to be included in the email body so the email is correctly associated to it in SFDC. These PoD emails are required in certain cases for revenue recognition so we need to make sure that we still are correctly sending / associating the emails with the determined solution.

It is possible that since this was implemented there are other ways to associate the emails with a Contact is SFDC. We might want to review this.

If on identifying the cases that lead to the Contact not being present we realize we have gaps in the Contact creation then maybe we can address these gaps and drop the SFDC Contact creation during the PoD email altogether. We can also update the way we check for the Contact by getting the "best match" for the vouchable at hand e.g. for a subscription we can get the Sold To Zuora Contact's email...

Result

If we decide to keep the SFDC Contact creation during PoD guard:

  1. The SFDC Contact created during the PoD email have a complete mailing address.
  2. The logic that tries to check for the SFDC Contact existence during the PoD email delivery follows the same logic: Try to match by Sold To Contact email address, then customer email, then placeholder email. so we don't create additional Contacts for the Account if we don't have to.

If we decide drop SFDC Contact creation during PoD guard we need to first:

  1. We add logging for any instance when we cannot resolve a Contact during PoD email delivery.
  2. We monitor the logging and make sure we look into failures here to identify causes.

Other related issues

These issues / epics impact our current PoD emails and are relevant for this work:

Edited by Vladlena Shumilo