Web Services
Most Recruit data is available in JSON format via RESTful APIs.
Authentication
AP Recruit supports Shibboleth, allowing customer campuses to use their existing single sign-on system to perform authentication. AP Recruit relies on Shibboleth to release an external user ID (possibly eduPersonPrincipleName) that will be used to uniquely identify each user within the system. This external user ID should also be present in the Directory and Access Control data exchanges (described later in this document) so that AP Recruit may properly load directory and authorization information for the authenticated user. Currently UC Recruit supports Shibboleth authentication for the Faculty and Administrators area only (not References or Applicants).
Domain Name and SSL
AP Recruit is designed to be accessed as a sub-domain of the customer campus’ domain name (e.g.: recruit.ap.uci.edu, apol-recruit.ucsd.edu). AP Recruit also requires a valid SSL certificate provided by the customer campus. Customer campuses are responsible for renewing this SSL certificate prior to expiration.
Access Control
AP Recruit expects customer campuses to input some basic access control information into the system. Without this information, users will not be able to login and process recruitments.
Customer campuses are asked to populate access control data via one of AP Recruit’s supported data transfer methods (see “Data Transfer Methods” section below for more details). Unless customer campuses have exceptional needs, we recommend using a data feed for populating faculty roles and a simple built-in web interface for managing all other roles.
User roles are also used when determining access to letters of reference for applicants:
Academic Unit Hierarchy
Recruit requires basic school/division and department structure for customer campuses. This information helps users in locating recruitments, allows for scoping access to specific departments or schools, and supports a delegated support structure.
User Directory
AP Recruit requires some information about each campus affiliate that interacts with the system. Examples of campus affiliates are faculty who will potentially participate in search committees, analysts, and anyone else who requires access to the “Faculty and Administrator” section of AP Recruit.
Academic Employee Demographics
UC Recruit accepts a spreadsheet listing individual academic employee gender and ethnicity. This data is used to create the UCOP Search Data report requested annually by UCOP.
Data Feeds
Data is provided to UC Recruit via either data feeds, web services, or a combination of the two. Learn all about the wonderful world of data feeds.
Title Codes & Specialties
AP Recruit includes a list of title codes that is sufficient for UCI and UCSD needs. This list may need to be modified for customer campuses in case of missing title codes. Typically Academic Personnel will maintain a complete list of academic title codes used on campus.
A recruitment in AP Recruit will have one or more associated specialties or research areas. These specialties are included in diversity reports, allowing Recruit to include national diversity figures for comparison purposes. Currently the list of specialties and corresponding diversity benchmark/availability data are provided by UCI Office of Equal Opportunity and Diversity. This data may need to be updated to meet customer campus equal opportunity & diversity reporting needs.
Data Transfer Methods
UC Recruit supports the following data transfer methods:
- Web Service, using HTTP/RESTful API and XML
- Data Feed, using SCP/SFTP protocol, CSV files, and routine data import processes.
- Admin Tool, provided to authorized individuals. Allows for in-tool editing of data.
The following table identifies each type of data required by AP Recruit and its corresponding supported transfer mechanism.
|
Data Type |
Web Service? |
Data Feed (CSV)? |
Admin Tool? |
|
Academic Unit Hierarchy |
No |
Yes |
Yes |
|
Directory |
No |
Yes |
No |
|
User Roles |
Yes |
Yes |
Yes |
Supported Recruit Environments
Each customer campus has access to three UC Recruit environments:
- Production: the live site where recruitment activities take place.
- Training: used during in-class workshops, e-Learning, or as a sandbox for new analyst users to learn the system.
- QA: an environment used in testing system integration and reviewing branding changes. Post-launch, the AP Recruit team will invite members from each customer campus to use this site in testing new releases prior to deployment to training and production environments.
Each environment requires data in order to function correctly. The Production environment always requires live, up-to-date data. Training data may differ from Production data depending on the customer campus needs.
Examples of data populated to the Training environment:
- UCSD imports a small set of test users into their Training environment. During classroom training, each attendee is assigned a test user ID for the duration of the class. At the end of the class the test ID password is reset.
- UCI imports a full copy of the UCI directory into their Training environment. This allows analysts to complete initial online training and then continue using the environment as a sandbox with data that mirrors Production.