Technical Documentation: Information about UC Recruit, including data feeds, web services, access controls, and more.
Integration Checklist: runs through all of the tasks for both UCI and your campus. Use this to keep on track with the project.
Customer Worksheet: details the information UCI needs to get started integrating UC Recruit with your campus. Use the technical documentation to help fill out the customer worksheet when going through your initial integration with UC Recruit.
Branding: information about how to customize the images and text strings for UC Recruit for your campus
Minimally Viable vs Full Integration
The AP Recruit team recommends a Minimum Viable Integration unless a customer campus has exceptional needs. This approach will reduce time required to integrate campus systems with AP Recruit.
Examples of exceptional circumstances where the Minimum Viable Integration approach may not be appropriate:
- The customer campus requires the use of a central access control system. Access data is provided to Recruit in an automated fashion.
- The customer campus already has school and department data in a form that can be easily transformed into a format suitable for feeding into AP Recruit.
The following table is intended to help customer campuses choose between a Minimum Viable Integration (requiring the least amount of upfront development time) and Full Integration (requiring the most upfront development time).
|
Integration Option |
Directory |
Access Control |
Academic Unit Hierarchy |
|
Minimum Viable Integration |
Nightly feed of Recruit users |
Nightly feed of Senate faculty user roles only |
Initial spreadsheet of schools & departments, ongoing updates via web interface |
|
Full Integration |
Nightly feed of Recruit users |
Near real-time updates via Recruit’s API of faculty, analyst, and equity advisor roles |
Nightly feed of data |
Both options have benefits & disadvantages described in the following table:
|
|
Minimum Viable Integration |
Full Integration |
|
Upfront development time commitment[1] |
Low: 12 weeks @ 25% FTE |
High: 12 weeks @ 60% FTE |
|
Academic Unit Hierarchy Maintenance |
Staff manually updates using web interface as structure or unit names change |
Automated updates via feed. Can save time in the long run if the customer campus already maintains this data |
|
Access Control Maintenance |
Staff manually updates Analyst and Equity Advisor roles for users using a web interface. Assumes customer campus provides faculty user roles via feed |
Automated updates via API. Allows the use of a central access control system |
[1] This is a very rough estimate that does not account for differences in customer campus IT architecture and capabilities.
Changelog
- 12/12/2012: Removed document, linked to new technical documentation, added links to download worksheet and view checklist.
- 1.10: Added section “Working with Data Feeds”. Added data feed contact to Customer Worksheet.
- 1.9: Added survey response data to the Recruitment Information Web Service
- 1.8: Removed information about deprecated faculty level column in directory feed
- 1.7: Adds information about updates to web services
- 1.6a: Same as 1.6 but without “Track Changes” enabled (and changes accepted)