Write down every piece of state the workflow touches

Most multi-portal systems carry more state than their interfaces let on. There's the main business status, and then there are permissions, ownership, sync status, review status, payment or entitlement state, notification state, and whichever version of the data each component last saw. One label like "complete" can be squashing several of those together.

For the workflow you're releasing, make an inventory. For each state value, write down:

• the system that owns it
• the event that's allowed to change it
• the roles that can trigger that event
• the components that copy, derive or display it
• any delay you'd expect
• what evidence is left behind after a transition succeeds or fails
• how you recover when the transition stops halfway

Ownership has to be spelled out. Two services shouldn't each decide the same business fact unless there's a reconciliation rule between them. If an external service is the authority on settlement and your application is the authority on eligibility, name those as two separate facts. Calling both of them "approved" makes things ambiguous in the code, in the database fields and in the support instructions.

Derived state needs the same attention. A portal might show "ready" because four conditions are true, without ever storing a ready flag. Write down that rule and where it runs. If the staff portal, the customer portal and the API each implement it separately, either compare them line by line or move the rule behind one tested contract. Small differences pile up without anyone noticing: one path leaves out archived items, another uses a different date boundary, and a third treats a missing integration response as a success.

The inventory can stay small. It only needs to cover the workflow being released, so you don't have to model the whole product. What it should tell you is who owns each fact and how every other component finds out that it changed.