StarRez provides the ability to manage and assign housing stock.
Data feeds are provided from Banner for door access codes, demographic information and enrollment (housing eligibility) information.
A data download from StarRez to Banner is available as a job submission process in Banner. This process will push StarRez room assignments into Banner for use by the Active Directory feed, Facility Commander feed and Banner Room Key management forms.
When will demographic data be loaded?
Right now, demographic data will be loaded once a day at 1:30 am ET.
How is the student demographic data population determined?
We use the SYBISTU table as the basis for the demographic data population. The data is gathered from the baseline Banner student table, but incorporates other datapoints from other Banner tables that are useful for this load.
SYBISTU/SGBSTDN is term-based. What terms are you using to pull records from SYBISTU?
Housing business processes require future term data to assign housing. We use the following calculation to pick up students in future terms.
|Current Term||Terms used in student demographic pull|
|Fall (90)||Fall (90), Winter (10), Spring (20)|
|Winter (10)||Winter (10), Spring (20), Summer+ (50, 60, 65)|
|Spring (20)||Spring (20), Summer+ (50, 60, 65), Fall (90)|
|Summer (60)||Summer+ (50, 60, 65), Fall (90), Winter (10)|
Demographic data push from Banner to StarRez
Persons are inserted or updated by an API (application programming interface) push process using Banner data.
We do not delete persons from StarRez. The Housing office must purge person records as needed.
The concept of a population is to pull in everyone who could be housed.
|Population Group Name||Business Rules||Notes|
|Students (Undergraduate, Language Schools, School of Environment, Summer Study)||
Active Student record in Sybistu and
|Non-enrolled DMLs (Doctorate of Modern Languages)||Sybistu record exists for a summer term (ends in 60) with Student Type code = V (Visiting) and Student Status code = NE (Not Enrolled)|
|Long-term Housing Guests||Spriden name type = HGST (Housing Guest)||Spouses or dependents of language school faculty/staff, but may be other guests as well.|
|TAs (Teaching Assistants)||Employee class = 28|
|CRDs (Commons Resident Directors)||Job Titles starting with the characters "Common Res" or "CRA"||Example|
|Summer Student Employees||N/A||Summer Student Employees will already be loaded into StarRez as students.|
|Language School Faculty||Faculty member actively employed by Language Schools and working on the Middlebury Campus|
|Language School Staff||Staff member actively employed by Language Schools and working on the Middlebury Campus|
Housing Eligibility data PUSH from Banner to StarRez
Housing Eligibility data (also know as enrollment data) is inserted or updated by an API (application programming interface) push process using Banner data from Banner records.
This process sends all valid eligibility (enrollment) data for the terms of interest (see above). If a person does not exist in Star-Rez that is related to a new eligibility (enrollment) record, that person will be created in Star-Rez using only their ID and first/last names. As the demographic data in Banner is then set up for this new person, it will be updated in Star-Rez via the demographic data push process.
Room PIN codes PUSH from Banner to StarRez
PIN codes for rooms are maintained in Banner on an ellucian Self-Service Banner (SSB) web page. When a PIN code is changed on this page a process is triggered to send that updated PIN to Star-Rez via another API (application programming interface) push process.
Room Assignments PULL from Star-Rez to Banner
Room assignments are maintained in Star-Rez. Updates are sent back to Banner via a data extraction process invoked in Star-Rez. That process creates a file that is then imported into Banner through a manual (job submission) process that pulls the data into Banner and updates the appropriate Banner room assignment tables.
F A Q
Q: From: Hall-Kolts, Karin A. Sent: Monday, June 5, 2017 12:05 PM
Erin, Can you remind me of the outcomes of previous conversations we’ve had about the Class and Year fields in the Enrollment Details section of the Enrollment page? I was hoping the Class could be set to pull in the Expected Graduation Term and the Year would pull their Expected GradYear (my notes indicate that both of those fields were on our list of fields to be mapped to StarRez). Also, can you confirm that the Enrollment Term is the Matriculation Term as found on BANNER SGASTN screens and not the Admission Term. (2nd screen shot below) Could we then also change the heading on that field in SRWeb to “Matriculation Term” instead of “Enrollment Term”?
Are these questions for Rob or for StarRez?
A: From: Pekor, Robert J. Sent: Tuesday, June 6, 2017 2:04:11 PM
|field||Push Process||Where it comes from|
|Class||Biographic||Relates back to the SAGASTDN term-code-matric field in Banner|
|Expected-Graduation-Term||Enrollment||relates back to the SAGASTDN term-code-grad field|
|Enrollment term||Enrollment||nothing specifically called “enrollment term” in either push, but the entry term relates back to the relates SAGASTDN term-code-entry field.|
|Admission Term||Enrollment||relates SAGASTDN term-code-matric field. If the term-code-matric field is blank, it sends the SAGASTDN term-code-admit.|
Are you saying we need to change some of these?