Collect: Multiple projects support

1. What is the general goal of the feature?

A lot of users have to switch between various servers during project (sandbox <> dev <> deploy) and also between projects (study 1 <> study 2 <> study 3)


A useful and small change to ODK Collect homepage would be to show the current server (and or username) to which the app is connected.


An extended feature would be to be able to hotswitch between two servers without having to retype/rescan the login info each time. i.e. a settings option to use server 1 or server 2 and where maybe the home screen colour could be changed depending on the server in use

2. What are some example use cases for this feature?

Basic feature

  • I always know which server I am connected to, which makes my life better and reduces my stress.

Extended feature

  • Scenario 1 : Dev/Deploy

    • I enter URL/User/Password for two servers (1 = dev/ 2 = deploy)
    • In the settings I change the colour of the dev server to "red" and leave deploy server as "Default/White"
    • I flick a switch on settings and move to dev. Collect connects to the dev server and changes red so I know I'm in dev. Shows URL and username of dev server at top of home screen
    • I test my scripts and move back to deploy server, Collect goes white. . Shows URL and username of dev server at top of home screen
  • Scenario 2 : Project 1/Project 2

    • I enter URL/User/Password for two servers (1 = project A/ 2 = project B)
    • In the settings I change the colour of the project A server to "orange" and project B server as "green"
    • I flick a switch on settings and move to project A. Collect connects to the server and changes orange so I know I'm in right project. Shows URL and username of server at top of home screen
    • I flick a switch on settings and move to project B. Collect connects to the server and changes green so I know I'm in right project. Shows URL and username of server at top of home screen

3. What can you contribute to making this feature a reality?

Testing in field.

We propose introducing a profile concept that combines all form files, general settings and administrator settings. Profiles would be identified by a name, color and unicode character (including emoji). The profile indicator replaces the overflow menu on the Collect landing screen:

Screen Shot 2021-01-13 at 10.40.14 AM

Tapping on this profile icon reveals a dialog that is anchored to the top of the screen and provides options to modify settings for the current profile, switch profiles or add a new profile:

The preferred way to add a profile is by scanning a QR code with the additional option to manually enter server details:

The configuration QR code may contain a profile name, color and character. If no name is specified, it defaults to the server domain. If no color is specified, one is computed from the profile name (this ensures the default color is consistent across devices). If no character is specified, the first character of the name is used. On upgrade, the currently-configured server is used to set those defaults. is a special case and gets named “Demo”.

Once a profile has been created, all of its settings may be changed including profile name and server. An admin password can be used to restrict who can make those changes. Profile options for the current profile are accessible from Admin Settings > Profile. The current profile can be modified by scanning a QR code from Admin Settings > Profile > Configure via QR Code.

Profiles are deleted from the profile section in Admin Settings. If the current profile is the only profile, deletion is not available. A profile can only be deleted if it has no unsent submissions.


This is fantastic!

Would ODK 1x1 widgets still work?
E.g. widgets are laid out in a logical arrangement for profile A. User selects profile B, then taps widget for form A1.

I believe this refers to app shortcuts. We're not sure what the support for this or for launching Collect activities directly would look like. We would offer some support but it may need to initially be partial. For example, those might only work if the profile they refer to is currently active which would maintain the current level of functionality but not extend it to multi-profile contexts.

So does this mean we can have multiple profiles with different forms assigned to it?

Hi @LN,
this feature would be very helpful for users who participate to different studies from different partners with their own Central server.

Yes, exactly that is the goal.

1 Like

This is a great idea and v. useful when sharing the same device between different studies or when considering separate phases of the same study (e.g., pilot vs. deployment)

As ODK Central user roles and encryption are currently managed at the project level, I may also use profiles as a "trick" to manage different encryption / web user access needs within the same study.
For instance, a first profile would be used to collect encrypted personally identifiable information and a second profile to collect (de-identified) research data with a manually entered link to the previous submission.


4 posts were split to a new topic: Questions about Collect first launch experience and updates

In the wireframe, the 'Admin Settings / App Configuration' section is gone. From that section: the 'Save legacy .settings file to disk' is noted as being removed in a future version (presumably this would be that future version), and the 'Configure via QR code' is now part of the adding a profile process, but will there still be a way to 'Reset application...'? You note that "If the current profile is the only profile, deletion is not available." How will a user be able to clear all settings? Also, what does 'Reset profile' do?

1 Like

Wow, great ideas! I really appreciate the attention to detail with things like the color being computed from the name to ensure cross-device consistency!

Generally I love the direction! I have one key concern:

I'd like to see some mockups of what this would look like the first time you open the app (the zero case). You've described the one and many cases nicely but I'm not sure what happens when there are no profiles. What is the icon going to be? How will users know what it means if they weren't the ones to choose it? If it's D for Demo, how do they know what it's for?

I appreciate the desire to keep the UI clean and re-purpose the menu icon space with the profile icon, but now the affordance of the well-known menu icon is gone. I think it might be worth exploring having the profile icon, name, and URL shown above the 'iconic buttons' on the home screen. It would look nice, and it would make a lot of sense. "Turtle nesting: Fill blank form, Edit saved form ... ".

The menu could stay as it is with the options being 'General Settings, Admin Settings, Profile Settings, [divider], Change Profile, Add Profile'.

This also has the added benefit of getting rid of these buttons:


Which seem kind of awkward to me.


1 Like

I love the direction this is headed.

I agree with @tomsmyth that the two settings buttons seems strange at first, but we could do some user testing between the two alternatives. For most new users the presence of "General settings" and "Admin settings" is confusing, and we would do well to find a better solution rather than just moving the buttons (i.e. finding a solution to having a single 'Settings' button for editing the profile).

I've been thinking about this a fair bit and I'm wondering if we should not revisit whether this is a way to manage and display multiple Projects (each containing one or more forms) rather than calling them Profiles. This would match @chrissyhroberts original idea and also what users are used to seeing in Central and KoBo. It may be the same thing technically but ultimately for most users I expect they will use this feature to differentiate between different projects, all of which may be on the same server or even use the same account/password.


I think so. We've tracked analytics on settings being loaded from those files and it's in the single digits for the past 90 days.

The idea is that 'Reset profile' would be exactly the same as 'Reset application' currently is but only apply to the current profile. Is that the functionality you'd want? Ideas for making that clearer are much appreciated.

This would not be a possible state -- there would always be at least one profile. On upgrade, the configured server domain would be used to populate the profile name, icon and color. If your server were, your profile would be named In the upper right hand corner, you'd see a T with a background of whatever color the domain name hashes to.

I agree that immediately after upgrade it might not be clear what it means. But I think it's pretty natural to try tapping it and I believe the profiles dialog would make it clear what's going on. Additionally, anyone who has ever used any Google app would be used to this structure.

Do you mean well-known within Collect or in Android more broadly? My sense is that for apps that use accounts, having an account indicator instead of an overflow menu is very common. See all the Google apps or any social app. I think the important thing is that people know to tap it. The convention that items on the upper right of the app bar are tappable is so strong that I imagine anyone who has used an Android device would know to tap there. For someone who hasn't used an Android device, it's not clear to me that the three vertical dots has any more meaning than a round button-looking-thing.

Good idea, we can also experiment with that, possibly in addition to the icon indicator. Perhaps the profile name goes in the app bar and the version information goes somewhere else.

I agree they look bad as styled but perhaps it's mostly because of the styling? The mockups are meant to be rough even though they ended up looking more "real" than they probably should because I was copying and pasting material components. I think we could match the styling of "Add profile" with an icon at left or use a button style similar to what the Google apps use in that same space. What I like about this layout is that it's very clear that the settings belong to a specific profile. If we maintain the overflow menu, to me it would look like settings are applied across all profiles.

I agree with this, especially since typical workflows for configuring a bunch of devices with admin protection involve QR codes. I think admin settings can now be less accessible. My preference would be to group a change to settings location with a first launch experience update. In my ideal world we can make the addition of profiles minimally invasive and then do a comprehensive overhaul of the UI as a separate step. I think if we tie too many changes together it will be overly risky.

Are you imagining changes to the concept beyond what it's called? We pitched a more generic "profiles" name because people organize forms in all kinds of different ways across the various supported servers which may or may not have project concepts. That said, I'm personally happy with "projects."

Thanks for all the replies @LN. I think I am persuaded on all points.

I'm not sure what this means:

What is a first launch experience update? Are you saying you don't want to change the structure of settings at the same time as adding profiles?

Don't hesitate to come back with more alternatives. I'll try playing around with making the profile/project name more visible soon.

That does sound kind of jargony, oops! I mean updating what users experience when they launch Collect right after installing it. Ideally users would get guided through adding a new profile/project. I think that change will feel like a major improvement to the app and that it would pair nicely with updating how settings are accessed. Mostly, if possible, I'd like to try to keep this profile/project feature fairly focused because it already has a lot of pieces.

Right, I guess that's clearer. :grimacing:

I think of a project containing one or more forms that someone in the field needs to work on. I think it reflects the reality on the ground better (one person working on one or more projects to collect data for different ends) than "profiles".

"Profiles" implies to me that you could not use the same server/username combination more than once. If that's the case, we should keep profiles and think about how "projects" can be managed and displayed separately.

1 Like

I got some questions on the TAB call about how one user on a Central server would handle being in multiple projects and I wanted to put my response here for the public record.

Right now, they would scan a different app user QR code for each project and that feels very natural to me. In the future, we’ll also be enabling web users with usernames and passwords to collect data in Collect. In that case, they'll be able to enter a user name, password and project ID (likely select from a drop down list of projects you have access to) And we’d also be able to embed that information in a QR Code.

If I switch the profile on Collect what happens to the downloaded forms? Are they hidden or removed or do they persist? What about saved forms?

If I have added multiple profiles on Collect, do they all sync their forms when in WiFi or just the active one? To fetch/send forms from multiple profiles do I need to toggle between them?

Could Central be changed to allow an App User to be given access to forms across different projects? So that a data collector can fill out forms from multiple projects without changing the Central-URL-with-token.

Question: we have several cases where projects share the devices. A typical example of one institution where once a week the interviewer goes to collect data for project A. Another day or days another interviewer could use the same tablet for a project B, maybe there's as well a project C etc etc...
In this scenario Interviewer B by clicking on switch profile could potentially open forms A and C and see saved data or send data. Wouldn't pe possible that on click an app user has to enter a confirmation code or password to access his profile?

Everything will be kept but not visible (for other profiles). We haven't decided on the implementation yet but probably we are going to create the same structure of dirs (forms, instances, layers, metadata) for every new profile so every profile will have its own space on a device.

That's a good question. We have two automated tasks, one responsible for uploading forms and another responsible for downloading updates. We thought that at least the first one should work for all profiles no matter which one is active but it's not set in stone.

Every profile will have its own settings (general and admin) so for every profile you will be able to set admin password like now. I don't know if we are going to implement it immediately but it shouldn't be a problem to protect profiles using that password.