Hi Folks, I have had ongoing issues with “nested” repeat groups. I have gone to all the posts, and looked at the new KoboToolbox documentation (November 2025), but I have been unable to resolve my issue. So I have created an exceedingly simple form, and I continue to get the same problem. The first repeat works - I can add responses so long as I don’t need to go into the next layer of repeats. Once I try to go down that extra level, the system breaks down and I mostly do not get the correct repeat loop questions. My simple form is uploaded below - if anyone can help me work out what I am doing wrong with this, I can probably work out how to fix more complicated forms. In the uploaded form, the breakdown occurs if you select
Sampling information for tagged trees & drop sheet trees
Tagged Tree (shows as Repeat 1 in Group 1),
Yes for nuts on the ground.
In the first instance, this allows you to enter information on a quadrat. Thereafter, it is not possible to get the questions on quadrants again.
@taniak, what have you been testing this with? The Collect Android App or Enketo? Could you also kindly share a screenshot of your error with the community please?
@Kal_Lam Happy New Year!! I have the problem in both Enketo and with KoboCollect on Android. The current small test file that I uploaded is not even deployed, because it fails to work even in the form preview of building a form. I have used the ODK Validator, and whilst it doesn’t give me any error message as such, when I preview the form online via this route, I get exactly the same error. In the screen grab below, the system works for the first entry, but then fails when I go to sample a 2nd tree. You will note that there is no drop-down menu at the bottom even though I have selected “Yes” to the previous Q (are there nuts on the ground).
Also, adding additional (non-repeat) groups into the fray probably only complicated matters further… So what I did was remove these additional (superfluous?) groups, and removed the relevant condition on the inner repeat group, and instead just applied it against all the enclosed questions [the only diff if that you now see the repeat, but all the questions within it remain hidden…].
Please take a look at my changes and see if it behaves a bit better for you:
I ran a few tests, and - if you ignore the empty nested repeat box when it doesn’t apply - it seems to be behaving a bit better. FYI I stripped out a bunch of unrelated stuff in your original form - just to try to reduce it to the bare minimum - so if this version is ok/adequate, then feel free to add things back in.
Unfortunately, whilst I fully understand the desire to make the inner repeat conditional, in your specific usecase, I dont know of another workaround - other than to instead make all the questions insider the inner conditional (and remove the relevant condition on the inner repeat itself, as I have done).
@Xiphware Thank you very much for this. I have played around with what you sent, and whilst you get the empty box when it doesn’t apply, at least it seems as though the drop down occurs whenever it is required in this example form.
Needless to say, my “real” form is much more complicated than this trimmed down example one is , so I have used the same sort of coding in my real form. It mostly works. On the occasions where the dropdown doesn’t automatically appear, it usually appears immediately when I click on the plus button (to add additional quadrat sampling data). In other instances, it may take several attempts. In the following screen grab, it took 3 attempts. When this happens, the only solution is to delete those “empty” records - I have just tested this with a deployed form on my iPhone, and I could not submit the record until those blank records were deleted.
As weird behaviour is a known issue with nested repeats (at least since 2022, based on the links you provided, may I ask when this will be looked into in greater detail and correctly resolved?
Yup. I wanted to ‘distill’ it down to its barest form and remove any unnecessary (unrelated?) variables - eg the superfluous additional enclosing groups - to isolate what the root cause might be. So feel free to re-embellish it with whatever you like, right up to the point it breaks again (but at least then you’ll know what you did that made it worse)
It mostly works… As weird behaviour is a known issue with nested repeats…
Yes, there are a few known issues in Enketo with repeat groups [repeats are messy to deal with in XForms; nested repeats doubly so]. FWIW we (Kobo) inherited maintainership of Enketo less than a year ago, so these issues are on our radar but I cant make any estimate on when they will be resolved.
If you haven’t already, I’d be curious to know if you have also tried running your form under KoboCollect, and whether it behaves any better?
I have continued playing with this in my much more complicated real form. I seem to have encountered different weirdness with the repeat within repeat in my form, but I will see if I can resolve these on my own, and if not, work out how the data collectors can deal with the issues.
Regarding your final question, I think the error occurs primarily with Enketo. I have been using a different form on another project, which has a repeat within a repeat. This was what caused me to first post a question on this topic. Folks entering the data on an iPad (Enketo) kept running into problems where the 2nd repeat did not work (exactly like this one). They were sent a Lenovo Tablet set up with KoboCollect, and have never had a problem since. So it seems the two platforms do indeed behave differently, with Enketo disliking the repeat within repeat more than KoboCollect.
I had no idea that you folks only inherited Enketo recently - I was under the impression it was a long-standing integral part of the whole Kobo Toolbox “package”, managed by the same core team. (BTW - thank you to all of you!)
Repeats within repeats - aka nested repeats - is an area where Enketo is recognized to have issues. Collect still has a few issues with repeats too, but you are far less likely to hit them.
If your specific usecase requires it - ie you cant refactor your form to avoid nesting them - then I might advise using KoboCollect for data collection when possible. If this is not feasible, then I highly recommend testing your form(s) very thoroughly before deploying it out to the field (including such things as adding and deleting repeat iterations, at different nesting levels..). That way, perhaps you can devise some ‘best-practices’ for your particular form, about what should work and what your users might avoid doing that is prone to error.