Using the Panel Coordinator/Panel Field Manager Roles in 7.5 and earlier

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.

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

The PC and PFM roles are designed to work with a few pieces of code inserted in the source.

app config
use panels: #, #
auto redirect: system.system_panels

In the code above, '#' will be replaced with the panel IDs found within the system.system_panels sheet. This sheet contains information on each panel that has been through our software, including email domains, redirects, associated panels, and the default value for pfm_approve (more information on this can be found below).

When use panels is included, this fires off a number of events:

• panel_list (a set list) is generated, which is a subset of the system.system_panels sheet using only the IDs specified with use panels 

• panel_quota is created, which is a quota comprised of panel_list 

• pfm_approve will auto-populate according to the respondent's panel value, using a value taken from the system.system_panels sheet.

With use panels  specified, this will permit the addition of users with a PFM survey role. Note when use panels  is set, one should not need to create a variable such as QPANEL.

Using Other Sheets

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

• rename the panels to mask them on a project for clients,
• grant some panel users access to other panels,
• 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

When use panels  is applied, you'll recall that panel_list is created. 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_quota 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_quota. 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_quota, 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.

Caveats for Pre-7.3 Versions

PFM and PC roles have existed prior to r7.3, however in r7.3 they received improved functionality. Therefore, some attention is needed when using PFM roles with surveys on versions r7.2 or earlier.

Default value of pfm_approve

The default value of pfm_approve was a functionality added in r7.3. Unless specified within the code itself, pfm_approve will have a value of '1' (Approved) for every record for surveys running r7.2 or earlier.