Campaign

A campaign is a container for a single study, project, or program. Each campaign is a standalone web app with its own URL, accessible through a web browser on both mobile and desktop devices.

A campaign controls which participants can access which parts of the app through three mechanisms:

1. Policies and consent determine whether a user may participate or access specific data and features.
2. Waves determine when app layouts and content are available.
3. Groups determine to whom app layouts and content are available, and what information can be shared between participants and groups.

Policies, consents, waves, and (membership to) groups together determine what each participant can access within a campaign.

These rules are used by both campaign app layout and campaign content.

Policies and consent

A campaign optionally specifies Terms of Service and a Privacy Policy that participants must accept before they can use your app.

Additionally, a campaign can define consent items. Consent can be either required or optional.

Required consent can gate participation in the campaign. Optional consent does not prevent participation, but can be used to control access to specific parts of the campaign or determine whether secondary users, such as researchers, may access particular participant data.

Waves

Waves control when specific app layouts and content are available.

A wave can have a start date, an end date, both, or neither. A wave without either bound is always active. Otherwise, the current time must fall within its configured period for the wave to be active.

Waves affect availability, not existing progress. For example, when a wave ends, a participant may lose access to a Mission without losing the progress already made in that Mission.

Groups

Groups control to whom specific app layouts and content are available.

Participants can belong to one or more groups. App layouts, content, and other campaign configuration can then be assigned to those groups.

Memberships and roles

A membership links a user to a group and assigns one or more roles to that relationship.

Available roles are:

• Participant — participates in Campaign content through the group membership, including Missions assigned to that group.
• Manager — manages memberships and membership requests for the group.
• Trainer — can register activities for other group members where the applicable access rules permit it.
• Ghost — can observe other group members and, where the applicable permissions allow it, their data, without appearing as an ordinary visible member of the group. Hence, Ghost-memberships are not exposed through ordinary participant-facing membership lists.

A membership can contain multiple roles, subject to role-combination rules. Of course, Participant and Ghost cannot be combined within the same membership.

Holdings

Groups are organized through holdings.

Every group belongs to a holding. A holding defines how its child groups are organized, how participants can enroll in them, and what information can be exposed within or between them.

A holding has one of three types:

• Campaign — organizes participants at the level of the campaign as a whole. A campaign typically contains a campaign holding with a single group representing its participant population. New participants are automatically enrolled in the child group of the campaign holding.
• Study arm — organizes participants into different intervention or study conditions. Groups within a study-arm holding can receive different app layouts, content, or both. These groups are typically not exposed to participants. New participants are randomly assigned to one of the child groups of the study-arm holding.
• Group — organizes participants into groups that are meaningful within the intervention itself, such as teams, departments, or communities. These groups can be exposed to participants and can support group discovery and membership workflows. Participants may be enrolled by a campaign organizer or join or request membership themselves.

A group can itself be the parent of another holding. Alternating groups and holdings can therefore form a hierarchy.

For example:

Campaign holding
└── Campaign group
    └── Study arm holding
        ├── Intervention group
        │   └── Group holding
        │       ├── Team A
        │       └── Team B
        └── Control group

Holding enrollment settings

A holding determines how users can be enrolled across its child groups.

When requires enrollment is enabled, normal application navigation is blocked until the user obtains a membership in one of the holding's child groups. Access to the enrollment flow, request status, and sign-out remains available.

When allow enrollment in multiple groups is disabled, a user can have at most one Participant-membership across the child groups. A pending request for a Participant-membership also reserves this slot. Memberships containing only roles such as Trainer, Manager, or Ghost do not consume it.

For example, a user who is a trainer in Team A and a participant in Team B has one Participant-membership for this rule. A user who participates in both teams has two.

Individual groups also control how new memberships are handled. A group can either accept a membership directly or require a membership request to be approved first.

Holding permissions

Holding permissions determine what information can be exposed within or between the child groups of a holding.

Expose groups and Expose group memberships are deliberately separate. Being allowed to see another group does not automatically mean being allowed to see who belongs to it.

Note that holding permissions and membership roles serve different purposes. A membership role determines what a user may do in relation to a group. Holding permissions determine what information may be exposed within or between groups.

Permission access

Each permission can have one of three effective access levels:

• Not — the information is not exposed. This is the default when no applicable permission is configured.
• Within group — the permission applies between members of the same child group.
• Between group — the permission also applies between different child groups of the holding.

The levels are ordered from least to most open:

Not → Within group → Between group

When more than one applicable permission exists, the more open permission takes precedence. Between group therefore also includes the access provided by within group.

Permission scope

Holding permissions apply only to the direct child groups of the holding on which they are configured. They do not propagate through nested holdings.

Consider for example:

...
└── Study arm holding
    ├── Intervention group
    │   └── Group holding
    │       ├── Team A
    │       └── Team B
    ...

A between group-permission on the study arm holding does not expose data between Team A and Team B. Both teams belong directly to the nested group holding, not to the study arm holding.

To expose data between Team A and Team B, configure the relevant permission on their immediate holding.

And again, within group only exposes information within a single group. Sharing between sibling groups, such as Team A and Team B, requires between group on the holding that directly contains those groups.

Shared-mission activity exposure

Expose activities with contributions to shared missions only exposes activities when the relevant participants currently participate in the same Mission.

Both the activity owner's Participant-membership and the viewer's Participant-membership must currently qualify for that Mission. This takes into account the applicable enrollment, participation decision, wave, and Mission availability.

A historical contribution alone is not enough. If shared participation ends—for example, because a participant opts out, a wave ends, or the Mission is completed—the activity is no longer visible through this permission.

This does not delete the activity or its contributions. It also does not remove access granted through another permission or through ownership.