Best Of

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!

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.

Great, that should work just fine. Now when you export these point samples, you can also include the header fields for each sample row in the export file. Then these shared XYZ values will repeat for each row, and any other header field you might want to include. To achieve this - on the general export dialog there's a "Include header fields with table data" option that will union the header fields with the sample rows. Otherwise the export template lets you set this up as well.

Thanks David, this is very helpful and clarifies the configuration and underlying logic very well.

In our case, the objective is to associate multiple samples with a single logical field point, with all samples sharing the same XYZ captured at the point/header level. Based on your explanation, disabling the “limit entry to single row” option in the sample table is exactly what we were looking for.

Thanks again for the detailed explanation and for sharing best-practice considerations.

Hi David. Tested the case. It seems I was trying to login with internet connection which leads to the online login page. I have turned off all the connection and logged in without any issues. Thank you very much for the detailed explanation. 🤩

Yes, you can configure MX Deposit to allow multiple samples for the same point/header. In fact, if you are currently limited to just one sample row in the sample table - then somebody has explicitly configured it that way. In the activity configuration, you can expand the sample table (or any table) and there is an option called "limit entry to single row". If this option is enabled, then you will only be allowed to enter a single row (or sample) in that table. If you disable this option, it will let you add multiple rows (or samples) in that table.

The trick with point data is the coordinates. The coordinates are captured in the header, which then enables all the coordinate validation and transformation options. So in your case, are you looking to capture different XYZ values for each sample in the same table? Or will the XYZ live in the header, and the sample table has just sample IDs? We have seen customers add their own XYZ columns in sample tables, which works fine - but you won't be able to transform those coordinates on export. You would just need to make sure that what you capture in the table is in the coordinate system that you are always working in.

Would be good to understand if these ideas/solutions work for you, or if there's anything you think would work better here. We have tossed around the idea of having a sort of special "coordinate" table that has built-in northing/easting/elevation/CRS columns that would also make use of the coordinate transformation features on export. That would let you capture different XYZ values for different samples in the same table, then the point header could just be some logical grouping of samples.

Thoughts?