Building a database from a logical framework

Language: English

In this tutorial you start from a logical framework and finish with a database that has forms for collecting data, a few records in it, and a report. An AI assistant does the repetitive work of turning indicators into fields, and you review and correct what it produces.

You will use Claude, but the steps work with any assistant in this manual.

What you will learn:

  • how to have an assistant read a logical framework and propose a form design,
  • how to review that proposal before anything is created,
  • how to have the assistant create and then refine the forms, and
  • where an assistant is helpful and where you have to make the decisions yourself.

What you need

  • An ActivityInfo account, and permission to create a database.
  • An AI assistant connected to ActivityInfo. See Connecting Claude to ActivityInfo.
  • The authorisation must allow changes, because you will create forms and add records. If you granted read access only, connect again and allow changes.

Work in a database you create for this tutorial, not in a live database.

Step 1: Create an empty database

  1. On the Database List page, click “Add database”.
  2. Name it Logframe tutorial.
  3. Open “Database settings”, click “Security”, and select “Enable the MCP server for this database.”

Nothing else is needed. The assistant will create the folders and forms.

Step 2: Give the assistant the logical framework

Start a new chat with ActivityInfo switched on, and paste the following. This is a short logical framework for a water and sanitation project, which is enough to show the pattern.

Here is a logical framework for a project. Read it, but do not create anything yet.

Goal: Improved health for displaced households in Nyala district.

Outcome 1: Displaced households have reliable access to safe drinking water.
  Indicator 1.1: Number of households with access to at least 15 litres of safe water
                 per person per day. Target 2,400 households. Measured quarterly.
  Indicator 1.2: Percentage of water points with residual chlorine within the safe
                 range. Target 90%. Measured monthly at each water point.

Outcome 2: Households practise safe hygiene.
  Indicator 2.1: Number of people reached by hygiene promotion sessions,
                 disaggregated by sex and age group. Target 12,000 people.
  Indicator 2.2: Percentage of households with a handwashing station with soap.
                 Target 65%. Measured through a household survey twice a year.

Activities: rehabilitation of water points, distribution of hygiene kits,
            hygiene promotion sessions, household surveys.

Step 3: Ask for a design, not for forms

Ask the assistant to propose a design first. This is the most important habit in this tutorial: you review the plan while it is still cheap to change.

Propose a set of ActivityInfo forms to collect the data needed for these indicators.

For each form, tell me:
- what one record represents,
- the fields, with their type and whether they are required, and
- which indicator each form contributes to.

Explain which measurements need a form of their own and which belong together in one form.
Do not create anything yet.

The assistant proposes something close to this:

  • a Water points form, one record per water point, holding its name, location and type,
  • a Chlorine tests form, one record per test at a water point, referring to the Water points form,
  • a Households form, one record per household, with household size and location,
  • a Hygiene sessions form, one record per session, with participants disaggregated by sex and age group, and
  • a Household survey form, one record per household visit, with the handwashing station question.

Step 4: Review the proposal

Read the proposal against three questions. This is your judgement to apply, not the assistant's.

Does one record mean one thing? A form that mixes water points and tests on those water points will fight you later. Ask the assistant to separate them if it has combined them.

Are the repeated measurements separate from the thing measured? Chlorine is tested monthly at each water point, so tests belong in their own form that refers to Water points, or in a subform of it. Ask which it proposes and why.

Is anything a free text field that should be a selection? Free text cannot be aggregated. Push back:

Which of the fields you propose are free text? For each one, tell me whether it could be a
single-select or a reference field instead, and what the options would be.

Then ask for the one correction that matters most in practice:

Indicator 1.1 counts households with access to at least 15 litres per person per day.
Which form and which fields will that number be calculated from? Show me how.

If the assistant cannot answer that, the design does not yet support the indicator, and the fix is a design change rather than a bigger prompt.

Step 5: Create the forms

When the proposal holds up, ask for it to be created:

Create these forms in the Logframe tutorial database.

Put the water forms in a folder called Water, and the hygiene forms in a folder called Hygiene.
Give every field a code. Make fields required unless there is a good reason not to.
Use single-select or reference fields rather than free text where you can.
When you are finished, list what you created.

Now open the database in ActivityInfo and look at what was made. Check the field types, the required flags and the reference fields. This is a first draft, and treating it as one is the point.

Step 6: Refine a form

Two changes you will almost always need. Ask for them one at a time, and check the result after each.

Add a field that the framework implies but does not state:

Add a field to the Water points form recording the date the water point was rehabilitated.

Change a field in place:

In the Households form, rename the "Size" field to "Household size", and add a description
explaining that it counts the people who normally sleep in the household.

Changing a field this way keeps the field and any data already entered in it. Deleting a field is the operation to be careful with, because it also deletes the data entered in it. If you ask the assistant to remove something, have it tell you what will be lost first:

Which fields would be deleted if you removed the fields you just added, and would any data be lost?

Step 7: Enter a few records

You need data before a report means anything.

Add three water points to the Water points form, with plausible names and locations for
Nyala district. Then add two chlorine tests for each water point, in the last two months.

Open the forms and check the records. Look particularly at whether the chlorine tests point at the right water points, because a reference field filled in from a name is where an assistant most often makes a mistake.

Step 8: Build a report

Create a report called "Water monitoring" in this database, with two analyses:
- the number of chlorine tests per water point per month, and
- the percentage of tests within the safe chlorine range, by month.

The assistant returns a link to the report. Open it and compare it against the records you added. With three water points and six tests you can check the numbers by hand, which is exactly why this step comes while the database is still small.

What you learned

You produced a working set of forms from a logical framework in one sitting, and the assistant did the typing. Three things carried the result:

  • You asked for a design before you asked for forms. Reviewing a proposal costs a minute. Reworking twelve forms that were created from a misunderstanding costs an afternoon.
  • You checked the numbers while they were small enough to check. An assistant reports a wrong figure with the same confidence as a right one.
  • You made the design decisions. What one record represents, which measurements are separate, and which fields must be a selection are decisions with consequences years later. An assistant proposes; you decide.

Where to go next

Next item
Explanation