VII. Access Control Specification

Supported Data Transfer Methods

Customer campuses have three options for maintaining user access control data over time:

Transfer Method	Setup & Maintenance	Integration Considerations	Update Frequency
Manual Updates	Quickest to set up.  Possibly higher maintenance costs.	No integration with external access control system	Depends on how quickly a staff member performs update
Data feed	Moderate setup.  Lower maintenance costs.	Possible to feed Recruit access control data from external access control system	Nightly
RESTful API	Longest to set up.  Lower maintenance costs.	Possible to push data from access control system to Recruit.	Real-time or as needed.

Definitions

UserRole

A UserRole defines a relationship between a User, a Role, and a Resource. Think of a UserRole as authorizing a User to act as a Role for a given Resource.

User

A User corresponds to an entry in the user feed for AP Recruit, addressable by external_user_id or alias attributes. While each person who logs in to AP Recruit should have a single user entry, a given user may have multiple roles and thus multiple UserRoles. The external_user_id represents the primary key defined for the user data feed, while the alias is typically the username used to log into AP Recruit.

Note:

There are three classes of users defined within AP Recruit: Applicants, References, and Users. Users encompass analysts, search committee members, and anyone involved in managing the recruiting or diversity processes. Applicants and References are not considered to be Users for the purpose of this specification.

Role

Each Role defines a set of permissions, such as the ability to manage recruitments, create survey reports, manage applicants, etc….

Role name	Manageable via Automation?	Description
Administrator	No.  Must be managed via User Manager.	Generally staff assigned to support users of the system.  Typically this includes at least one person from the business office (Academic Personnel, Faculty Equity, Equal Opportunity and Diversity, etc…) and one person from IT (central or department IT unit).  Recruit tasks include: provide technical & business support, grant user access to training and production environments, investigate trouble reports, “proxy” as other users.
Central AP Analyst	No. Must be managed via User Manager	Staff within the central AP office.  Recruit tasks include: generate annual search data reports required by UCOP (part of a future enhancement).
User Manager	No.  Must be managed via User Manager.	Staff authorized to grant others access to use Recruit.  This role is intended for customer campuses that prefer to manage access wholly or partly using a web-based management screen.  Note: Recruit also allows customer campuses to update access information via data feed or web service.  Recruit tasks include: add, edit, and remove user access.
Diversity Analyst	No.  Must be managed via User Manager.	The person in the equal opportunity/diversity/affirmative action unit responsible for compiling reports on applicant diversity.  Recruit tasks include: create and review diversity reports for individual recruitments, view applicant pool, view shortlist, and download spreadsheets of diversity survey responses.
Equity Advisor	Yes.	Typically a senior faculty member appointed to a school/division that participates in faculty recruiting by approving search strategies and raising awareness of best practices.  Not all campuses currently have this role.  Recruit tasks include: generate and review diversity reports, reviewing (but not managing) applicants.
Recruit Analyst	Yes.	Staff that manage recruitment listings within Recruit on behalf of a school or department.  School analysts are authorized to manage recruitments for all departments listed under the school.  Department analysts may only manage recruitments for their department.  Recruit tasks include: create new recruitments, manage applicant pool, generate diversity reports, answer applicant questions, input write-in applicants, specify search committee members.
Recruit Analyst (No Reports)	Yes.	Same level of access as “Recruit Analyst” role, but with no access to view or create Diversity Reports.  Some campuses may opt to use this role instead of “Recruit Analyst” if their central AP or diversity office handles all diversity reporting.
Committee Chair	No.  Must be managed via Committee Manager.	Chairs are assigned to a specific recruitment.  This is an internal role managed by Recruit Analysts using the web-based Manage Committee tool.  Recruit tasks include: review applications and letters of reference, manage applicants.
Committee Editor	No.  Must be managed via Committee Manager.	Editors are assigned to a specific recruitment.  This is an internal role managed by Recruit Analysts using the web-based Manage Committee tool.  Recruit tasks include: review applications and letters of reference, manage applicants.
Committee Member	No.  Must be managed via Committee Manager.	Members are assigned to a specific recruitment.  This is an internal role managed by Recruit Analysts using the web-based Manage Committee tool.  Recruit tasks include: review applications and letters of reference.
Full Professor	Yes.	Full professors appointed to a specific department.  The section “Faculty Roles within Recruit” describes how Recruit uses faculty level role information.
Associate Professor	Yes.	Associate professors appointed to a specific department.  The section “Faculty Roles within Recruit” describes how Recruit uses faculty level role information.
Assistant Professor	Yes	Assistant professors appointed to a specific department.  The section “Faculty Roles within Recruit” describes how Recruit uses faculty level role information.
Lecturer (SOE)	Yes.	Lecturer with Security of Employment appointed to a specific department.  See “Faculty Roles within Recruit” for more information.
Lecturer (PSOE)	Yes.	Lecturer with Potential Security of Employment appointed to a specific department.  See “Faculty Roles within Recruit” for more information.
Other Professor	Yes.	An individual recognized as a faculty member.
Approver Roles	Yes.	Individuals with approval authority for search plans and various reports. These individuals may have authority to approve at the department (e.g.: Department Chair), school (e.g.: Dean), or the entire tool (e.g.: Chancellor).  New approvals will automatically fill in approvers when appropriate for the step.

Resources

The Resource is the context given for a UserRole. While a UserRole can be associated with a number of different types of resources within AP Recruit, only three resource types are permissible via automation: Departments, Schools, and the ‘recruit’ Tool. A resource is identified by its resource_type and its resource_external_id, the key defined via the School and Department data feeds.

Example

Suppose we have a user, “Theodore Geisel.” Theodore is responsible for managing recruitments for the Department of Sneetches and the Department Department of Grinches. Theodore would then have two UserRoles, a Recruit Analyst role for each department. These roles would grant Theodore access to create new recruitments, generate diversity survey reports, and manage applicants for any recruitment under his departments.

Restrictions

While AP Recruit defines many roles and allows for a wide variety of associated resources for UserRoles, only the following may be managed via automation:

• Only UserRoles with a Role of Recruit Analyst, Recruit Analyst (No Reports), Equity Advisor, Full Professor, Associate Professor, Assistant Professor, Lecturer (SOE), Lecturer (PSOE), Other Professor, Committee Chair, Equity Advisor, Faculty Principal Investigator, Department Chair, Department Director, Dean, Diversity Office, Central AP Office, Academic Senate, Provost, Executive Vice Chancellor, Chancellor, Dean’s Analyst, University Librarian, Budget Office, Vice Provost, and Affirmative Action Reviewer roles can be managed.
• Only UserRoles with School, Department, and Tool resources can be managed.
• Only UserRoles with the auto flag set are eligible for automated updates.  All UserRoles created via automation will be given this auto flag.  UserRoles created via the web-based User Manager tool will not have the auto flag set.
• Some combinations of roles and resources are not allowed, e.g.: Full Professor of a School (only Department resources are allowed for faculty roles).

 

Faculty Roles within Recruit

Recruit uses faculty role information in the following ways:

• Determining access to letters: some departments allow only select faculty ranks to view letters of reference.  For more information on how Recruit uses faculty roles to determine access to letters, please see Appendix A: Access to Letters of Reference.
• Granting access to committee: some departments open a recruitment to all ladder-rank faculty at prescribed stages of a recruitment.  Instead of requiring analysts to manually add each individual faculty member to the search committee, Recruit allows for quickly adding an entire department to the committee.  This has the same effect as adding each individual Full Professor, Associate Professor, Assistant Professor, Lecturer SOE, and Lecturer PSOE to the search committee with one exception: as faculty members join or separate from the department, access to the committee is automatically granted or revoked.
• Displaying faculty role: analysts see faculty roles when building a search committee to aid in identifying the correct individual.

 

Data Transfer Method 1: Manual Updates

The first option for managing user access within Recruit is to manually update some or all user roles using a web-based administration tool.  While this option requires no upfront development time, it will require staff to manually input all UserRoles (including rank information for all Senate-level faculty members).  For UCI, this manual entry would require input of about 1,000 faculty UserRoles.  At a minimum, consider using automation to transfer faculty UserRoles to Recruit.

For customer campuses that prefer to use an existing access control system and push access data to Recruit, consider using the data feed or API transfer methods described in the next two sections.

To establish manual user access updates, please provide the email address of the user or users responsible for managing access.  The AP Recruit team will give this user access to the User Manager tool within Recruit’s Admin area.

Certain roles within Recruit must be managed via the User Manager web-based tool, including privileged administrator and diversity analyst roles.

Data Transfer Method 2: Data Feed

A User Role in Recruit consists of an external_user_id, a role, a resource_type and a resource_external_id.

Attribute Name	Format & Description
external_user_id	A non-empty UTF-8 string, up to 32 characters.  This references the user entry for the user.
role	A non-empty UTF-8 string, matching the name of a role within Recruit.  See “Restrictions” above for the acceptable role values.
resource_type	A non-empty UTF-8 string describing the type of resource.  See “Restrictions” above for acceptable resource_type values.
resource_external_id	A non-empty UTF-8 string up to 32 characters, referencing a school, department, or tool external_id.

Note: UserRole records that had been provided by a feed that are present in Recruit but missing in a subsequent user role feed will be deleted from Recruit.

Some sample data feed entries for user roles might include:

which is adding Peter Anteater as a Recruit Analyst to the Informatics Department.  If in a subsequent feed this row is not present, the UserRole within AP Recruit will be deleted.

Data Transfer Method 3: RESTful API

Visit the API: User Roles page for information about the RESTful API.