How is a state table (Zustandstabelle) for a life-cycle process built, and why is it the most rigorous representation?
Each row is one case: the state of every system before (CRM, IdP, self-service), the action to take, and the state of every system after; listing the rows systematically forces you to consider every combination of states, which is what makes gaps visible.
* One row per combination: the table is complete only when every realistic combination has a row. *
The regular cases for the webshop:
| Case | Before (CRM / IdP / SS) | Action | After (CRM / IdP / SS) |
|---|---|---|---|
| 1.1 New in CRM, rest unknown | new K1 / none / none | Create user with company; assign initial password | K1 / U1 with company and initial password / none |
| 1.2 New in CRM, rest known | new K2 / U2 without company / U2 | Add company in the IdP | K2 / U2 with company / U2 |
| 1.3 Not in CRM, new in self-service | none / none / new U3 | Create user including password in the IdP | none / U3 without company / U3 |
| 2.1 End-customer update | none / U4 / U4 changed | Update user attributes in the IdP | none / U4 with new values / U4 |
| 2.2 Business-customer update | K5 changed / U5 / U5 | Update attributes incl. company in IdP and self-service | K5 / U5 with new values / U5 |
After the regular cases come the potentially irregular cases (reported as warnings) and the irregular cases (reported as errors).
Why it is rigorous: a flowchart shows one path at a time, a table enumerates the space of situations. Asking "which combinations of CRM, IdP and self-service states exist?" surfaces cases nobody wrote down. And every row is directly a test case: given this state, when this action runs, then expect that state, which is why developers value it for unit tests.
Go deeper:
State-transition table (Wikipedia) — tables of current state, input and next state.- Decision table (Wikipedia) — the related technique of enumerating condition combinations, widely used to derive test cases.