Best practice for handling multiple “point-level” tables (Field Mapping, ESG, Prospectors) under the
Hi everyone,
In our project, the Field Mapping data is currently stored inside the main Header table, and we have a “child” table for Field Mapping Samples. Now we need to add two additional point-level tables: one for ESG and one for Prospectors.
We created the two new tables, but it looks like “Point” becomes unified across all tables — as if the system treats them as belonging to the same overarching Header structure. Because of this, all tables appear to be tied to the same point register.
My question is:
How do projects usually handle this scenario?
Is it recommended to separate Field Mapping from the Header, creating a dedicated Field Mapping table, so the structure becomes something like:
HEADER
FIELD MAPPING
PROSPECTORS
ESG
This would keep each point-based workflow independent, instead of sharing a single “Point” entity.
Any best practices or examples from other projects would be extremely helpful.
Thanks in advance!
Answers
-
Typically this is where you would configure separate activities for each logical dataset. So set up your "Field Mapping" activity as you need it, with header and sample table (allowing multiple rows), then you can set up separate "Prospecting" and "ESG" activities to those data requirements. An activity can even be just a header and you can capture everything in the header. Otherwise you can set up every activity for the specific data requirements of each. Then you can either import data into the respective activity, or if logging directly into the system - when you click "New Point" you just need to choose which activity you are creating a point for.
One consideration when planning out the activities is if you can re-use the same tables in different activities then it unlocks the ability to export data from different activities in the same export file. In the export template, these are the "common tables". You can re-use headers across activities, re-use lists across header fields and table columns - lots of ways to standardize. Otherwise, you can always configure an export template to pull the data together (if that's what you want) - or you can export each activity into separate files as well, again depends on how you want to use the data downstream.
In terms of assay results (if needed), you can even capture samples across different activities and import a single certificate that has samples spanning those activities. The system will find them, based on the sample IDs.
Lots of options, and its always good to think about how you want to pull the data out as that might influence how you configure things in the first place.
Let me know if you have any follow up questions on anything.
2 -
Thank you for the clear explanation — this really helped.
Following your guidance, we’ll restructure our workflow using separate activities for Field Mapping, Prospecting and ESG, each with its own headers/tables, which solves the issue we were facing with the unified “Point”.This approach aligns well with how we need to export and manage the datasets, so we’ll proceed accordingly.
Appreciate the support!
2
