Introduction
ActivityInfo first and foremost is a relational database. ActivityInfo is built on the relational model, which allows you to establish relationships between multiple data sets.
Although ActivityInfo has been designed specifically for M&E, case management, and other use cases required by the social sector, the platform doesn’t make any assumptions about what kind of data your organization might be managing.
Below is one example of the different kinds of data that you might be working with in your own organization:
if you're an NGO that implements a number of different development projects, you might have a list of those projects, and within those projects you might have information about the activities that are being implemented, and then further you might have the details about each of the implementations for those activities. Between these data sets, there are naturally-ocurring relationships.
Data Hierachy
ActivityInfo uses an intuitive hierarchy to organize data that includes databases, folders, forms, records, and fields:
Records
A the heart of the hierarchy is the record, which represents a single, discrete entity with its own attributes and it's something that can be separated from other data entities. Record most commonly represent individuals, objects, events and so on.
Fields
Each record that you have in your system can be described by a number of fields. Fields are the specific attributes that describe something about that record.
For example, if you have a record that represents individuals, that record might have fields that represent the individual's name, their date of birth, their contact information and so on.
Forms
If you have multiple records that belong to the same category, that have the same set of fields that describe them, you might collect those records within a form. You might have a form for individuals, another form for activities, and another form for projects. Forms in ActivityInfo are the main way by which you bring data into your database.
Folders
If you have many forms, you may want to organize them into different folders. So just as you would group together files related to the same project or the same sector in your own computer, folders in ActivityInfo work in very much the same way. It helps your users find the forms they need when there are many forms.
Database
Finally, at the top of this hierarchy, you have your database. The database is where all of your forms and folders are stored. This is the overall container for where all of the data sits. This is essentially the workspace where you collaborate with your coworkers and other users of the database on the same set of data.
Let's take a look at how we would apply this hierarchy to one of the data sets from the beginning of the article. If you visualize a list of projects as table, then the projects table would be organized as an ActivityInfo form. The columns, “Project Code” and “Project name” describe different attributes of a project, would be represented as fields in ActivityInfo. And finally, the rows in the table would be added as records to the form.
This hierarchy is reflected in ActivityInfo’s user interface. When you navigate to a form, you’ll find each of these elements in the hierarchy represented:
Field Types
ActivityInfo supports a wide range of field types that allow you to describe the records in your system, ranging from structured to unstructured
Key Fields
Key Fields are an important feature in ActivityInfo. Key fields allow you to uniquely identify records to make sure that users aren't entering duplicate information within the same form. This is also very important in that it allows you to make connections between different forms thanks to the ability to identify specific records in a form.
Relationships
ActivityInfo provides a two field types that allow you to relate forms to each other.
Relationships
The first are reference fields, which allow you to create a one-to-many relationship between two forms.
This is quite useful when you have a list of information that needs to be referred to by many forms in your database. Examples include lists of geographic areas, lists of facilities and so on. Reference fields give you the ability to connect different forms to this one standard list that you would only need to maintain once.
The second feature is subform fields. Subform fields are similar to reference fields, but enforce a parent-child relationship between two forms. This is useful when you need to capture recurring or repetitive information.
Example use cases for subforms include collecting indicator results on a monthly basis, or collecting data about household members during a household survey.
Roles
The database is your overall workplace where you would invite other users into your database. When you invite a user into your database, you assign them a specific role. Roles in ActivityInfo are a collection of specific permissions, which is to say the specific actions that a user can take within that database. So these can represent things like adding or editing, designing forms, managing other users, or managing reports.