When building a long survey in the KoboToolbox Form Builder, I started noticing that the editor becomes very slow after adding several repeat groups and nested questions. At first everything worked normally, but once the form grew larger, every edit began taking several seconds to respond. Sometimes the page freezes briefly before becoming usable again.
Another issue is that changes made to question labels or relevance conditions occasionally do not appear to save correctly. I can click Save, and there are no visible errors, but after refreshing the page, some of the recent edits are missing. This does not happen every time, which makes it difficult to reproduce consistently.
I also noticed that opening repeat groups or moving questions within the form takes much longer than expected. Dragging and dropping questions sometimes causes the interface to become unresponsive for a short period. My browser does not crash, but the editing experience becomes frustrating on larger forms.
To rule out local issues, I tested the same project in both Google Chrome and Mozilla Firefox with all extensions disabled. I cleared the browser cache and even tried using a different computer, but the behavior remained the same. My internet connection is stable, and smaller forms work without any noticeable delays.
The form contains many skip logic rules, calculations, and repeat groups because it is designed for field data collection. I am wondering if there is a recommended limit for the number of questions or nested repeats in the online Form Builder. If so, is XLSForm a better option for managing complex forms of this size?
Has anyone else experienced slow performance and inconsistent saving when working with large KoboToolbox forms? I would appreciate any suggestions for improving the editor’s responsiveness or identifying whether this could be related to a known limitation or configuration issue. Any troubleshooting steps or best practices would be very helpful. Sorry for long post!
Short answer: YES, if you’re building a form with complex logic, validation constraints, calculations, repeat groups… all that good stuff. In my case, the default is always to open my spreadsheet and start building the XLSForm directly.
Plus, you can take advantage of all the spreadsheet functionality, like:
Bulk editing: copy, paste, formulas
Managing cascading selects with way less pain
Easy sharing and versioning
Once you get used to it, it’s hard to go back to the form builder for anything complex.
From my personal point of view, the web form builder is great for forms with a mid level of complexity, super friendly, but not ideal once things get heavy.
If you want to dive deeper into XLSForm, there are plenty of resources and you can get started here:
Thanks for the welcome and for sharing your experience. That actually makes a lot of sense and matches what I’ve been observing. My form has a large number of repeat groups, calculations, relevance conditions, and validation rules, so it sounds like I’ve reached the point where the online Form Builder is no longer the best tool for managing the project efficiently.
I hadn’t seriously considered switching the workflow to XLSForm before, but the advantages you mentioned especially bulk editing, formulas, version control, and easier management of complex logic—sound like they would make maintaining a form of this size much easier. It would also reduce the amount of dragging and clicking that’s currently slowing me down in the web interface.
I’ll start reviewing the XLSForm documentation and see if I can migrate the form while preserving the existing logic. Hopefully that will also resolve the occasional saving inconsistencies and improve the overall editing experience. Thanks again for confirming that this behavior is expected with larger, more complex forms and for pointing me toward a more suitable workflow.
You can always export a Formbuilder form into an XLSForm definition and work on it there instead. The caveat is that there are a few FormBuilder question types - specifically Rating, Question Matrix, and Ranking - that are actually ‘wrappers’ for a custom set of underlying interrelated XLSForm questions. So if you do export a FB form with these question types then you may end up with an XLSForm having a bunch of unexpected questions/groups in place of these.
You can also (always) import an XLSForm back into Kobo and work on it in Formbuilder. However, there are are few mostly advanced XLSForm features - eg background-geopoint, triggers, etc - that are currently unsupported in FormBuilder. So you may see an error/warning if you upload an XLSForm with these and then try to edit it with FormBuilder…
Typically, I find the Kobo Formbuilder is awesome for starting writing forms and even mocking something up quickly to trial and test out; I still use it a lot for this very purpose. But for more advanced forms, or ones that keep evolving in length and complexity, eventually you switch over to writing and editing it as an XLSForm. And never need to go back
