Validation in SharePoint forms can happen while the user works instead of when they try to save. In Ultimate Forms, real-time validation has two halves. Live feedback shows each column's status as the user types: a required column carries a visual warning that clears the moment it is filled, so the form guides instead of blocking. And live data checks validate against what is actually in the list, synchronously, before the save completes, which is how duplicate entries and overlapping bookings get stopped. Both are configuration, not code. This guide builds each one. They are the responsive layer of the full validation toolkit, built from the same rule types as everything else in Form Designer.
The save-time ambush
Default SharePoint validation has one move: a red asterisk at the start, silence in the middle, and a refusal at the end. The user fills a long form, misses something, clicks Save, and is blocked, then scrolls back through the page hunting for whatever the form knew about all along but chose not to mention. On internal forms this costs patience. On public-facing forms it costs the submission itself, because an anonymous visitor ambushed at the last step does not hunt; they leave, and the lost application or sale never reports itself.
The ambush is a design choice, not a necessity. The form knows at every keystroke which columns are satisfied. Real-time validation simply shares that knowledge as it changes, which converts the save from a judgment into a formality: by the time the user reaches the button, everything is already green.
Live feedback: the form that answers as you type
The pattern is built from style rules, and the user experience comes first. On opening, every required column shows its state plainly, the asterisk plus a pink background (a thin red border works too, if your style guide prefers it), so the form's demands are visible at a glance rather than discovered by trial:
As data goes in, the warnings go out, column by column, the pink clearing the instant each entry lands. The user gets continuous confirmation of progress, and whatever remains pink is exactly what remains to do:
Note what the second screenshot adds: the next section appears only once the first is valid, a permission rule conditioned on the same completeness, so the form reveals itself in earned stages instead of presenting its whole length upfront. Feedback and progressive disclosure, driven by one set of conditions.
The build is one rule, copied. Add a style rule to a required column: when the column is blank, apply the warning style, pink background or red border. The moment the condition stops matching, the style vanishes on its own, that is simply how style rules evaluate. Then copy the rule to every other required column, changing only the condition's target. Blank-check conditions cover most cases; where a column must match a pattern or range, the same rule style attaches to the real condition instead:
Ten minutes for a long form, and the validation experience changes category: users arrive at Save with nothing left to fix, which is the entire point. The warning that prevents an error outranks the error message that reports one.
Live data: validating against what the list already knows
The second half of real-time validation answers a question the form alone cannot: is this entry valid given everything already saved? No column comparison can see that a conference room is already booked for this slot, that a vendor with this tax ID already exists, or that this employee already has a pending request. The data that decides lives in other items.
The mechanism is a synchronous action. A Calculate Summary action counts list items matching your conditions, overlapping bookings, duplicate identifiers, open siblings, and runs before the save completes because it is marked Synchronous under its Advanced settings. The action either writes the count to the item or raises an error when the result fails your condition; set it to raise an error when the count is above zero, with a message that explains the conflict in business terms: "This room is already booked from 2:00 to 3:30. Choose another time."
The user experience stays honest to the real-time promise: the check happens at save, against the list as it is at that second, so even two users racing for the same slot resolve correctly, the second save finds the first one's booking and fails with the explanation. This is the check that client-side validation can never make trustworthy, because only the server knows what was saved a moment ago.
The two halves divide the labor cleanly. Everything the form itself can know, required columns, date logic, patterns, cross-column comparisons, gets live feedback while typing. Everything only the list can know gets the synchronous check at save. A booking form with both feels finished: the columns guide the user through a valid entry, and the save guards the one thing the columns could not see.
Where the pattern pays most
Long internal forms. The longer the form, the crueler the save-time ambush and the greater the feedback dividend. Forms past a screen in length should treat live validation as standard equipment, alongside the layout features that keep them navigable.
Public and external forms. Anonymous users have no patience, no training, and no second visit. Live feedback is the difference between a completed submission and a silent abandonment, and the synchronous check protects the back office from the duplicates that public volume produces.
Booking and allocation systems. Rooms, vehicles, equipment, time slots: anything exclusive needs the data check, because the conflict is invisible to the form and expensive after the fact.
Deduplication at entry. Vendors, customers, assets: a synchronous count on the natural key (registration number, serial, email) stops the duplicate at its origin, which is the only cheap place to stop it. Merging two vendor records a year later, with payments attached to both, is the expensive alternative that this one action quietly prevents.
One design habit ties the halves together: write every message, style or error, in the user's terms. Pink says "this still needs you"; the save error says what conflicts and what to do. Validation that explains converts frustration into guidance, and guided users produce the clean data the whole exercise exists for.
A second habit keeps the feedback honest over time: audit the warning styles whenever the form's requirements change. A column that stopped being required but kept its blank-state style rule now nags about nothing, and users who learn that pink sometimes lies stop trusting it everywhere. The feedback layer is cheap to build and cheap to maintain, but it does need the maintenance: the rule conditions should always mirror the actual validation rules, so the form's promises and its enforcement never drift apart.
Frequently asked questions
Add your comment
