What are the typical mistakes when modelling IAM life-cycle processes?

Modelling only creation, creating without first searching for an existing object, linking systems with a key that can change, letting different views of the process disagree, covering only the happy path, and forgetting the dependent LCPs such as password and consent.

Each one maps to a concrete failure in the webshop scenario:

1. Only "create" is modelled. Without update and delete, accounts outlive the business relationship: stale data and orphaned accounts.
2. Create without search. A business customer who already registered privately gets a second IdP user (duplicate identity).
3. A mutable matching key without history. An e-mail change looks like a brand-new customer: duplicate plus orphan.
4. Views that contradict each other. The text propagates deletions to the IdP while the system view has no delete path; one of them will be implemented.
5. Only regular cases. Without defined warnings and errors, intermediate states and real inconsistencies are either ignored or flood operations with false alarms.
6. Dependent LCPs forgotten. Deleting an account without the password, creating a user without an initial password, processing data without checking consent.
7. One representation for everyone. The lawyer cannot review a sequence diagram, the manager will not read a state table, and the review that would have caught the problem never happens.

Tip: A quick review routine: for every object, check create/update/delete exist; for every create, check there is a search first; for every key, ask "can this value change?"; and compare at least two views of the same process.

Go deeper:

• System for Cross-domain Identity Management (Wikipedia) — the standard protocol for propagating user create, update and delete operations between systems.
• RFC 7644: SCIM protocol, creating resources — how a provisioning client creates users and receives the server-assigned id used for later updates and deletes.