Forms in the portal are wired straight to the record they edit: pick a delivery option in Share ⇒ as email, answer a quiz question, change a setting, and the choice is written to that record with no Save button in between. That is what keeps a half-filled form alive across a sign-in round trip or a reload.

It also means a form has something to be wired to — and sometimes there is nothing there:

Both are ordinary. Neither was handled: the form would try to open the missing record on every single redraw, fail, and try again on the next one. On screen the affected choice never loaded, so the form looked broken; behind it the portal was logging the same failure several times per redraw — on one deployment, 473 times across four days.

A record that is not there is now a state, not a failure. A form asks whether the record exists before it opens it, so the missing one is never reached for in the first place:

Nothing changes for a form whose record is there, which is nearly all of them.

The engineering rule behind it — read whether it is there one way, what it says another, and never paper over the difference — is in CQRS and Content Access and Data Binding.

Reconnecting…
The server was updated. Reloading the page to pick up the latest version.