🧩 Summary
As part of #2459, ultimately to allow people to change their emails on the website (#2570), we need to support changing emails in the CRM base. The CRM currently uses email as the primary key, and rows are created by automations that upsert a Person based on the email from another synced base.
Proposed general strategy: Keep email as the primary key that appears for admins, but actually match on a stable user id (i.e. the id of the record in the User table) or keycloakIdentifier where possible, falling back to email only when we have nothing else to go on. When email changing is properly supported on the website, propagate this change to the CRM base (possibly keeping the old email(s) under an array for matching).
This needs to be worked out in lot more concrete detail before executing. I will leave a comment with the full migration plan.
✅ Definition of done
The CRM base supports (in principle) changing emails
📌 Notes / Designs
No response
🧩 Summary
As part of #2459, ultimately to allow people to change their emails on the website (#2570), we need to support changing emails in the CRM base. The CRM currently uses email as the primary key, and rows are created by automations that upsert a Person based on the email from another synced base.
Proposed general strategy: Keep email as the primary key that appears for admins, but actually match on a stable user id (i.e. the id of the record in the User table) or keycloakIdentifier where possible, falling back to email only when we have nothing else to go on. When email changing is properly supported on the website, propagate this change to the CRM base (possibly keeping the old email(s) under an array for matching).
This needs to be worked out in lot more concrete detail before executing. I will leave a comment with the full migration plan.
✅ Definition of done
The CRM base supports (in principle) changing emails
📌 Notes / Designs
No response