This is great, @Elvi_Web, thanks so much for taking the time to share a worked example!
Essentially, your quota list is a pre-populated participant list but all you know about your participants initially is their age range and gender. When a data collector completes an assigned participant, they "check them off" by changing their status. That "participant" (or quota as you called it) is then filtered out of the selection list. This is a great approach!
It's a little different from what I had in mind. I was thinking of creating participant entities when a successful interview is submitted. The interview form would both do that entity creation and have the entity list attached to it. It would use existing entities to count how many participants of each age range have been interviewed so far to create a summary of which participant types are still needed.
The disadvantage of my strategy is that the form ends up needing a lot of logic. This could lead to performance issues if there are many participants and could easily contain subtle bugs.
I really like that your strategy is easy to validate: you can scroll through the 1000 quotas and verify that they look like what you expect. The only slight downside is that you have to generate that list up front.
Are there any problems that lead you to want to optimize? Is it difficult to generate the quota lists? I can share a sample form for what I have in mind if you think that would be helpful.
It should be the same! Currently both Collect and Enketo have to re-request the full list of entities from Central every time there's a change. It should take Central only a few seconds to generate entity updates but sometimes it could be a bit longer so if you refresh immediately after submitting, you might not get the new data.
We're actively working on making entities available offline in Collect. That would mean that the quota update would be instant after finalizing a form. As soon as you open another form that uses the quota list, it will see the update without having to be online.