A business customer tells sales that her e-mail address changes from old@firm.ch to new@firm.ch. Why does the provisioning need the old address, and what happens without it?
Because the e-mail is the key that links CRM customer and IdP user, the user can only be found under the old address; the update must look it up with the old value and then overwrite it, which is why the model assumes the CRM keeps a change history.
The update flow branches on exactly this question:
- E-mail unchanged: find the user by e-mail, change the other attributes (for example the company).
- E-mail changed: find the user by the old e-mail, then set the new one.
Without the old value, the sync only sees "customer with new@firm.ch". It searches the IdP, finds nobody, and concludes it is a new customer: it creates a second user with an initial password, while the original user, still holding the company, remains under old@firm.ch with no matching CRM entry. The result is a duplicate plus an orphan, an inconsistency that later shows up as an irregular case.
The underlying lesson is about keys. The e-mail is a natural key (a business key that comes from the real world), and real-world values change. Robust designs therefore link systems with an immutable identifier, for example by storing the CRM customer ID on the IdP user, and treat the e-mail as an ordinary attribute. NIST's identity guidelines make the same point for accounts: each account gets a unique, preferably randomly generated identifier.
Go deeper:
Natural key (Wikipedia) — business keys, and why they are less stable than surrogate keys.- NIST SP 800-63A: Subscriber accounts — why each account should carry a unique, randomly generated identifier.
- Change data capture (Wikipedia) — techniques for capturing old and new values of a change for downstream systems.