Hello community,
Is it possible to push data from a form to several entity lists?
Thanks for sharing your experience.
Hi @dast,
Unfortunately, at this time we only support a form updating a single entity list (and a submission only creating/updating a single entity).
It's something we are thinking about, though, both having a form write to multiple entity lists and having a submission create multiple entities at once that are somehow nested, or related, or spread across entity lists but still related.
Would you be able to share a scenario you would like to use this for so we have more concrete use cases to think about?
1 Like
Hi @ktuite
I'm working on such a scenario.
I have a form Scheduler where a supervisor can create a schedule with the task for different workers. The supervisors selects the date, then select a worker from workers.csv and then select multiple tasks from task.csv.
Then the worker will use the Fieldwork form, with the worker and date the form will get the schedule and then the worker will select one of the scheduled tasks and do it.
Now I only have the schedule as entity, so I must upload workers.csv and tasks.csv to both the Schedule and Fieldwork forms. If I could have them as entities too, I could then have forms to add/modify workers and tasks info, and also wouldn't need to duplicate the csv to both forms.
If not as entity, is it on the roadmap to have csv not only for the form but for the whole project? For my usage, I could live without the option to have workers.csv and tasks.csv as entities, but it would be nicer if I could upload them once to the project and have both forms be able to use them.
Attached the forms and csv, this is something I'm evaluating, I'm not using it in real case yet, probably in a couple of weeks.
Scheduler.xlsx (88.6 KB)
FieldWork.xlsx (66.7 KB)
workers.csv (212 Bytes)
tasks.csv (2.9 KB)
Yes! That's something that we are working on now and hope to have released in the next month or so. You'll be able to create an entity list from the Central frontend rather than through a form, define some properties for that entity list, and then upload a CSV to populate it. That will allow you to have task and worker entity lists that are shared within your project. When you make edits to those lists either through form submissions or direct edits, they will be reflected across the forms that access them.
As you've described the situation, it doesn't feel like there's a lot of benefit to being able to add tasks or workers from the scheduling form. But in an ideal world, is that something you'd want to do? For example, you might want a supervisor to add a worker while building a schedule? If so, it's starting to feel like a data management application -- you'd basically like ODK to be a frontend that lets you modify tasks, workers and schedules in an open-ended way.
At the moment, we're designing entity features more for workflow support than for data management. That means we're primarily targeting the part of your overall workflow where data collectors have tasks and want to complete them and mark them as complete. That doesn't mean you can't create forms that support the data management part of your overall workflow but I do want to let you know that it's not our current primary focus.
If you really want a single form to update multiple entity types today, you can consider "flattening" your entity lists into one. Instead of having task, worker and schedule entity lists, you could have a single list and have a "type" property that identifies each entity as a task, worker, or schedule entry. This will make some of your in-form queries more complicated and it won't be appropriate for very large scenarios but it may be an appropriate technique if you just need something done now. I'd be interested in hearing whether you or @dast find this a useful idea or have follow-up questions.
Hi Helene,
In tasks.csv for example I have contact person, email, but in real application I could add location or other relevant information. Most of that information would be uploaded with the csv via central, but maybe in the field you could modify some information (minor edits or corrections), so if the location is missing it can be added with the form. Also, some of the users mostly use their phones so if something is needed and I can do it in ODK without it being too messy, I'll prefer to do that. Meaning that I agree with what you say that ODK would be used as data management application.
For my current use though, with having to upload the csvs to both forms, it works. Not being able to modify workers.csv and tasks.csv is not a big deal now, but if there is a new feature where they can be added as entities I will most probably start using them as such.
1 Like
Thanks for all this insight. This is helpfull.
In our case we have have quite complex forms with basically two main areas the collected informations are related to:
- Farmers and their families
- Agricultural fields
We created two entity lists for these two areas of questions (there are more, but I try to keep it simple).
We have different forms that pull data from these entity lists, basically one form about fields and one about farmers. In both forms data from both entity lists are used.
I am not even quite sure if this is a good way to go. But we thought it might be convenient if we could update both entities from both forms.
Best, Daniel
1 Like
Most of that information would be uploaded with the csv via central, but maybe in the field you could modify some information (minor edits or corrections)
In that case, I would recommend having special forms that are just for edits/corrections. In your scheduling form, you can say something like: “if you notice missing or complete information about a person or task, please edit it using the edit form.”
You can think of your form list as an action list. In this case you’d have something like:
- Build schedule
- Update worker
- Update task
That will allow you to update your three entity lists independently.
1 Like