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.

A life-cycle process manages one information object, such as an account, a password, a consent or a customer, from its creation through its changes to its deletion, so at its core it consists of create, update and delete operations (CRUD).

Every piece of identity data is born, changes and eventually has to disappear. A process landscape that only models creation produces stale data and forgotten accounts; one that forgets changes lets systems drift apart. So for every managed object you ask three questions: how is it created, how is it changed, how is it deleted? CRUD (create, read, update, delete) is the shorthand. The "read" part is the object being used by other processes (authentication reads the password); the life cycle itself is about the three writing operations.

For each operation a good LCP description pins down:

1. Trigger: which business event starts it (a signed contract, a customer's request).
2. Actor: who performs it (sales staff, the customer, an automatic job).
3. Systems: which systems are read and written.
4. Preconditions and result: what must hold before, and what state every system is in afterwards.

The Swiss IAM glossary eCH-0219 describes provisioning in the same spirit: setting up, managing and removing digital identities or user accounts, typically covering initialisation, update, deactivation and deletion. Many real deployments add that intermediate deactivated / suspended state between "active" and "deleted", so an account can be blocked and restored without losing its history.

Go deeper:

• Create, read, update and delete (Wikipedia) — the four basic operations on stored data and how they map to SQL and HTTP.
• eCH-0219 IAM glossary V2.0.0 — the Swiss standard defining user account, provisioning and related terms (in German).
• NIST SP 800-63A: Subscriber account suspension or termination — the events that end an account's life cycle in a real identity service.