Carbon Credit Project: Short-term workaround needed: tracking the same farmer across several forms over years (baseline, consent, boundary, monitoring)

User Support
1

Hello everyone,

I work with carbon and agroforestry projects where the same farmer is visited many times over several years:

      • A baseline survey, - FPIC consent, -Boundary mapping of the parcel,
      • An implementation record, – then monitoring rounds.

Each visit is a different form, often filled by a different enumerator, and usually offline.

KoboToolbox handles each form well. The difficulty is the thread between them. Every submission is its own record, so “where is this farmer in the process, and what is still outstanding?” has to be answered outside Kobo.

What I am looking for

A short-term solution that works in KoboToolbox today. I am building a long-term solution in parallel (outlined at the end), but it is not ready for the field yet, so I need something that holds up in the meantime.

What I have tried or seen so far

  • A farmer ID typed or scanned into every form, then joining the exports afterwards. It works until an ID is mistyped or a farmer is registered twice.
  • pulldata() or select_one_from_file with a CSV of registered farmers. It works, but the CSV has to be regenerated and redeployed, and devices in the field carry an old copy.
  • Dynamic data attachments linking a registration form to follow-up forms. Closer, but devices need a connection to refresh, and it gives you data from the parent form, not a status per stage.
  • Validation status in the data table for review, with rejected records edited or resubmitted.

Questions for anyone doing longitudinal or case-based work

  1. How do you link visits to the same person or household? Which approach held up in the field?
  2. How do enumerators know, while offline, who is due for which form today?
  3. When a supervisor rejects a submission, how do you handle the correction without losing the original?
  4. How do you catch duplicate registrations?
  5. If you run part of this outside Kobo (a spreadsheet, scripts on the API, a BI tool), what is the lightest setup that worked for you?
  6. What still hurts most?

The long-term solution, briefly

For transparency, this is what we are building for carbon projects. It is still in development.

  • An offline-first web app that installs on Android phones and tablets, built around the farmer record instead of the form.
  • Each farmer is registered once, with a unique ID and a GPS location, and carries all five stages, each with its own status: not started, in progress, submitted, approved, or sent back.
  • Forms are templates in English with conditional logic and validation, and a later form can read answers from an earlier stage.
  • A supervisor reviews each submitted stage. A rejection comes back to the enumerator as rework and is saved as a new version, so the original is kept.
  • Exports to CSV, GeoJSON and KML.

I mention it only so the answers can focus on the gap between now and then. Short-term workarounds are exactly what I need, and I am happy to share what has and has not worked for us in return.

Thank you,
Stephen

2

@stephenoduor – This is a classic longitudinal case management challenge, but you can solve it completely within the KoboToolbox ecosystem today without running external API scripts, managing multi-form sprawl, or relying on manual CSV updates.

Here is an end-to-end native workaround using a Single Master Form self-linked via Dynamic Data Attachments (DDA) paired with a Supervisor Gatekeeping & Amendment Workflow.

1. Short-Term Workaround(can be all what you need :hugs:): Single Self-Referencing Master Form

A. Consolidate into One Master Form

Include all 5 stages (1: Baseline, 2: FPIC Consent, 3: Boundary Mapping, 4: Implementation, 5: Monitoring) in a single XLSForm. Use relevant skip logic (relevant = "${visit_stage} = 3") so enumerators only see questions corresponding to the active stage.

B. Self-Link the Form via Dynamic Data Attachments

  1. Deploy the form in KoboToolbox.
  2. In the project settings (SETTINGS > Connect Projects), connect the form back to itself as a dynamic data source.

C. Auto-Compute the Next Stage

Inside your XLSForm, pull all prior submissions for the chosen farmer_id using an XPath calculation on the dynamic attachment:

\text{previous\_visits} = \text{count}(\text{instance('self\_link')}/ \text{root}/\text{data}[\text{farmer\_id} = \text{current}()/../\text{farmer\_id}\ \text{and}\ \text{approval\_status} = \text{'approved'}])

Then compute the current visit stage:

\text{visit\_stage} = \text{previous\_visits} + 1

When an enumerator selects or scans a Farmer ID (via the barcode question type to eliminate typing errors), the form automatically identifies that Stage 1 and 2 are complete/approved and jumps directly to Stage 3.

2. Handling Rejections, Supervisor Approvals & Amendments

To keep the primary pipeline clean and prevent corrupting historical submissions when rework is needed:

A. Supervisor Approval Gatekeeping

Add an approval_status calculate/select field (approved, rejected, pending) to the master form.

  • Field Guardrail: Include a supervisor PIN code field at the end of the form. If an enumerator submits, it defaults to pending. On the Kobo Web Portal (or via a supervisor device), the supervisor reviews the submission and updates approval_status to approved or rejected.
  • Because the stage auto-increment formula checks for approval_status = 'approved', a rejected or pending submission will not advance the farmer to the next stage.

B. The Amendment Workflow (Preserving Audit Trails)

When a supervisor sets a submission to rejected (e.g., boundary map error in Stage 3):

  1. Child Amendment Section: Enable an “Amendment / Correction” section inside the master form that becomes active only if the farmer’s latest record in the dynamic attachment carries approval_status = 'rejected'.
  2. Relational Traceability: Store the original submission’s unique identifier (_uuid) in a hidden parent_instance_id field within the amendment submission.
  3. Overwriting State safely: Once the supervisor approves the resubmitted amendment, its approved flag counts toward the farmer’s stage progression without deleting or overwriting the original unedited baseline raw record.

3. Long-Term Architectural Recommendation: ODK Central + Entities

While the self-referencing DDA setup handles this natively in KoboToolbox today, if you are building an offline-first app specifically for long-term case management across years, evaluate ODK Central with Native Entities.

ODK’s Entity Management feature is purpose-built for longitudinal tracking—it natively updates state properties on a central “Farmer” entity record across multiple visits offline without needing custom web app development or server scripting.

Hope this gives you a clean, robust setup for the field!