UI Builder — client state parameter (complex array) cannot be read back through ANY binding

[JamesBateman]

I have a List selector (Manual mode, Two panels) whose Selected Items writes correctly to a complex-array client state parameter ({id, label} objects) via the native SELECTED_ITEM_SET event → "Set client state parameter" response. The write is confirmed working — the List selector's own "Selected columns" panel correctly reflects ticked items every time.

The problem: I can't read that same parameter back out anywhere else on the page, no matter the mechanism. I've tried:

• Native array-typed prop binding on a REST Data Broker — always sends []
• STRING() formula wrapping the state — always empty
• Script-mode property/event-response bindings — silently fail to persist (revert to boilerplate on reopen)
• A Data Broker Scriptlet reading the same state — never surfaces a selectable output pill, even with output_schema set
• PICK() extracting IDs into a separate simple-array parameter — same result, nothing readable
• Plain Pill-view binding, no formula at all — shows nothing

Goal: send the List selector's current selection as a JSON array in a POST body via a REST Data Broker.

Has anyone hit this — complex-array client state that writes fine but can't be read back through any binding type? Known limitation, or a pattern I'm missing?

[JamesBateman · Accepted solution]

Solved! I had a private suggestion to bypass all the binding dialogs and log the raw payload directly via a genuine Client Script (not an inline "script mode" box inside a response dialog — a real, separately-saved script asset) is what actually cracked this.

Turns out there wasn't a platform ceiling on reading complex-array client state at all. Two separate bugs were compounding:

1. The event payload shape wasn't what any binding dialog implied. List selector's SELECTED_ITEM_SET event doesn't expose a flat items array — every dialog's "items" pill is a label mapping to the real key, event.payload, and that payload arrives as one separate single-item sub-array per currently-selected field (e.g. 3 ticked fields → [[{id:"a"}], [{id:"b"}], [{id:"c"}]]), not one flat array. Every formula/binding I'd tried (STRING(), PICK(), native array-prop binding) was silently resolving to the wrong node the whole time, because nothing in the UI ever surfaced what the raw shape actually was. Fix: flatten every sub-array together rather than assuming a flat structure.

2. A reactive input binding isn't safe to use for an explicit action. Getting genuinely correct data into the Data Broker required a live reactive binding (input bound directly to client state) — but that means the resource re-invokes on every state change, not just on button click. REFRESH has no per-invocation input override (confirmed: its own Configure step says "REFRESH does not have configuration options"), so there was no way to keep it reactive-for-data-correctness while explicit-for-timing.

Fix for #2: skip the Data Broker/REFRESH pattern entirely for this action. The button's own Client Script reads state fresh at the moment of click and calls the Scripted REST API directly via helpers.snHttp(url, {method, headers, params, body, batch}) — a genuine HTTP client available inside Client Script handlers. Worth noting this is distinct from Data Broker Scriptlets, which do not have fetch available at all — helpers.snHttp inside a Client Script is the one that works.

Marking this solved — hope it saves someone else the same rabbit hole which cost me 3 nights work!!