In analysis, how can I connect an Entity registration form's submissions to follow-up form submissions?

1. What is the issue? Please be detailed.

The entities feature availableon the new version of ODK is promising. And we have started experimenting with its use.

We are using a Farmer Registration form submissions to create entities that will be used for follow up surveys.

Is there any way we can use the metadata of the Farmer Registration submissions like the instanceID or Key in the entities data so that we can relate follow up surveys to the Farmer Registration submissions?

There is an __id in the entities data called Entity ID but this is a hash only for the entities table.

Is there any suggestion on how wecan relate the entities data to the original submissions?

2. What steps can we take to reproduce this issue?

3. What have you tried to fix the issue?

4. Upload any forms or screenshots you can share publicly below.

I'm really sorry this never was answered, @prabha! Somebody asked a similar question in the latest Insiders call and I wanted to make sure to surface the information. Was it maybe @nmambre or @wroos? If not and you remember who it was, please tag them so they can see it.

In any form, you can use ${instanceID} to access the current submission's instance ID and use it in expressions. If you want to save it to an Entity property, you will need to first store its value in another calculate with ${instanceID} in the calculation.

If I understand correctly, you want to use Entities to connect several forms' submissions and you want to do your final analysis on the submissions, including the registration submission. This might be, for example, because the registration form includes an intake survey has many many questions which aren't inherent properties of the Entity but instead represent baseline data. If I've understood the need correctly, I think a better option will be to make sure your registration submission has an identifier that all subsequent submissions also have. Here are some options:

  • If you know anything at all about your farmers before the start of your project, maybe something like the coordinates of their residence, you can now load that information into an Entity List before the start of data collection (documentation) so that all of your forms can start by looking up an Entity and store the same ID to connect form submissions in analysis.
  • You could consider separating out the registration from the baseline/intake survey. You'd need to either immediately reload the baseline/intake survey form from the server after registration to see the farmer, wait for offline entities, or manually copy some identifier from the registration form to the survey form.
  • If there is a natural identifier like a phone number or a participant id, you could save that to the registration submission and every subsequent submission.
  • You could save the entity id to the registration form submission using a calculate with calculation /data/meta/entity/@id.

Thank you. This is what I have done. I have accessed the ${instanceID} and save it as SubmissionID. I use this to relate the new survey to the original entity.

Looking for more features on use of entities.




I'm so glad you figured it out and got it working!

I made it sound like using the instanceID from the original registration form wasn't a great idea but really, there's no reason not to. It ends up being very closely related to the third alternative option that I listed. The most intuitive key for you is probably the best one to use! :blush:

If you have any specific questions, don't hesitate to ask. You may be interested in some new documentation that we recently posted. We've also been doing office hour sessions with Insiders.

You had engaged with this issue when I posted and it and teh submissionID is the suggestion I got. New entities feature - #20 by prabha

I will try to understand the other ways you ahve suggested here.

1 Like

Thanks for that link, I had a memory of a similar discussion but I couldn't find it!

You may find them useful in other contexts. If you have something that works, there's absolutely no reason to change anything.