Get Started
Introduction to the platform
The Campus Labs platform enables institutions to collect, manage, and report on data useful for teaching and learning, accreditation, and student success program design and improvement. The platform is offered to end-users as a software as a service (SaaS) web application, accessible via any modern web browser. The platform can, should, and in some cases, must be integrated into existing institutional data infrastructure to gain the most benefit from its capabilities through methods outlined in this document.
Common technical inquiry topics
Data collection
The Campus Labs platform collects many types of data including, but not limited to, the following:
- Student, staff, and faculty self-reported responses to survey and form questions
- Notation about student or program performance
- Observational and behavioral notations about students, staff, or faculty
Data hosting & security
The platform is hosted on servers, owned or leased by Campus Labs, at secure datacenters. Data is backed up nightly and is wholly owned by the campus. All Campus Labs employees are held to the highest non-disclosure standards and agreements. Campus Labs is FERPA-compliant.
Maintenance & upgrades
Campus Labs performs all system administration duties and delivers patches and upgrades to the platform via a continuous integration model which rarely requires down time. Institutional primary contacts are notified of upgrades via email.
Institutional asset requirements
In order to get the most out of integration with the Campus Labs platform, many institutions identify two (2) information technology professionals with specific skill sets to attain integration.
The first task, authentication, requires an IT professional that understands the identity management infrastructure of the institution and is familiar with the common techniques that the institution has used in the past to connect to other third-party technology applications.
As the authentication connection is being established, an IT professional that is familiar with accessing, formatting, and sending large data sets from systems like the student information system (SIS), learning management system (LMS), and/or enterprise resource planning system (ERP) to third-party platforms can begin work on understanding the core data exchange requirements.
Once the authentication connection is complete and tested the core data exchange process can be initiated and tested. Staff at Campus Labs will refer to the institutional IT professional tasked with the core data exchange as the Campus Data Manager.
Types of integration
The platform is capable of several data integration touch points into common institutional environments.
Required integrations
The following integrations are required to enable access of the web application to end-users and must be completed before or during the initial training period immediately following the license start date.
Person Identifier
The goal of the platform is to create one system that brings data together for new insight. In order to accomplish this task the platform requires a single point of identification for a user that is consistent across all components of the suite and that is able to be associated back to a single person at the Member Campus for cross-tabulation and identification purposes.
Campus Labs uses this unique identification to:
- Allow access to the web application
- Associate collected data to a single reference point
- Display a custom user experience to each user
- Share information about a user across the platform's elements for various reporting and visualization functions
More information about selecting a unique identifier for your implementation of Campus Labs can be found in the Choosing a Person Identifier documentation file.
Authentication
The platform connects to campus identity management systems in order to identify and credential users. The selected authentication method must be capable of transmitting a fully and indefinitely unique identifier to avoid duplication of account creation or exposing incorrect data associations. Campus Labs provides support for the following authentication protocols:
Shibboleth
http://www.incommonfederation.org/
Campus Labs is an InCommon provider, listed under parent company Higher One, Inc.
CAS: Central Authentication Service
LDAP: Lightweight Directory Access Protocol
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
Generic Pass-through
A proprietary method of authentication based on Security Assertion Markup Language (SAML) typically used when the institution cannot achieve or support the other preferred types.
Once an authentication method is selected please see the Campus Labs Authentication Worksheet .
Core data exchange
The core data exchange process enables the institution to send basic, large data sets to the platform in order to establish user accounts and baseline user information that will be used for data insight and reporting. There are three sets of data that are considered core data:
Accounts
Account data is the most basic information that the platform requires in order to identify a user and tie information to them. This information is used to customize the user experience of the web application and enable communication directly to the user in specific conditions. Account data will likely be contained within the SIS or ERP systems at the institution and include the following fields:
- Unique user identification
- First name of the user
- Last name of the user
- Email address of the user
- Preferred first name of the user (optional)
Demographics
In order to present interesting data visualizations, generate logical filtering, and create rules-based actions within the platform, several pieces of demographic and academic data points are required to be sent to Campus Labs. Demographic and academic data will likely be contained within the SIS or ERP systems at the institution.
Courses
One of the most valuable data associations at an institution is the academic history of a student. To allow insightful application of assessment data for teaching and learning and outcomes-based program improvement the platform requires course catalog and enrollment data. Course data will likely be contained within the SIS or academic catalog management systems at the institution. See Appendix D: Course Data Dictionary for information on specific data definitions.
Task-specific integrations
Several elements of the platform contain features that may require integration into the institution infrastructure to provide the best user experience or basic functionality. These task-specific integrations are not required for the basic functionality of the platform but are often highly sought-after features that primary institution users are interested in implementing.
Learning management widgets
Plugins that enable interaction with the platform from within the learning management system; helping faculty to generate and use data in a location that they are familiar with.
Application programming interface
The platform offers several API endpoints, which allow for institutions to generate and retrieve data and actions. These endpoints can be used to integrate specific combinations of applications in the institutional ecosystem or enable data streams for record-keeping purposes.
Campus Data Manager
In order to streamline the communication and troubleshooting process during the core data exchange integration process each member campus should provide the contact for a Campus Data Manager. The Campus Data Manager should be familiar with the broader campus data ecosystem, have access to data from elements of the ecosystem, and have sufficient ability and permission to reformat and send large data sets to the platform.
The Campus Data Manager will be provided with a Campus Labs support contact that can assist with the troubleshooting of issues that arise as well as with a web interface that can assist in identification of data loading errors.
Once a Campus Data Manager has been identified please register the individual with Campus Labs: http://bit.ly/cldatamgr
Core data exchange methods
Due to the importance of the core data elements for the platform and the highly varied technical capabilities of each higher education institution, Campus Labs supports the following methods to transmit the core data sets. A single method should be determined for all three elements of the core data exchange (i.e., do not mix methods).
For a detailed review of the core data exchange process please read the Core Data Exchange Process documentation.
Scheduled file import via Secure File Transport Protocol (sFTP)
This common method allows institutions to send large data sets to the platform by saving .CSV "flat" files containing data for Accounts, Demographics, and Courses into a Campus Labs hosted directory via a sFTP connection. The institution must provide the data in the file format indicated by Campus Labs along with a manifest file which indicates to the platform that the data file is complete and ready to be imported.
Once the data and manifest files are saved to the directory the platform processes the data file and incorporates the information into its data set. Any errors are displayed via a web interface accessible by the Campus Data Manager (demographics and courses) or delivered back to the institution via email from Campus Labs staff (accounts).
1 Diagram of basic file import process via sFTP
Web service & API endpoints
A more advanced method, requiring proficient campus IT professionals, which allows both bulk and individual field loading of data to the platform via secure, scheduled transactions over the internet. Each data type endpoint offers the ability to create, retrieve, and update the data. This additional, fine-toothed control of each data type offers institutions ultimate flexibility in the delivery and management of core data in the platform.
Campus Labs assumes that institutions that select this method have prior experience in programming against/with web services and API endpoints and does not offer support or training for IT professionals that are not proficient with these concepts and/or techniques.
If you are unsure if your institution should consider using the Web service & API endpoint method please read our Application Programming Interface FAQs
Manual file uploads
Using the same file formatting requirements of the scheduled file import method, this method requires a user to import the data via a web interface. This method is the most limited in terms of flexibility and is generally reserved as a last resort if the more robust options are not possible.