Why use Work Groups?
Work Groups allow you to manage permissions for a group of users instead of separately managing permissions for each individual user. For example, you can establish the permissions for all your reviewers in a single Work Group.
Work Groups are divided into what a user can do in WebAdMIT for AMCAS (Permission Sets), what a user can see on an applicant’s page in WebAdMIT for AMCAS (Panels and Sub-Panels Enabled for Viewing), and for some CASs, what reports a user can run. Based on what the user’s abilities need to be in WebAdMIT for AMCAS, some or all of these sections of the Work Group template may need to be completed.
A WebAdMIT Administrators Work Group is available by default and provides users with full administrative access. If you want to limit a user's access to WebAdMIT for AMCAS, review the example Work Groups below; you can use these as a template when building your own Work Groups. Be sure to review how to create Work Groups and user accounts first.
What's impacted when I limit a user's access through Work Groups?
If you restrict access to a permission set, then a user cannot access a feature's management tool and/or perform updates on an application.
If you restrict access to a panel or subpanel, then the user cannot access the information anywhere in WebAdMIT for AMCAS, including these pages and tools:
- Applicant Details page
- Applicant Header
- Full application PDF
- Email templates
- List Manager
- Export Manager
- PDF Manager (for PDFs under the Documents and Evaluation panels)
Example Work Groups
You can customize permissions and Work Groups to fit your needs. The examples below show how you might configure a Work Group and how the resulting applicant pages would appear to its members.
Example 1: Faculty Reviewers/Interviewers
For users who will be reviewing applicants and/or conducting Interviews. In this example, they don’t need any administrative functionality through permission sets and only need access to select panels (e.g., Assignments, Education, Evaluations, Experiences, etc.).
Resulting Applicant Details Page
Resulting Full Application PDF
Example 2: Faculty Reviewers/Interviewers without Race/Ethnicity Data
For users who will be reviewing applicants and/or conducting Interviews and should not view applicant race or ethnicity data due to program, university, state, or federal mandates. In this example, they don’t need any administrative functionality through permission sets and only need access to select panels (e.g., Assignments, Education, Evaluations, Experiences, etc.).
*Note that the Personal Information Race and Ethnicity subpanel is not selected. For some CASs, race and ethnicity data may be collected in a CAS Custom Question. If that is the case, then do not select the corresponding panel/subpanel under Cas Custom Questions. Contact a member of your account team to learn how your CAS collects this data.
Resulting Applicant Details Page (note that the Race and Ethnicity subpanel does not appear under the Personal Information panel)
Resulting Full Application PDF (note that the Race/Ethnicity section does not appear under the Citizenship Status and Residency Information section)
Example 3: IT Staff
For users who will be working with applicant lists and configuring exports. They only need access to the data that will be exported.
Resulting Applicant Details Page