Using the Panel Coordinator/Panel Field Manager roles in 8.0 and later

Overview

Panel Coordinator and Panel Field Manager are survey roles that exist to give proper rights and actions to panel partners.

• Panel Coordinators (PC) are able to see all data – regardless of panel origination – while controlling quota caps for all data collected within the survey. Additionally, they can approve/reject/expunge data records only from their panel (defined by panels associated with their email domain). 
• Panel Field Managers (PFM) are restricted to viewing data originating from the panel associated with their email domain. They can view an aggregated view of quotas (in future releases, PFMs will be able to set caps only for their panel). They can approve/reject/expunge data records originating from their panel. 

The Panel Field Manager role is intended to be given to nearly all panelists on a project, with the Panel Coordinator role being given to the "main" panel (or the client panel) on the project. Since Panel Coordinators have the ability to view all data, regardless of panel source, this role should be given out sparingly on projects where there are multiple fielding panels.

PCs are like PFM+, with all the rights and more of a PFM. The following table shows the difference between the rights for PCs and PFMs.

Limitations and rights

PCs and PFMs have different rights available to them: 

In order to assign the role of Panel Field Manager to a user, the email domain of that user must be included in the system.system_panels sheet. The functionality of the PFM role is reliant on fields within this sheet, and therefore users originating from domains not present in the system.system_panels sheet cannot be added.

Prepping source 

On every survey, it is assumed that the Panel applet will be used. Therefore, the below code is the implied survey default:

app config
use panels: auto

use panels: auto can be overwritten by replacing "auto" with panel IDs found within either the system.system_panels sheet, or a custom sheet (see Using Other Sheets below), if the Panel applet is not to be used on a survey.

On every survey:

• panel is created
• panel_quota is created, which is a quota comprised of all panels identified via the Panel applet or the use panels: #  tag
• pfm_approve will auto-populate according to the respondent's panel value, using a value taken from the system.system_panels sheet (more information on this can be found below).

Using other sheets

Sometimes on a per-project basis there is a need for PFMs to use another sheet besides system.system_panels. This need may arise because the Survey Programmers (SPs) need to

• grant some panel users access to other panels, or
• modify redirects or add a panel.

To meet these needs, SPs may specify which sheet to use instead of system.system_panels by applying the panel_sheet tag to a survey's app config. The alternate sheet would be added locally (to the survey itself) via the Spreadsheets applet.

app config
panel sheet: surveyid.panelsheetname
use panels: #, #

If the panel sheet tag is not applied to the app config, the system will default to system.system_panels.

Quotas

As shown above, the Quotas applet functionality is affected by users' survey roles. Continue reading for more specifics.

Creating quotas

Oftentimes, surveys will require quotas to be nested/crossed by panel, so clients can view from which source certain data points are streaming from, as well as cap certain panel sources. If panel is used in a crosslist and then utilized within a quota, that quota will display a restricted view of the quota options. PFMs will only be able to view options for the panel they are a part of. 

In the example above, there are three panels on the project, Panels A, B, and C. QCRQ is a quota utilizing a question crossed by panel. PC users will be able to view all quotas. PFMs can only view the data collected for their panel when viewing cross quotas, so for a PFM on Panel A, notice they are only able to view the information coming from Panel A.

An example of what the code would look like for QCROQ:

setlist: CROQLIST
crosslists: panel, CROLIST

CROQ. crossed quota
type: quotas
optsfrom: CROQLIST

Quota view and managing

Both PCs and PFMs will have access to viewing the total quota counts for the survey, regardless of panel source. However, how each survey role can set quotas varies.

PCs will be able to set quota caps for the entire study, regardless of panel source. Currently, PFMs do not have the ability to set quota caps. 

pfm_approve

Some panels require viewing the data acquired from their panel members prior to "releasing" or "approving" it to the end client. As such, when use panels is included in the survey source, pfm_approve is created and filled with the default stored value within system.system_panels. There are three values for pfm_approve:

If you need to override the default pfm_approve variable, use the following code:

set value
question: pfm_approve
value: #
condition: anyChecked($panel,#)

In this code, you would replace the '#' with the values pertinent to the needs of the study.

PFMs and PCs have the ability to approve or reject records. They can utilize the applets Approve records and Reject records, found under the Data button group in the Survey Navigation menu.

Expunge

PFMs and PCs can also choose to expunge records. This can be done via Data > Expunge Records. Once a record is expunged, it will no longer be viewable to PFMs, PCs, or clients. It will not count towards quotas, and effectively will be removed from the dataset (while still existing there in case the action needs to be reversed). If this action needs to be reversed, a Survey Programmer will be required to assist. If a client or panel required a respondent to be "marked as removed", they should use the Expunge Records applet to do so.