00:00:05 Introduction and session overview

Thanks so much, Faye. Great. Glad to have you all here. I recognize a lot of names in the chat. Welcome. Today, we are going to do a roundup of many of the features that we've released over the last year, even maybe fourteen to eighteen months. As I work with users, I sometimes see that if you designed your database a year ago or two years ago, you might not have gotten around to using some of these new features that we've released.

So we wanted to do a tune-up session to introduce you to those new features that you can use in database design. We will go through each of the items I have on the screen. I will be mostly clicking around in the app today, and I will stop periodically for questions so that you have a chance to ask about other cases or details.

00:01:20 Record labels

We are going to begin with a small feature, but it is useful throughout the application, and that is record labels. In many places throughout the application, the application needs to refer to records. For example, if I have a form of individuals and I select a bunch, we need a way to label those records. It is the same if I delete records or in the print form. There is a whole bunch of places where we need to name a record.

What we have done up to now is smash together all the key fields from a form. But depending on your form, you may have a lot of key fields or they may not be the most useful ways to name a record. By going into form settings now, the title section is expandable. You can choose a field to be a record label. It could be a single field, like the last name, or you can create a calculated field.

For example, I could create a dedicated field for the label using a formula. I might want the last name and the first initial. Once I define that formula and choose it as the record label, that becomes the way ActivityInfo will name this record. This shows up in the selection pane, when exporting attachments to label folders, and it is used a lot in the mobile app to label the record page.

00:05:27 Custom lookups for reference fields

Let's look at another new feature that is useful for naming things, which is customizing the lookup for a reference field. To give you an idea of what I mean, let's start with a simple form that references my individuals form. Let's say we have a form for tracking educational grants. I am going to add a reference field to my registry of individuals. By default, ActivityInfo will use all of the key fields that you have defined as a kind of cascading select. First, I have to choose the first name, then the last name, and then the date of birth. It is not a super user-friendly way of presenting this selection list, but I don't want to change my key fields because I want to ensure records are unique.

With custom lookups, you don't have to choose between changing your key fields and having a user-friendly dropdown. We can go back into form design, go to the recipient field, and select the new option "Use custom lookup." This allows me to choose one or more fields to use for the selection. By default, it shows the record label, but maybe I want more detail. I can create a new formula using the CONCAT function to combine the full last name, full first name, and the date of birth in parentheses.

Now when I add a record, I can search by birth date, last name, or first name. It makes it easy to find the individual you are looking for in the list, and I only have one dropdown instead of three. You can still use cascading fields if you want. For example, if I want to reference a location, I can add multiple lookup fields to create that cascading effect, choosing the province first and then the district. This gives you more control over how the lookup is presented.

00:12:20 Multiple reference fields

The next thing that we added is multiple reference fields. You have always been able to use multiple selects if you have predefined choices, like a list of expenses covered. However, before we released multiple reference fields, it wasn't really possible to combine this with reference fields. If I wanted multiple locations or multiple grantees, I couldn't easily do that without making a dropdown list of thousands of participants. Multiple reference fields allow you to allow multiple choices from a single reference form.

I can replace the recipient field with a new multiple reference field. This allows me to go to the registry and choose multiple individuals as recipients. One limitation is that right now, multiple reference fields always use the record label to display the selection. We don't yet have the custom lookup option for multiple reference fields. So, if you are going to use multiple reference, it is important that you define that record label for the form you are referencing so it displays useful information.

You can basically think of these multiple references as subforms because they function in the same way. You have a parent form and then multiple child records. You can add calculated fields, such as a count of the recipients. You can also use aggregation functions like TEXTJOIN to group all the recipients together in a single cell. This works with subforms, reverse references, and multiple references.

00:25:00 Translation fields

Let's look at translation fields. If you have an ActivityInfo database with your forms, you might be working in a context with multiple languages. You can translate your database through the database settings and translations. You can add translations for the form structure, field names, and options. However, when you reference data from another form, like a list of activities or partners, that data is not part of your form definition and historically remained in the original language.

With the translated fields feature, we now have a solution. If I go to my form settings for those reference forms, I can add another field for the translation. I will mark this new field as a "Translation" of the original name field. This allows me to import or type in the translations of all reference data. For example, I can have "World Food Programme" in English and "Programme Alimentaire Mondial" in the French translation field.

Now, if I switch my interface to French and go to my activity report, it will use the translated fields to populate the dropdown. This means you can provide a full translation for your speakers of other languages. This also works nicely together with record labels and custom lookups; if you set a record label, the system will use the translation of that record label to label the record.

00:37:40 Default values

The next feature is default values. These allow you to prefill a field in data entry so that the user doesn't have to fill it in, but they can change it if they want to. For example, if I add a registration date field, maybe most of the time the date of registration is the same as the date you are filling out the form. I can use a formula like TODAY() to set the default value. The user can still edit it if they are entering data collected last week, but they don't have to type it out from the start.

This can also be useful for surveys if you want to capture when the data was collected, not just when it was synced. You can add a text field for "Survey Time" and use the NOW() function. You can even set this as read-only so the enumerator cannot change it. This captures the timestamp when the form was first opened.

You can use default values on most field types. For single select fields, you can choose one of the options as a default. This is really useful for review workflows. You could add a "Review Status" field marked as "Reviewer Only" permission, with options like Pending, Approved, or Rejected. If you set the default to "Pending," any new record added by a standard user will automatically be set to Pending until a reviewer changes it. Note that default values are only applied when you first add a record, not when editing.

00:45:00 Custom views

We have added a "Views" button to the form view. This allows you to change how the records in your form are presented. The default is a table with all fields, but you can change this to a Map view or a Reader view. The Reader view provides a handy way of consuming qualitative data.

For database design, the Views feature allows you to save views and share them with others. If you are building a system for your colleagues, the default view with all columns might not be the most relevant. You can select specific columns, change column widths, and even add calculated fields specifically for that view. For example, I can create a "Full Name" column using a formula just for the view without adding it to the database structure.

Once designed, you can save the view and set it to "Shared." You can also set it as the default view. This means when your partners log in, they see exactly the view you have designed for them. You can create multiple shared views, such as a view filtered for "New Farmers" only. This is a great way to improve the user experience. Additionally, custom views can help with performance. If you have a form with thousands of records and many reference fields, creating a view with only the key columns will help the table load faster.

00:54:30 Validation rules for subforms

The last feature I want to cover is validation rules for subforms. This has been out for some time, but it is quite useful. Let's look at a simple case. If you have a household form with a subform for members, you might want to limit the number of members you can enroll. You can add a validation rule that counts the members and ensures the count is less than or equal to a specific number. If a user tries to add more members than allowed, they will get an error and cannot save the record until it is corrected.

A more complex scenario involves class registration where classes have a maximum capacity. You can apply validation logic using reverse references. For example, if I have a Class form and an Individuals form, I can link them. In the Class form, I can add a calculated field to check the status. I can write a formula that checks if the count of students (via reverse reference) is greater than the class capacity. If it is, the status is "Overcapacity"; otherwise, it is "Acceptable."

Then, on the Individuals form where I select the class, I can set a validation rule or filter on the reference field so that you can only choose classes where the status is "Acceptable." This effectively prevents users from enrolling individuals into classes that are already full.

01:04:20 Q&A and Conclusion

We are over time, but I will stay online for additional questions. Regarding the question about report generation, that is not the topic of today's training, but we will share links to trainings we have done on reports.

Regarding the feedback on the complexity of the application: Our philosophy is to keep the simple things simple, but make the complex things possible. You don't need to use any of these advanced features to set up a basic data collection system. However, if you are in a context with complex indicators or validation requirements, it should be possible to model that in ActivityInfo. We try to strike a balance where the form designer remains simple, but you have the tools to manage complexity if you need them.

We also have an API importer feature and improved bulk update capabilities in the new table view, which supports filling down values and making changes across multiple cells. For managing users across multiple databases, you can export a user list from the billing account, though we note the request for a bulk user cleaning tool.

Thank you all for joining and for the feedback. I hope you have gotten some ideas on how to update your existing databases with these new features.