Currently, if a form creates Entities, form designers are responsible for making sure they have enough information to link between a submission and the resulting Entity if they need it. For example, it's common for an intake form to capture some identifying information that gets saved to an Entity and other baseline data which needs to be analyzed from the submission.
Often what makes the most sense to do is to save the Entity ID to the creating submission. That way both creating and updating submissions can be linked back to the Entity they reference using the system ID. This requires an XPath expression like /data/meta/entity/@id. That's not very intuitive so users end up creating their own uuids or using natural IDs. Using natural IDs can be a great solution as long as those are guaranteed to be unique somehow which is much harder to do than it seems.
To help address this case for forms that create a single top-level Entity, we can add a system column to the OData and CSV data exports. I can think of two names for that column:
__entity- The name of the target Entity list with a
__ prefix. For example, __participant.
Once we allow multiple top-level Entities, we will likely flatten those out to __entity1, __entity2, etc.
This will help with analysis. We are also working on some additions that will help in follow-up forms (i.e. that will make changes to the Entity CSV served to clients).
Currently, if a form creates Entities, form designers are responsible for making sure they have enough information to link between a submission and the resulting Entity if they need it. For example, it's common for an intake form to capture some identifying information that gets saved to an Entity and other baseline data which needs to be analyzed from the submission.
Often what makes the most sense to do is to save the Entity ID to the creating submission. That way both creating and updating submissions can be linked back to the Entity they reference using the system ID. This requires an XPath expression like
/data/meta/entity/@id. That's not very intuitive so users end up creating their own uuids or using natural IDs. Using natural IDs can be a great solution as long as those are guaranteed to be unique somehow which is much harder to do than it seems.To help address this case for forms that create a single top-level Entity, we can add a system column to the OData and CSV data exports. I can think of two names for that column:
__entity__prefix. For example,__participant.Once we allow multiple top-level Entities, we will likely flatten those out to
__entity1,__entity2, etc.This will help with analysis. We are also working on some additions that will help in follow-up forms (i.e. that will make changes to the Entity CSV served to clients).