A cheese dairy runs a webshop for both private and business customers and introduces IAM with a CRM, an identity provider (IdP) and a self-service portal. Which system holds which customer data, and who writes it?
Sales staff enter business customers (e-mail, company) in the CRM; private and business customers register themselves in the self-service (name, password, e-mail, consent); both sources feed one user object in the IdP (name, password, e-mail, company).
* Two writers, one IdP user: that shared object is why the life cycles have to be modelled. *
The scenario is a classic B2C plus B2B setup. After a risk analysis, the company decided on two things:
- Self-service for every customer. Anyone who wants to order registers in a portal with name, password and e-mail, and ticks a consent box for the processing of their data.
- Extra data for business customers comes from sales. When a contract is signed, a sales employee records the business customer in the CRM (customer relationship management system) as a Customer with the contact person's e-mail and the company.
The IdP is where authentication happens, so it holds the merged picture: a User with name, password, e-mail and, for business customers, the company. The e-mail address appears in all three systems and is the key used to recognise that a CRM customer and a self-registered user are the same person.
The important consequence: the IdP user has two independent writers. A customer may create it by registering, and sales may create or change it through the CRM, in either order. Every life-cycle process in this topic exists to keep that one object consistent.
Go deeper:
Identity provider (Wikipedia) — what an IdP stores and offers to the applications that rely on it.
Customer relationship management (Wikipedia) — the system class that holds the business-customer master data here.