Hello! Long post ahead but your support would be truly appreciated. Thank you.
Context: We’re a field program where community-based staff (“field workers”) visit the 2-3 end users repeatedly over several weeks to a month to deliver a series of support sessions. We’re migrating from a case-management platform (which auto-tracked each client and routed field workers to the correct next form) to KoboToolbox, which has no native “case” object.
Current design: A parent “Registration” form enrolls each client once and generates a hidden unique ID. Separate activity forms are linked to Registration via Dynamic Data Attachments (DDA), with the ID linking the registration and session forms. Field workers each manage a caseload of roughly 2–3 new end users per month, with new end users every month - and there is currently no physical ID card or token system in place.
Questions:
- Is there a way for the field worker to identify an end user in an activity form without the field worker typing or remembering the unique ID? Since this is in a low-tech field setting where a barcode/QR card system isn’t currently feasible, what have other users done for this?
- We tried using a combination approach with DDA and an external CSV file to power a searchable dropdown of names. However, the CSV file meant that there was a lot of manual work to add the new registered end user names to the external CSV, reupload it to every session form, and redeploy. It also seemed unfeasible for the field - for example, if a field worker filled a session form directly after the registration form, the name would not pop up in the searchable dropdown. Is there another way around field workers remembering IDs, and being able to put in a name while the form also being linked automatically to the ID?
- When a new client is registered in the parent project, what is the realistic lag before that record is usable in a linked child project via DDA — both (a) when the field worker has intermittent internet, and (b) when they are fully offline for the visit? What steps does the app-side user need to take to force a sync?
- Is there a practical ceiling on how many individual end user records a project can hold on the free/nonprofit plan before performance (especially DDA lookup speed) degrades, separate from the monthly submission/storage quota?
- If we encrypt the Registration form (since it holds identifying information) using KoboToolbox’s form encryption feature, does this break Dynamic Data Attachments to that form? Can a child project still pull data from an encrypted parent project?
Thank you so much! Any help would be really appreciated!
Hi @mehakmalho Welcome to the forum.
I’ll try to address your questions one by one:
- For DDA to work, you need to ensure that your form structure follows the required setup for case management (parent–child relationship, consistent IDs, etc.).
- Please take a look at this approach suggested by @osmanburcu Adding option to Select one from a text box
- For that workflow to function, you’ll need an active internet connection. Refresh times can be delayed by up to ~15 minutes depending on caching.
- I’ve tested external CSVs with large datasets (around 50K records) and they worked well. While there’s no official documented limit, performance will degrade once your list grows into the millions.
- KoboCollect or WebForms (Enketo) cannot decrypt encrypted form DDA. If your project uses encryption, attachments remain inaccessible outside the server.
Hi @mehakmalho,
As @jorcabrera mentioned this is possible, please see the topic he shared and let me know if you have any question or need support regarding the topic
Hi! Thanks so much for sharing this. However, I still have a couple questions.
I understand that if an end user name is not present, they can add it through the ‘Other’ option and it will automatically be updated in the Github CSV - based on the document you shared with me (thank you for such a thorough one!). However, since there is a parent master registration form as well, this should ideally be the most updated point that is linked to the CSV, and the CSV should autoupdate everytime there’s a new entry in the master registration form. With this context, I have a couple more questions that you support would be helpful for! Apologies if these may seem repetitive, I’m still relatively new to Kobo and trying to figure this out!
- How can the external CSV be autoupdated? Is there a way that if a field worker adds End User 4 to the registration form, it automatically updates to the external CSV?
The above function would help immensely, because then the back end labor would reduce significantly. Do we use Power Automate for this as well? If yes, how?
- We realised that we don’t want Field worker A to see the end users that are being supported by Field worker B, since the end user names are sensitive among the field workers as well. Therefore, I’ve included a choice filter for registered_by, to sort end user names in the searchable CSV powered dropdown based on the username of the field worker.
Is there any other approach to fulfill the same purpose?
Please let me know your thoughts! Thank you!
Hello, thanks so much for the super thorough documentation. I had some questions and have replied to the previous comment for the same! Please let me know your thoughts.
hi @mehakmalho,
What i shared was just a random example while i test the method. I believe you would like to feed child from the parent form directly without any back en labour. If this is the case, you can apply the same method i shared with you, Parent form will collect the main data and will send it to Power Automate flow, flow will proccess it (you can do anything you do in Power automate similar to your manual work) and update the CSV file, after that you will feed the child from with this CSV file.
1- When you submit a new form, a copy of the form with selected questions will send to Power automate server, this will trigger the flow aumatically so no manual work after turn on the flow.
2- You still can use the same logic, your registered_by question can send to power automate, Power Automate register the data and add the registered user’s name to relevent column. No differance from what you are doing.
If field workers only manage a small caseload, I’d focus less on remembering IDs and more on making the lookup process as frictionless as possible. In many case-management systems, the challenge isn’t generating unique IDs, it’s helping users find the correct record quickly and consistently.
Since DDA is designed to eliminate some of the maintenance burden of external CSV files, I’d explore whether a searchable list based on participant names or other recognizable attributes can be pulled dynamically from the parent project instead of maintaining separate CSV updates. That reduces manual work and lowers the risk of mismatches. The biggest concern in offline environments is usually synchronization timing, so clear sync procedures for field staff may be just as important as the form design itself. DDA was created specifically to avoid many of the CSV maintenance headaches discussed here.
