Why must the business-customer LCP be coordinated with the account and password LCPs, and what is attribute ownership?

Because the CRM, through sales, and the self-service, through the customer, both write into the same IdP user, an operation of one LCP can overwrite or delete the other's data; deciding which source owns which attribute, for example the company from the CRM and the password from the user, keeps them from colliding.

Collisions that the coordination must prevent:

• Deleting what you did not create. The CRM delete removes the whole user, including a private account the customer set up personally before becoming a business customer.
• Overwriting a user's choice. In case 1.2, a careless sync could reset the user's own password to an initial one, or overwrite the name the user entered. The model correctly only adds the company.
• Updates in two directions. When a business customer's data changes, it must reach the IdP and the self-service, or the customer sees stale values in the portal.

The tool for this is attribute ownership: for every attribute, exactly one source is authoritative and the others only read it.

Name and e-mail are exactly the attributes both sources write, which is why the model leaves the handling of self-service users as something the account and password LCPs must agree on.

Go deeper:

• Master data management (Wikipedia) — deciding which system is authoritative for which data across an organisation.