Introduction
In ActivityInfo, the way you name your forms, subforms and fields determines how users interact with your database, from data entry to analysis and reporting.
Unstructured naming leads to confusion, duplication, and might lead to errors. Structured naming creates clarity, consistency, and a system that can grow without being difficult to manage. It also reduces the need for repeated clarification during data entry or analysis because well named forms and fields communicate their purpose directly.
Naming forms and subforms
Forms are the containers for your records. Every time a user wants to enter data, they must decide which form to use. If the naming is unclear, that decision becomes uncertain and can result in data being entered in the wrong form.
A form name should communicate its purpose without requiring the user to open it. It should provide enough context to distinguish it from other forms in the database.
Be explicit and not generic since users should identify the purpose of a form directly from its name.
To achieve this, use a structured naming approach that includes key context elements such as project, sector, region, activity or period.
Naming should also reflect how the form is used within the data flow. A form designer should consider whether the form supports a single step in a process or multiple workflows. For example, naming a form “Registration form” may be misleading if it is also used for updates or follow up activities. In such cases, a broader name like “Registry” is more appropriate.
In other situations, a form may simply represent a collection of a specific data entity. In these cases, naming the form using the plural of that entity is often clearer and more intuitive, such as “Partners” or “Locations”.
Subform naming
Subforms capture related records linked to a parent record.
Using plural names communicates that the subform represents a collection of related records.
Examples of subforms in the form Household Survey Phase 1 - 2026:
- Household Members
- Visit_s_
Naming fields
Field naming in ActivityInfo fulfills two simultaneous functions. First, Labels provide clear guidance to users during data entry. Second, Field Codes enable back-end calculations and data synchronization with third-party platforms. To maintain data integrity, ensure that labeling is consistent between digital forms and any corresponding physical questionnaires used in the field.
When naming fields:
Use clear, context-rich field labels - Short labels without context can become unclear when data entry is taking place. This is common with labels such as “Name” and “Date”. To avoid ambiguity, include enough detail in the label so that it can stand alone. Examples:
Registration Date
Date of Distribution
First Name
Last Name
Apply consistent naming patterns - When fields are named consistently, the relationship between them becomes clearer. Example pattern:
Beneficiary Name
Beneficiary DOB
Beneficiary Gender
Use field codes for technical consistency - Field codes operate behind the scenes but are essential for formulas and integration through the ActivityInfo API. They should follow a structured format that avoids compatibility issues across systems. Ensure that the field codes are concise and meaningful. Examples:
| Label | Field Code |
|---|---|
| Full Name | full_name |
| Registration Date | reg_date |
Field codes must start with a letter and contain only alphanumeric characters or _underscores. Note that spaces are not permitted.
Logical grouping with headers - Long forms can overwhelm the user, therefore using section headers can break up the data entry process logically. You can also include a description to give the users more information about a section. Example:
Section 1: Beneficiary Identification - Full Name, Beneficiary National ID, Beneficiary DOB, Beneficiary Gender, Beneficiary Phone number
Section 2: Interventions - Type of service, Date of service, Partner Name
Section 3: Follow Up and Status - Follow-up Date, Current status, Notes
Standardizing options in selection fields
Single and multiple selection fields options need to be standardized clearly to ensure that they are consistent across the database. Without clear standards, filtering, aggregation or reporting might be affected when you have multiple variations of the same option.
Example:
- Using different casing like “Health”, “HEALTH”, and “health” across forms will result in fragmented data, as systems treat these as distinct values during filtering and aggregation.
- Using synonyms or terminology variations also leads to fragmentation. Stick to a single standard, such as “Cash Transfer,” instead of mixing it with “Cash Assistance” or “Cash Support.”
Conclusion
Naming forms and fields in ActivityInfo is a foundational part of database design that shapes how data is collected, understood, and used over time. Clear and structured naming ensures that users can identify where to enter data, understand what each field represents, and interpret outputs without relying on additional guidance.
Across this guide, a few consistent principles stand out. Form names should communicate purpose and context. Field labels should be descriptive and self explanatory. Field codes should follow a structured format that supports formulas and integrations. Selection options should be standardized to prevent fragmentation of values. Section headers should organize information in a logical flow that reflects how data is collected in practice.
These practices work together to create a database where:
- Data entry follows a predictable structure
- Values remain consistent across forms and users
- Reports and exports retain their meaning without additional transformation
Applying these conventions early reduces inconsistencies and limits the need for data cleaning later. It also supports collaboration across teams, since everyone works with the same shared understanding of how data is structured.