Adjuster Review Screen: 62 Fields, 2.5 Seconds, and a Tablet
An adjuster's Review Claim assignment renders one section: 62 fields plus a repeating grid of line items holding up to 40 parts. Changing the Damage type dropdown runs an action set that refreshes the whole section so conditional fields appear; each refresh takes about 2.5 seconds, moves focus back to the top, and discards whatever the adjuster had typed in the Notes text area. Validation is configured to run on every change, so a half-typed claim number turns red while the adjuster is still typing. On a tablet the section collapses to a single column but the line-item grid stays wide and scrolls horizontally off the screen, so the totals are invisible. The team's proposed fix is to delete the conditional logic and always show all 62 fields, which they argue will also improve performance.
1. Diagnose the refresh problem and propose a design. Be explicit about what should be refreshed, what should not, and why the team's proposed fix does not solve it.
Read the worked answer
Diagnosis
The cost is not the conditional logic; it is the scope of the round trip. Refreshing the whole section re-evaluates every control in it, including the 40-row grid, and re-posts the entire form. Focus returns to the top because the region is replaced, and Notes is lost because it lives inside the replaced region and its uncommitted value is not carried across.
Design
- Shrink the refresh region. Put the conditional fields in their own section or layout and refresh only that, not the parent.
- Prefer client-side visibility. If the condition is a simple comparison on Damage type, a When rule driving layout visibility can show and hide without a server trip at all. Reserve server refresh for fields whose content must be recalculated.
- Get Notes out of the blast radius. Move Notes outside the refreshed region so it cannot be discarded, and stop triggering refreshes on every change of a free-text field.
- Protect the grid. Do not include the 40-row grid in a region that refreshes on dropdown change. If it must be nearby, defer-load it so it is not rendered on first paint, and keep row-level work to a row-level refresh.
- Confirm with measurement. Time the interaction before and after; if a refresh of a narrowed region is still 2.5 seconds, the cost is in the data derivation, not the layout.
Why deleting the conditional logic fails
It increases the rendered form length and the per-field cognitive load, and hidden fields still submit - so the payload barely shrinks. The round trip remains. It trades a performance symptom for a usability defect.
2. When should validation run on this form? Propose a rule set and explain how it interacts with the flow action.
Read the worked answer
Principle
Validate at the moment the user can act on the result. On-change validation of a field the user is mid-way through typing produces a transient error state, trains people to ignore red, and - if validation also gates a refresh - multiplies server calls per keystroke.
Rule set for this form
- On blur for format and completeness of high-value identifiers (claim number, policy number) - the value is complete when focus leaves, and the feedback is immediate enough to be useful.
- On change only where the value drives a dependent lookup or a refresh, and only for fields whose value is chosen rather than typed (dropdowns, dates, lookups).
- On submit for everything cross-field: totals versus line items, reserve amount against authority limit, required documents present. Cross-field checks cannot be evaluated meaningfully field by field.
- No validation on the Notes field beyond maximum length.
Interaction with the flow action
Separate "Validate" from "Submit": validation runs the declared and constraint checks without processing the flow action, so errors return the user to the same form with input preserved. Configure the flow action so a validation failure does not silently discard the screen, and show a consolidated error summary near the submit control - with 62 fields, per-field errors alone are not discoverable. Finally, keep a server-side check on submit for the claim-number format even though the client validates: client validation is for the user's benefit, not a control.
3. Address the tablet layout. What would you change, and what would you tell the team that proposes removing the conditional fields?
Read the worked answer
Layout changes
- Use responsive breakpoints with a device-appropriate screen layout rather than letting the desktop section reflow. Decide what a tablet user actually needs on screen and design for that width.
- The grid is scrolling off-screen because columns have fixed pixel widths. At the small breakpoint, stack each row as label/value pairs, or drop the non-critical columns and keep identifier, quantity, and amount - but keep the totals visible, because the totals are the decision.
- Move the totals into a summary layout above the grid (or pin them) so they are not a function of horizontal scroll. If adjusters must see running totals while editing, the total should recompute and remain visible as they type.
- Check the entire path, not just this section: the submit control and error summary also have to be reachable on the tablet.
What to tell the team
That the two problems are independent. Removing conditional fields changes what is displayed; it does not change the round-trip cost that causes the 2.5-second pause, and it makes the small-screen problem worse by adding more fields to the column stack. Fix the refresh scope for performance, fix the layout for the tablet, and leave the conditional logic to do its job - while confirming, with the adjusters, which conditions are genuinely worth a round trip and which can be a client-side visibility rule.