Skip to content

Core Concepts

3D collects data and builds a database from it. Each approved answer set becomes a record that later forms can link to.

Example

In an agriculture project, field teams report on farms and farmers that are already in the database. They can also add new farms and farmers, and then report on those.

The core concepts follow a natural order. Forms define how you collect data. Data tables store and manage it. Views combine it. Interfaces and Dashboards show it. Around all of them, a project holds everything for one piece of work, and roles decide what each user can do in it. This page takes them in that order, and ends with the project.

Forms

Forms are how data gets into 3D. You build a form by adding questions. Each question has a type, and the right type keeps the data consistent.

Every form is linked to a data table, and each question is a column in that table. When someone completes a form, their answers arrive as a submission. When the submission is approved, the answers become a new row in the table, a record. A form can approve its submissions on its own, or hold them for a person to review.

Users complete forms in the browser or in the 3D app, in the office or in the field.

Example

A form for registering new beneficiaries asks for a name, a phone number, a location and a date. Each approved submission is one beneficiary record in the table.

A form can also work with data that exists already. A Relation question picks a record from another table, and an Inheritance Filter narrows the options of one question by the answer to the one before it.

See Forms for full documentation.

Data

Every approved submission is a record in a data table. A data table is like a spreadsheet. The columns are the fields, and each row is a record.

You can browse, search, filter and edit records, import them from a spreadsheet, export them to Excel or CSV, and see the history of any record.

Tables also connect your data. A Relation field in one table points to a record in another. A Visits table links each visit to one Beneficiary record. The result is a set of linked tables, not a flat list of survey answers.

Example

A project has three linked tables: Farmers, Farms and Harvests. Each Farm links to a Farmer, and each Harvest to a Farm. You can trace any harvest back to its farm and its farmer.

See Data for full documentation.

Views

A View joins related tables into one combined table. Each row shows one record with its related records, one row per combination.

Views have three uses.

  • Cascading Select questions. One question with several levels, such as Country, State and Town, built on a View that joins those tables. This is the most common use. See Cascading Select.
  • Inheritance Filters on forms. Separate questions, where a chosen Country limits the States, and a chosen State limits the Towns. See Inheritance Filters.
  • Reading related data together. A View shows each record with its related records on one row. An Interface does the same job as a page built around one record, and either works. A large View can have a daily Snapshot, so it opens quickly.

A View respects data scoping like any table. A scoped user sees only their rows in it. See Groups and Data Scoping.

Example

A Schools, Classes and Students View joins those three tables, so every row shows a student with their class and school. A form for a new visit can then offer only the students of the chosen class.

See Views for full documentation.

Interfaces

An Interface is a page built around one record. Pick a farmer, and the page shows the farmer's details, the cooperative they belong to, and lists of their visits, yield reports and training sessions. It is the quickest way to see everything about one thing, on the web and in the 3D app.

Example

A field officer opens the Farmer profile Interface before a visit, sees the last three visits and the farmer's crops, and then completes the visit form with that in mind.

See Interfaces for full documentation.

Dashboards

Dashboards show your data as charts, tables and counts, so your team and your stakeholders see the state of the project.

3D dashboards are built in Metabase, an analytics tool that is part of 3D. Each project's Dashboards page shows its Metabase dashboards as tabs. A project can also show a Power BI report built from the 3D data warehouse.

A dashboard can be shared with a link that needs no login, or sent by email on a schedule, so reports reach the right people without them opening 3D.

Example

A project dashboard shows the beneficiaries registered this month, a map of their locations, a breakdown by gender, and submissions per week. It updates as new submissions are approved.

See Dashboards for full documentation.

Projects, users and roles

Everything above lives in a project. A project belongs to an Organisation and holds its own tables, forms, views, interfaces and dashboards.

Each user has a role in a project. A role is a set of permissions, such as Data Collector or Data Manager, and it decides what the user can see and do. Groups go one step further and decide which rows a user sees, so a district team sees only its own district.

See Projects & Users for full documentation.