Missing field entries (data) on submission

Matt Pallatt

Vote:

We have a set of Opti Forms that are multi step. At the end of the data collection process we're using a form actor to shunt the data off to a service which is transforming the data and uploading it to a client endpoint.

We have a problem in that "sometimes" the data is incomplete - so even though their is validation on fields, and the forms can't be finished without values for certain fields, when it ends up at the client endpoint, the fields that should have user data are empty. This happens around 10% of the time. And the fields that are empty are not always the same ones. Sometimes we have all data come through fine, sometimes its 8 fields of 15 come through fine, sometimes its 5 - there seems to be no method to the madness. Due to the nature of the data we can't store is locally or mail it anywhere.

We're using Opti 11, and Forms 4.31.0, and the environment is load balanced across two front end servers.

Does anyone have ANY CLUE what might be happening?

#341547

Jan 29, 2026 9:26

Eric Herlitz

Vote:

Can you reproduce this in other environments, e.g. local development evnrionments, test env etc?

If not then try to disable one of the frontends in the load balancer (as a test) and try if you still can reproduce the problem. If it is this is usually solved by enabling sticky sessions at the load balancer or move to a shared session store where you move session out-of-proc (SQLServer/StateServer/Redis depending on your stack) so both nodes see the same session.

#341551

Edited, Jan 29, 2026 21:34

Keshav Dave

Vote:

I agree this looks like a load-balancing/session issue rather than a Forms bug.

In Optimizely Forms (on Optimizely CMS 11), multi-step forms store intermediate data in session state. If you're running InProc session in a load-balanced setup without proper sticky sessions (or shared session state), different steps can hit different servers — which results in partially missing form data.

The “random” missing fields and ~10% failure rate are typical symptoms of this.

I would:

Temporarily disable one frontend to confirm
Verify sticky sessions are enabled
Preferably move session out-of-proc (SQL/StateServer/Redis) so both nodes share session state

This is usually the root cause in multi-step forms behind a load balancer.

#341704

Feb 15, 2026 20:13

Eric Herlitz - Feb 16, 2026 17:33

Wow, did ChatGPT use my answer to generate that?

Keshav Dave - Feb 16, 2026 20:46

I expanded a bit on your point around session handling in multi-step Forms, but yes - we’re aligned on the same likely root cause 🙂 Appreciate you calling out the load-balancing angle.

Eric Herlitz - Feb 16, 2026 21:23

Load-balancing in combination with inproper MachineKey's is where I would start looking, but then externalising session management when in loadbalanced environments is never a bad idea if it also include shared caching etc.

Matt Pallatt

Vote:

Thanks Keshav.

Not in a position to disable front ends unfortunately, SS are verified, and moving session state is currently not really an option either.

We enabled storing data temporarily (1 day) and this seems to have addressed the problem, albeit don't really want data sitting in the CMS for that long.

Will hopefully sort itself once we've upgraded to CMS 12.

#341705

Feb 16, 2026 9:24

Eric Herlitz - Feb 16, 2026 17:34

CMS12 wont fix that, I should have mentioned that you should check that the MachineKey's are identical across your servers.