Stop the Workarounds: We Need Native Multi-Step Forms

Stop the Workarounds: We Need Native Multi-Step Forms

After over 17 years of community requests, I'm hoping the Zoho team can finally address the lack of native multi-page form support in Zoho Creator. This has been one of the longest-standing feature requests in the community, with threads spanning nearly two decades:
The Issue
Zoho Creator currently has no native support for multi-page forms (also known as wizard forms, step forms, or tabbed forms). When building applications with complex data entry requirements—employee onboarding, loan applications, patient intake, vendor registration—developers have no built-in way to break a single form into logical, digestible steps.
Meanwhile, Zoho Forms has had robust multi-page form support for years, including page breaks, progress indicators, conditional page navigation, and page rules. This creates an inconsistency within Zoho's own product ecosystem.
The Product Asymmetry
The disparity between Zoho Forms and Zoho Creator is striking:
Capability Zoho Forms Zoho Creator
Page Break field type ✓ Native support
Drag-and-drop page breaks		 ✗ Not available
Progress indicator / Step bar ✓ Built-in
Shows respondent progress		 ✗ Not available
Page navigation (Next/Previous) ✓ Automatic
Customizable button labels		 ✗ Not available
Conditional page skipping ✓ Page Rules
Skip pages based on answers		 ✗ Not available
Page-level validation ✓ Validates before advancing ✗ Not available
Single form, single record ✓ Yes ✗ Requires multiple forms
The irony: Zoho Forms—a standalone form builder—has more sophisticated form UX capabilities than Zoho Creator—a full application development platform. Developers building enterprise applications in Creator are stuck with inferior form experiences compared to a simple survey tool.
Example Use Case
Consider an Employee Onboarding Form with 40+ fields across these logical sections:
  • Step 1: Personal Information (name, contact, emergency contacts)
  • Step 2: Employment Details (position, department, start date, manager)
  • Step 3: Payroll & Banking (bank account, tax forms, direct deposit)
  • Step 4: Benefits Selection (health insurance, retirement plans)
  • Step 5: IT & Equipment (laptop preference, software access, badge photo)
  • Step 6: Policies & Acknowledgments (handbook, NDA, consent forms)
Desired behavior: User completes each step, sees their progress, and can navigate back to review previous sections—all within a single form that creates a single record.

Current reality: User is presented with a massive scrolling form with 40+ fields, or developers must implement complex workarounds using multiple forms, lookups, and Deluge scripts.
The Current Workarounds (All Suboptimal)
To achieve multi-page form behavior, developers are forced into one of these suboptimal approaches:
Workaround 1: Multiple Related Forms ("Form Chain")
Create separate forms for each "step" and link them via lookups. Use Deluge scripts to pass record IDs between forms and auto-populate fields. 
// Step 1 form On Success:
step2_url = "#Form:Step_2_Employment?Employee_Lookup=" + input.ID;
openUrl(step2_url, "same window");

// Step 2 form On Load:
if(input.Employee_Lookup != null)
{
    emp = Employee[ID == input.Employee_Lookup];
    input.Name = emp.Name;
    input.Email = emp.Email;
    // ... populate all fields from Step 1
}
  • Problem: Data is scattered across multiple tables
  • Problem: Complex lookup relationships and Deluge scripting required
  • Problem: No "go back" functionality—user must start over if they need to edit Step 1
  • Problem: Reporting requires joining multiple forms
  • Problem: Breaks the single-record-per-entity principle
Workaround 2: Stateless Form Daisy Chain
To avoid creating "junk" records when users abandon the form mid-process, advanced developers use Stateless Forms for intermediate steps, passing all field values via URL parameters, and only writing to the database on final submit. 
// Step 1 Stateless Form - "Next" button:
step2_url = "#Form:Step_2_Stateless?" 
    + "Name=" + encodeUrl(input.Name) 
    + "&Email=" + encodeUrl(input.Email)
    + "&Phone=" + encodeUrl(input.Phone)
    + "&Address=" + encodeUrl(input.Address)
    + "&City=" + encodeUrl(input.City)
    + "&State=" + encodeUrl(input.State)
    + "&Zip=" + encodeUrl(input.Zip);
    // ... repeat for EVERY field
openUrl(step2_url, "same window");

// Step 2 Stateless Form - "Next" button:
step3_url = "#Form:Step_3_Stateless?"
    // Pass ALL fields from Step 1 again...
    + "Name=" + encodeUrl(input.Name)
    + "&Email=" + encodeUrl(input.Email)
    // ... plus all Step 2 fields
    + "&Department=" + encodeUrl(input.Department)
    + "&Manager=" + encodeUrl(input.Manager);
openUrl(step3_url, "same window");

// Final Form - actually saves the record
  • Problem: Stateless forms cannot use advanced field types including Subforms, File Upload, Signature, Image, and Audio—severely limiting data collection capabilities
  • Problem: Every single field must be manually mapped in URL strings
  • Problem: Adding one field to the schema requires updating scripts on every "Next" button
  • Problem: URL length limits restrict how many fields can be passed
  • Problem: No "go back" functionality—previous values are lost unless passed forward
  • Problem: Extremely brittle—maintenance nightmare for forms with 30+ fields
Workaround 3: CSS Hacks ("Fake Tabs")
Use Notes fields with custom HTML/CSS to create tab-like visual navigation, combined with hide/show field rules triggered by a radio button "step selector." This can work with individual fields or Section fields (to hide/show groups at once). 
// Radio field "Current_Step" with options: Step 1, Step 2, Step 3...

// On User Input of Current_Step:
if(input.Current_Step == "Step 1")
{
    show Section_Personal_Info;
    hide Section_Employment;
    hide Section_Banking;
}
else if(input.Current_Step == "Step 2")
{
    hide Section_Personal_Info;
    show Section_Employment;
    hide Section_Banking;
}
// ... repeat for each step
  • Problem: Requires hiding/showing every field or section individually—maintenance overhead
  • Problem: CSS styling is fragile and may break with Creator UI updates
  • Problem: No native progress indicator—must build custom UI in Notes fields
  • Problem: Validation doesn't prevent "next step" navigation if current step has errors
  • Problem: All fields still load in DOM regardless of visibility, impacting performance
  • Problem: Collapsible sections are all visible simultaneously—not a true wizard experience with enforced linear progression
Workaround 4: Zoho Forms Integration
Build the multi-step form in Zoho Forms (which has native support), then push data to Creator via webhooks or integrations.
  • Problem: Requires additional Zoho Forms subscription
  • Problem: For in-app forms, users must leave the Creator application entirely, complete the form in Zoho Forms, then return to Creator—a jarring, disconnected experience
  • Problem: Data synchronization is not instantaneous—there can be delays before records appear in Creator
  • Problem: Loses Creator-specific field types (lookups to existing data, formulas, subforms)
  • Problem: Integration complexity and potential sync failures
  • Problem: Cannot use Creator's built-in workflows on form submit—must rely on integrations
Workaround 5: Custom JavaScript Widget
Build a completely custom multi-step form interface using a JavaScript Widget that handles the UI, then submits data to Creator via API.
  • Problem: Requires JavaScript development expertise—completely inaccessible to citizen developers and new users who chose Creator specifically for its low-code promise
  • Problem: Must build and maintain custom form validation, navigation, progress indicators from scratch
  • Problem: Loses all native Creator field types and behaviors—must recreate lookups, dropdowns, validations in JavaScript
  • Problem: API authentication and connection management adds complexity
  • Problem: Widget UI doesn't automatically match Creator's styling or theme changes
  • Problem: Significant development time for what should be a basic platform feature
What Should Happen Instead
Proposed Solution 1: Page Break Field Type
Add a "Page Break" field type to the Form Builder (matching Zoho Forms functionality): 
Form Builder → Field Types → Page Elements → Page Break

Drag the Page Break field between sections to create multi-page forms.
Each page displays with Next/Previous navigation buttons automatically.
Proposed Solution 2: Progress Indicator Configuration
Allow developers to configure a progress bar or step indicator: 
Form Properties → Multi-Page Settings:
  ☑ Enable progress indicator
  ○ Progress bar style
  ○ Numbered steps style
  ○ Named steps style
  
  Step Labels:
    Page 1: "Personal Info"
    Page 2: "Employment"
    Page 3: "Payroll"
    ...
Proposed Solution 3: Page-Level Validation
Validate required fields on the current page before allowing navigation to the next page: 
// Deluge: On Page Change (new event)
if(input.Current_Page == 1 && input.Email == null)
{
    alert "Please enter your email address before continuing.";
    cancel page change;
}
Proposed Solution 4: Conditional Page Navigation (Page Rules)
Allow pages to be skipped based on field values (matching Zoho Forms' Page Rules): 
Page Rules:
  IF Employment_Type == "Contractor" THEN skip "Benefits Selection" page
  IF Country != "USA" THEN skip "US Tax Forms" page
Real-World Impact
This limitation affects any application requiring:
  • Employee onboarding — HR systems with 30-50+ fields across multiple categories
  • Customer applications — Loan applications, insurance quotes, account opening
  • Patient intake — Medical history, insurance, consent forms, symptoms
  • Vendor registration — Company info, compliance documents, banking details
  • Event registration — Attendee info, session selection, dietary requirements, payment
  • Grant applications — Project details, budget, team info, supporting documents
  • Any complex data collection — Where form abandonment due to length is a concern

User Experience Impact: Research consistently shows that multi-step forms have significantly higher completion rates than single long forms. This is due to the "Goal Gradient Effect"—users are psychologically more motivated to complete a task as they see progress toward the finish line. A progress bar creates momentum; an endless scroll creates cognitive overload and abandonment.

Database Architecture Impact:
The workarounds described above force developers to fragment a single logical entity (e.g., "Employee") into multiple physical tables (Personal_Info, Employment_Details, Banking_Info, IT_Equipment) just to achieve visual pagination.
  • Reporting nightmare: Every report requires complex joins across multiple forms
  • Integration complexity: External systems expect a single record, not fragments across tables
  • Data integrity risk: Orphaned records when users abandon mid-process
  • API overhead: Multiple API calls required to fetch what should be one record
The desired state is simple: one logical entity = one database table, with the UI handling pagination visually—not structurally.
The Business Case for Zoho
Why this benefits Zoho:
  • Product consistency: Aligns Creator with Forms and other Zoho products that already support multi-step data entry
  • Competitive positioning: Platforms like Salesforce, Microsoft Power Apps, and OutSystems offer native wizard/multi-step form capabilities
  • Reduced support burden: Eliminates community posts and support requests for workarounds for this basic functionality
  • Enterprise readiness: Complex enterprise applications require sophisticated form UX—this is table stakes for enterprise adoption
  • Developer productivity: Native wizard capabilities remove the overhead of building UI workarounds from scratch, cutting development cycles by hours. Instead of troubleshooting custom flow-control scripts, developers can focus on optimizing user experience and accelerating time-to-market for core business features.
Request to Zoho Team

Can this finally be addressed?

After over 17 years of community requests, the need is clear and well-documented. The current implementation forces developers to choose between:

1. Poor User Experience
Present users with overwhelming, scroll-heavy single-page forms that increase abandonment rates 		2. Excessive Complexity
Spend days implementing fragile workarounds using multiple forms, CSS hacks, or external integrations

We shouldn't have to make this choice—especially when Zoho Forms already has this capability built-in.

Community Input Requested: What workaround have you used in the absence of native support? Please add your voice to this long-standing request.


    Nederlandse Hulpbronnen