A cooperative in Ghana will not log into your compliance tool, and your trading desk will not replace an ERP it has run for twenty years because of a regulation. Grovetrace reads the data where it already is, in whatever shape it already arrives in. That is what the platform is built around.
A source is configured once with its credentials and a schedule, in cron or from a preset, with the next run shown in words. It then keeps pulling on its own, and over time it is the mapping you adjust while the integration stays as configured.
AS/400, SFTP drops and inbound webhooks are modelled as source types, but their connectors are not built yet. If your data arrives by one of them, raise it on the call: building a connector is scoped work against an existing pipeline, and it is the kind of request a design partner moves to the front of the queue.
You point every source column at one of three targets. The screen below is the real one: three FarmForce mappings configured against a single source.
SUPPLIERFarmers, cooperatives and exporters, whatever the source calls them.
LAND_PLOTPoints and polygons, with country, region and area.
BATCHLots and deliveries, including the purchase-order stream from an ERP.
Each of these has broken a cocoa programme somewhere. They are worth putting to any vendor you evaluate, including this one.
The field tool holds a farmer ID, the ERP a vendor code, the cooperative spreadsheet a name spelled three ways. A plot is unique per supplier by its external identifier, so the second arrival updates the first instead of creating a duplicate nobody notices until a statement names both.
Records land in a raw staging table keyed on their identity, and a re-run over unchanged or overlapping source data collapses to a single row, last occurrence wins. Without it, everything downstream would process the duplicates as real deliveries.
Mappings are versioned configuration. A source that renames a column, or starts sending hectares where it used to send acres, needs one change to the mapping and no migration.
The common case, and not a parsing problem. Incomplete origin data surfaces as a supplier whose plot coverage is short and an order that cannot yet be filed, months ahead of the submission window instead of inside it.
Four stages between the pull and the plot, each with its own job history, so a failure names the stage it happened in instead of arriving as “the sync broke”.
The connector pulls on its schedule, or on demand from a Run now button, and each run shows as running, completed or failed against the source it belongs to.
Rows land untouched in a raw table keyed on their own identity. Nothing has been interpreted at this point, and that is what makes the step safe to re-run.
Named transformations reshape the raw rows, including read-only SQL over a temporary view of them where a field mapping is not enough. Output columns are declared, so the next stage knows what it is being handed.
Rows become suppliers, plots and batches only at this stage. A promotion that fails names the record and the field, and the raw row stays in place so you can correct the mapping and run it again.
Raw records are staged before they become suppliers, plots or batches, and promotion is a separate step with its own job history. When a promotion fails because a required field is missing, the failure names the exact record and field that caused it.
It also works in the other direction: a plot in the application links back to the source row it came from, so “where did this hectare figure come from” has an answer instead of an argument.
Back to the platform overviewBring one export from the messiest source you have. Twenty minutes is enough to configure a mapping against it and see what resolves and what does not.
No data leaves the call unless you want it to. To send a file ahead of time, email hello@grovetrace.com and it is loaded into an organization only your team can see.