Thanks for tying all the pieces together, @ahblake! Great to see how much enthusiasm there is for this functionality.
Yes, exactly. This means you have more fields in your submission that you don't really need but it makes the relationship between form fields and Entity properties easier to see in form design.
I would recommend using a relative expression. For example, if you have a calculate directly in the repeat (at the same level as the meta block as you said it) that needs to access the Entity system ID, the expression ../meta/entity/@id should work. That way you don't need to think about nesting outside the repeat, only inside. Could you please tell us how you're using the system ID? Is it to create links between Entities?
Here's an overview of the status:
pyxformas released in Central v2025.3+ can generate forms following the 2025.1.0 Entities spec as outlined in the top post, but only for a single declaration per form, either at the top level or in a first-level repeat (not in nested repeats)- Central v2025.3+ can use the new spec
- Collect v2025.4 is still in beta, it can use the new spec when opted into in settings. In the next beta, it will create Entities from repeats offline, still requiring opt-in.
- Enketo can't use the new spec because of this issue which we don't currently have plans to fix. Those who need web-based forms for Entities with repeats will be able to use Web Forms.
Here is a simple form to create multiple Entities in the trees list: [https://docs.google.com/spreadsheets/d/1bHnF-1W39P2uNrE3Od8BIh7DtF4ErB-sK4T4flPEJkw/edit?usp=sharing](Entities in repeats)
We initially thought we would start by releasing what we have now: limited pyxform support and Central support with opt-in support in Collect. However, as we've created more test forms and explored the problem space more, we would like to have a clearer path to having performant links between Entities before we release.
As @dast says, almost every context in which it's helpful to create or update Entities in a repeat also involves a parent Entity (and possibly grandparent!). Currently, form designers are entirely responsible for making sure they establish the links they need. Because the system has no knowledge of those links, looking up the children from the parent is not performant (as @dast and @ahblake have pointed out in other threads).
Changing the way those links are represented after they've been created would be a time-consuming operation for each data collector. So we're doing some design work now to see how we can do this thoughtfully.
One additional point that has kept us from releasing as things are is that as we write test forms, it "feels like" the links between Entities should be created implicitly based on the shape of the form and so it's easy to forget to define them.
We're working hard to get this right, thanks for all your input so far! For those of you who have tried the functionality, please consider sharing your test forms and the projected sizes of your biggest Entity Lists.
If you link Entities already or are planning to, it would also be helpful to learn about relationships you want to represent that are not simple parent-child ones. For example, if you want to represent links to multiple parents, that would be helpful to know. That would be something like having participants that you want to be able to access from households, schools, and districts lists. In that case, participants can be said to have three parents.
CC @laurespake from ODK Collect v2025.4 Beta: guidance hints shown by default, updated repeat dialog - #10 by laurespake; it would be great to know more about whether you need any linking between Entities and if so how you plan to represent it.