A long SharePoint form can run as a wizard: one step at a time, Next and Previous buttons, a visible path from start to finish. In Ultimate Forms, wizard mode is two settings on the Tabs control, show navigation buttons and make them the only way to move, and from there the pattern grows as far as the process needs: steps that branch on earlier answers, salary sections only HR can see, and forms that pause mid-way and reopen exactly where the user left off. This guide covers the concept, the mechanics, and the three patterns, branching, security, and persistence, that turn a segmented form into a guided process. For the click-by-click build with every setting shown, see the hands-on walkthrough; for where wizards sit in the wider toolkit, the ten must-have features.
Why steps beat scrolls
A traditional SharePoint form shows every column at once, and when the list has grown to dozens of columns, the form has quietly become a wall. Users facing a wall do predictable things: abandon, rush, or fill in whatever silences the required markers, and each response costs the process either a submission or its data quality.
The wizard replaces the wall with a path. Each step holds one topic's columns, contact details, then specifics, then attachments, so the user answers one recognizable question at a time. Nothing is removed from the form; everything is removed from the moment. Step three of five feels finishable in a way forty columns never do, which is the same psychology every checkout flow on the internet runs on, and the reason wizard-style entry measurably reduces both abandonment and skipped columns.
Steps also give the designer control of order. With free navigation, users wander; with button navigation, they travel the form in the sequence the process intends, which matters whenever later steps depend on earlier answers, the branching pattern below being the obvious case.
The mechanics: two settings on the Tabs control
Wizard mode is not a separate feature to learn; it is a behavior of the Tabs control every tabbed form already uses. The build is short. Divide the columns into tabs, one logical step each. In the Tabs control properties, enable Show tab navigation buttons, which produces Next and Previous. Then enable Use only buttons, which stops tab headers from being clickable, so the buttons are the sole way through.

From the user's side: a new item opens on step one, with Next, Previous, and Save. Next advances, Previous returns, Save stores and exits. The restriction is configurable per form type, and the usual choice is to enforce it on New forms only, a first submission benefits from sequence, while someone editing one value later should jump straight to it.
Everything else about good multi-step design, the Progress theme that turns tab headers into step markers, icons per step, callout help, button placement, belongs to the companion piece: build multi-step SharePoint forms with tabs.
Pattern one: steps that branch
The strongest argument for enforced sequence is branching: later steps shaped by earlier answers. The classic shape is the insurance claim. Step one asks the claim type, Car or House. Step two is the car-damage step or the property-damage step, never both, because permission rules on the tabs show each one only when the matching type is selected. A third step might exist only conditionally, appearing when attachments were indicated.
The user experiences a short, relevant form; the designer maintains one form, not one per claim type. Branching is why order matters: the form can only shape step two correctly because step one is guaranteed to be answered first, which free tab-clicking never guarantees.
Pattern two: steps with different audiences
Tabs take permission rules by role as well as by data, which turns the wizard into a multi-audience instrument. The onboarding form shows the identity and equipment steps to everyone, while the salary step exists only for HR; the IT request shows the scheduling step to the requester and the review step to the service desk. One form serves every participant, each seeing exactly their steps, with column-level permissions refining the picture inside any step. This is the same machinery that runs staged business processes, with the wizard supplying the navigation.
Pattern three: pause and resume
Long processes rarely finish in one sitting, an onboarding packet gathers documents over days, a claim waits on an estimate, and a wizard that loses the user's place punishes exactly the thorough users it should reward.
Session persistence is built from pieces the form already has. A status column, hidden from the form, records progress: dynamic rules set its value from what the tabs contain, step two's key columns filled means status reaches step two, and so on. The user saves mid-way with no ceremony; everything entered is stored, because each step is real columns on a real item, not a client-side draft. On reopening, a rule reads the status column and lands the user directly on the tab where they stopped, a technique with its own detailed article. To the user it feels like the form remembered them. It did, with three rules.
The wizard as a process front end
The three patterns compound when the wizard feeds the rest of the platform. Each step can carry its own validation, so data quality is enforced per topic rather than in one save-time pile. Completing a step can trigger the machinery beyond the form: an alert to the next participant when step three's data lands, an action creating tasks from the finished request. Signature columns in the closing steps, with earlier tabs locked read-only once signed, produce the staged, tamper-resistant flows that regulated processes require. And where the process's decisions need formal approvals with reminders and logs, the wizard hands off to the approval machinery rather than reinventing it in tabs.
Three deployments show the range. The insurance claim: five steps from claimant details through branching damage sections to document upload and review, pausable while the police report is obtained. Employee onboarding: identity, compliance, IT setup, training acknowledgments, spread comfortably over the week they actually take, with HR-only steps invisible to everyone else. The IT service request: type selection branching into hardware or software details, then scheduling, then the admin review step that only the service desk sees.
Keeping the wizard honest
Two design disciplines keep wizard forms deserving of the pattern. Keep step counts in the three-to-six range, each answering one question the user recognizes; a twelve-step wizard is usually a process problem wearing a UX costume. And reserve enforced button navigation for the forms and form types where sequence genuinely matters, forcing an editor to click Next four times to fix a typo on step five teaches users to resent the pattern. The wizard is a tool for guiding first entries through dependent steps; used there, it reads as helpfulness, and used everywhere, it reads as friction.
A long form is a fact of process life. The wizard's contribution is converting that fact from a wall into a path, with the branching, security, and persistence to make the path fit each person who walks it.

