Support changing emails in customer.io

[Will-Howard]

🧩 Summary

There are many automations in Airtable which submit to customer.io using an email field that exists on the recording question. We are working towards deprecating many of these email fields (#2459), and ultimately supporting changing the primary email on the user row, so we may need to change these automations.

Proposed general strategy: Keep most of the automations largely as-is, but make sure we're using the authoritative user.email field. Carefully migrate the few (such as this one in the CRM base) that set user-level properties.

✅ Definition of done

We support changing emails in customer.io, or at least have a plan to do so once we implement the overall email-change feature (#2570).

📌 Notes / Designs

No response

[Will-Howard]

Migration plan

At a high level, there are a few automations in Airtable that do identity-level things in customer.io (near-exhaustive list: 1, 2, 3), but most just trigger sending emails via a standardised sendDataToUniversalWebhook webhook (e.g. this automation).

With this in mind, these are the migration steps required to support changing emails in customer.io (keeping all history attached to the same consistent person). The general idea is to set the Applications User id as the id in customer.io, overriding the current email-based profiles. In cases where this depends on subtle behaviour of customer.io, I have tested with fake users how it behaves:

• In the website email-change code (Allow users to change emails #2570, tbd) add an updateCustomerIoEmail(userId, oldEmail, newEmail) side effect. This should (async, not blocking the user flow). Edit: In-progress as Add customer.io email-change primitives (unused, tested) #2825.:
  a. Check if any profile exists for the old email. If not, do nothing (the new email will be naturally picked up)
  b. If any profile exists with the old email, ensure the userId-based-profile exists: look up by id; if absent, identify({id}, {email: old})
  c. Run identify({id}, {email: new}) to update the email on the existing profile
  d. Verify by reading back (poll by id until email == new, ~5–15s observed latency). On error, assume collision; if the new email profile has been created in the meantime, delete it and retry; escalate to a Slack alert if there is still an error
• To ensure that profiles in customer.io are generally stamped by user id: Modify the hourly "Sync people to customer.io" automation to identify by User ID when we have one (blocked by Support changing emails in the CRM base #2809); Persons without a User ID keep today's email-only identify. The first id-keyed pass will upgrade the entire existing pool in-place. Edit: In-progress as Breadcrumb: CRM "Sync people to customer.io" automation: identify by user id where available #2827
• Unblocked once the above step is complete: Switch on the automation to propagate email changes to customer.io
• Audit every event sender: With the above two steps complete, automations using the sendDataToUniversalWebhook webhook to send emails should continue working (and email history should attach to the right profile). It is however worth double checking every one to ensure they are using the canonical email and are not doing anything else, there are 27 to go through (should take <1 min for each)
• Add a To-override for automations that send emails about specific application forms: There are some automations where we always want to send it to the email a user applied with, even if they later change their email on their Course Hub account. For these, we need to update the automation to override the "To" field to send to an explicitly set email rather the one tied to their profile

Regarding the email-change code itself (#2570), I suggest we build it alongside this step 1 here so we don't have to reconcile the two later, but don't expose it to users yet.

[Will-Howard]

I'm about to deploy admin-initiated email changes (#2828). This is safe to do now that the automation to propagate email changes to customer.io is turned on, the last two steps above will just be useful to catch edge cases