Practice Environment Provisioning Guide
Last updated: October 5, 2026
Think of your practice environment as a dress rehearsal. You're building a working model of one term's housing operation — real students, real buildings, real charges — to learn the product, train staff, and validate your data before anything goes live. This guide is for the housing administrators preparing that data; the technical steps (single sign-on, secure file submission) you'll handle with your Integrations Specialist. Plan on one to four hours, depending on how clean your data is.
This work isn't throwaway. The CSV files you build here become your template for importing historical housing data into production later — the same schemas, the same process. Get them right once and Housing.Cloud becomes your long-term record keeper.
One Term, Not Your Whole Database
Instead of exporting everything, you'll create a snapshot of one representative term. Files stay manageable, the data mirrors real operations, and you build the foundation for importing years of history later. Choose your current or upcoming term — a completed term can't generate export files or support test cases, so it isn't an option here. Pick whichever gives you the most typical occupancy.
Scope note: focus on traditional student housing for this first pass. Staff apartments, temporary placements, and other non-standard arrangements are easier to configure directly in the product afterward.
What Carries Over
The schema template imports your structured records — residents, spaces, assignments, and charges. It doesn't recreate your previous system line for line; anything narrative is rebuilt on your new terms rather than imported wholesale.
Comes forward:
- Current residents and eligible students
- Spaces — buildings, rooms, beds
- Completed assignments and charge codes (your rate list)
- Any term you choose to bring in later via the historical-import process
Doesn't come across:
- Past application responses — rebuilt on your new forms
- Message history — previously sent emails and texts aren't stored
- System and historical logs
- Notes or documents previously attached to a profile
- Multi-year history from your previous system, wholesale
Admins can still upload important attachments or notes per profile directly in the product. If a specific field matters to you, ask your Implementation Manager before go-live.
The Files
You'll prepare four required CSVs, plus meal plans if dining is in scope. Each is one piece of your operation — name them clearly (profiles.csv) and save as UTF-8.
The one hard rule: your columns must match Housing.Cloud's schemas exactly — names, formats, required fields. You know your data best; mapping it to the right columns is your part, and it's what makes the import land accurately. Full column-by-column schemas are linked from each section below.
profiles.csv (required)
Your student roster for the term — who is in, or could be in, housing? Include every active, housing-eligible student (commuters who may need meal plans count), not just students with an assignment. Source: your SIS (Banner, PeopleSoft, Colleague), usually via a query or extract tool.
| Field | What you know it as | Example | Required? |
|---|---|---|---|
sisId |
Student ID (Banner PIDM, EMPLID…) | 12345678 | Yes |
name |
Full student name | Jane Doe | Yes |
schoolEmail |
University email | jane.doe@school.edu | Yes* |
dob |
Date of birth | 2004-08-15 | Recommended |
*Or personalEmail. The sisId connects students across every file, so keep it consistent. Dates in yyyy-mm-dd. Full schema: CSV Integration Schema: Profiles.
inventory.csv (required)
Your physical stock — every building, room, and bed available for the term. One row per bed: a double room is two rows, Bed A and Bed B. Use current building names, and keep every building/room/bed combination unique. Source: whatever is most accurate — your housing system, facilities database, or the spreadsheet you actually maintain.
| Field | What you know it as | Example | Required? |
|---|---|---|---|
building |
Building name or code | Johnson Hall | Yes |
floor |
Floor number or level | 2 | Common |
suite |
Suite identifier | 2A | Suite-style only |
room |
Room number | 201 | Yes |
bed |
Bed identifier | A | Yes |
roomType |
Room configuration | Double Room | Yes |
roomCapacity |
Max capacity of the room | 3 | Yes |
bedType |
Bed type for billing | Double Bed | Yes |
bedCostCode |
Reference to your charge code | DBL-STANDARD | No |
Capacity example: "3" if a double can flex as a triple. Full schema: CSV Integration Schema: Inventory.
charge-codes.csv (required)
What you charge — every housing and meal-plan rate that applied during the term. The price list, not transactions. Source: your billing system, published rate sheet, or the spreadsheet where rates live.
| Field | What you know it as | Example | Required? |
|---|---|---|---|
accountingCode |
Unique billing code | DBL-STANDARD | Yes |
name |
Charge description | Double Room - Standard | Yes |
defaultAmount |
Standard rate | 4500.00 | Yes |
accountingCode must exactly match bedCostCode in inventory — that link prices your rooms. Full schema: CSV Integration Schema: Charge Codes.
occupancies.csv (required)
The heart of the data — who was assigned to which bed, from move-in to move-out. Include every assignment active inside your term boundaries; if a student moved rooms, each assignment period is its own row. Source: your housing system, SIS housing module, or assignment tracking sheets.
| Field | What you know it as | Example | Required? |
|---|---|---|---|
sisId |
Student ID — must match profiles | 12345678 | Yes |
schoolEmail |
Student email — must match profiles | jane.doe@school.edu | Yes |
building |
Building — must match inventory | Johnson Hall | Yes |
room |
Room — must match inventory | 201 | Yes |
bed |
Bed — must match inventory | A | Yes |
dateStart |
Move-in date | 2026-08-15 | Yes |
dateEnd |
Move-out date | 2026-12-15 | Yes |
dateAssigned |
When the assignment was made | 2026-07-01 | Yes |
status |
Assignment outcome | assigned | No |
Status values: assigned (completed normally) · terminated (ended early, moved out) · canceled (canceled before move-in) · prorated (adjusted billing).
Dates in yyyy-mm-dd (GMT/UTC), start before end; only include assignments whose dates fall inside your term boundaries. Full schema: CSV Integration Schema: Occupancy.
meal-plans.csv & meal-plan-assignments.csv (if dining is in scope)
Required when dining is in scope — skip entirely if not. These are the plan definitions and which students held which plan during the term.
Full schema: CSV Integration Schema: Meal Plans
Six Steps, Start to Submitted
- Choose your term. Current or upcoming, typical occupancy — and write down its start and end dates. You'll filter everything else by them.
-
Extract from your SIS. Work with your SIS admin or IT. Banner: SQL or ODS extracts (make sure the PIDM comes along — it's your
sisId). PeopleSoft: PS Query. Colleague: UI exports or custom reports. Ask for data filtered to your term dates. -
Map your fields to the schemas. Your systems use different names — PIDM →
sisId, BLDG_CODE →building, BIRTH_DATE →dob. Write the mapping down; it becomes your reference for every future import. - Build the CSVs. Profiles first, then inventory (one row per bed), charge codes, then occupancies linking the two. Excel, Google Sheets, or your export tool — saved as UTF-8 CSV.
-
Validate. No duplicate
sisIds in profiles; no duplicate building/room/bed in inventory; every occupancy points to a real student and a real bed; dates formatted and ordered; required columns filled. Watch for stray spaces and capitalization — "Johnson Hall " won't match "Johnson Hall". - Submit. Send the CSVs (and your SAML metadata, via IT) to your Implementation Manager over your normal secure channel — encrypted email, an upload to Sero, or SFTP. We review, flag anything off with specific guidance, set up your environment, and walk through the data together during product learning.
If we need to touch your data again. Once your practice environment is live, any re-import or overwrite of loaded data is proposed to your day-to-day contact in Sero at least two business days in advance, with what's changing and why — we never re-import over configured data without your sign-off.
Later: Historical Imports
Once you've mastered one term, the identical schemas bring your whole history into production: create a Cycle per historical term (Fall 2023, Spring 2024…), prepare each term's CSVs the same way, and import oldest-first. Years of housing data, searchable in one system.
Common Questions
How much data should I include?
All traditional student housing assignments from your chosen term — whether that's 200 students or 2,000. The term sets the sample size, which keeps the test realistic.
My SIS doesn't have a field called "sisId."
Every SIS has a unique student identifier — Banner's PIDM, PeopleSoft's EMPLID, Colleague's PERSON_ID. Whatever yours calls it, that becomes your sisId.
Do I include students who applied but were never assigned?
Yes — profiles should cover your active, housing-eligible population, not just students with an assignment. Every potential applicant gets a Profile anyway, so including them makes testing more realistic.
My students share emails — siblings, recycled usernames.
Emails must be unique across profiles. Email is a login identifier and single sign-on key, so two students on one address will collide — resolve these before submitting.
Building names changed over the years. Which do I use?
Today's names, always. Your inventory reflects the campus as it is now.
Should I include staff apartments or temporary housing?
Include them in inventory if they're part of your term-based assignment process; otherwise configure them in the product afterward.
Can I update the data after my environment is set up?
Yes — add or correct data through the Admin interface any time. Before you move to production, we'll ask for one refreshed import so the live system starts accurate.
Stuck on a specific file? Post it in Sero tagged to your Integrations Specialist — rough beats late, and we shape data together all the time.