Overview
In this module, you'll learn how to create a new housing cycle and configure the foundational settings that determine who can access it, when housing takes place, and how the cycle connects to your institution's broader systems.
What you'll learn:
How to create a new resident or non-resident cycle
How to configure cycle name, dates, and external codes
How applicability tags control who can see and access your cycle
How to set visibility and access requirements
Time: 10 minutes
Remember the Building Block Approach: Cycles are containers that organize your entire housing operation. In PLS-6A, you're creating the container itself and defining who can access it. In later modules, you'll add the components—forms, rulesets, phases—that power the housing process inside this cycle.
Creating a New Housing Cycle
Housing cycles are created from the Setup section of the admin portal.
Navigation
Path: Admin › Setup › Cycles
From the Cycles list page, you'll see a button labeled "New Housing Cycle" or a dropdown menu (if non-resident cycles are enabled at your institution).
Cycle Type Options
When creating a new cycle, you may see these options:
Resident Cycle - Complete housing cycle for on-campus students with room assignment, roommate matching, and move management
Non-Resident Cycle - Application-only cycle for housing-related services without room assignment (requires NON_RESIDENT_CYCLES feature)
Copy Cycle - Duplicate an existing cycle to quickly create next term's cycle (requires CYCLE_COPY feature)
Feature Availability: If you only see "New Housing Cycle" without a dropdown menu, your institution only has resident cycles enabled. This is the most common configuration.
Understanding Resident vs. Non-Resident Cycles
Before creating your cycle, it's important to understand the fundamental difference between these two cycle types. Both types organize housing-related activity, but they serve different populations and purposes.
Resident Cycles: Complete On-Campus Housing
Use resident cycles when: Students will be assigned to specific rooms and beds and you need to manage the complete on-campus housing experience.
Resident cycles connect:
Applications, assignments, and billing under one framework
Roommate matching and room selection workflows
Move-in and move-out scheduling and logistics
Room condition reports and swap functionality
Meal plan selection and fee management
Integration with SIS for occupancy and transactions
Examples of resident cycles:
Fall 2025 Returning Students
Spring 2026 New Students
Summer 2025 Session Housing
Academic Year Graduate Housing
Required configuration: Resident cycles MUST have a ruleset assigned. Rulesets define the matching logic for roommate compatibility and room assignment rules.
Non-Resident Cycles: Services Without Room Assignment
Use non-resident cycles when: Students or groups need housing-related services but won't be assigned to specific rooms. This might include commuter students purchasing meal plans, faculty receiving temporary meal access, or programs requiring fee management without physical assignments.
Non-resident cycles support:
Application submission and approval workflows
Document signing (contracts, waivers, agreements)
Meal plan selection and billing
Fee collection tied to services
Eligibility tracking for programs
Non-resident cycles do NOT include:
Room or bed assignment
Roommate matching
Room selection or browsing
Move-in/move-out logistics
Room condition reports
Lottery systems
Examples of non-resident cycles:
Fall 2025 Commuter Meal Plans
Staff Housing Services Registration
Waitlist Management (students awaiting housing availability)
Summer Conference Meal Access
Configuration difference: Non-resident cycles do NOT require a ruleset because there's no room assignment or matching logic needed.
Student Experience Differences
Resident cycle students see:
Full housing portal at
/residencyApplication, roommate finder, room selection, meal plans, documents
Move-in scheduling, room details, roommate profiles
Action items for each phase of the housing journey
Non-resident cycle students see:
Simplified portal at
/nonresidentApplication status and cycle information only
Documents to sign (if assigned)
Meal plans (if applicable)
No roommate finder, no room selection, no move-in scheduling
Choosing the Right Cycle Type: Ask yourself: "Will students be assigned to a specific room or bed?" If yes, use a resident cycle. If students just need approval to participate in a program or access services without room assignment, use a non-resident cycle.
When to Use Multiple Cycle Types
Many institutions run both resident and non-resident cycles simultaneously to manage different populations:
Example institution setup:
Resident Cycle: "Fall 2025 On-Campus Housing" (for students living in residence halls)
Non-Resident Cycle: "Fall 2025 Commuter Meal Plans" (for commuter students who need dining access)
Non-Resident Cycle: "Fall 2025 Housing Waitlist" (for students awaiting housing availability)
Using applicability and exclusion tags ensures students only see the cycles relevant to them, keeping each population's experience clear and focused.
Feature Gate Required: Non-resident cycles require the NON_RESIDENT_CYCLES feature to be enabled. If you don't see this option in your menu, contact support to request the feature.
Starting a New Resident Cycle
Click "New Housing Cycle" (or select "Resident Cycle" from the dropdown). This opens the cycle creation wizard.
The wizard guides you through all configuration tabs step-by-step. You can also navigate directly to any tab to configure settings in any order.
The General Tab: Basic Cycle Settings
The General tab contains the foundational settings for your housing cycle. These settings establish the cycle's identity, define the housing period, and control who can access it.
Cycle Name (Required)
Field: Name
This is the official internal name for your cycle. It appears in admin lists, reports, and system references.
Best practices:
Use a clear naming convention:
[Term] [Year] - [Population]Examples: "Fall 2025 - Returning Students," "Spring 2026 - New Students," "Summer 2025 - All Students"
Include the year to distinguish between recurring terms
Keep it concise—this name appears in dropdown menus throughout the system
Cannot Edit Once Active: The cycle name locks when the cycle becomes active. Choose carefully before setting phase dates that will activate your cycle.
Display Name on Resident Portal
Field: Display Name on Resident Portal
This is the student-facing name that appears in the resident portal. It can be more descriptive or welcoming than the internal name.
Examples:
Internal name: "Fall 2025 - Returning" → Display name: "Fall 2025 Returning Student Housing"
Internal name: "Spring 2026 - New" → Display name: "Spring Semester 2026 Housing Application"
Internal name: "Summer 2025" → Display name: "Summer Session Housing 2025"
When to use a different display name:
Add context students need: "First-Year Housing Fall 2025"
Clarify the housing type: "Graduate Student Housing Spring 2026"
Make it welcoming: "Your Fall 2025 Housing Application"
Student Perspective: The display name is what students see when selecting which cycle to apply to. Make it clear and descriptive so they choose the correct cycle if you're running multiple concurrent cycles.
Residence Start and End Dates (Required)
Fields: Residence Start Date | Residence End Date
These dates define the residence period—the contractual housing timeframe when students actually live in housing. This is one of the most important concepts in cycle configuration.
Critical Distinction: Cycle Dates vs. Phase Dates Cycle dates (Residence Start/End) define the housing period—when students live on campus. Phase dates define activity windows—when students can apply, select rooms, form roommate groups, etc. Phase dates typically occur months before the residence period begins. Students apply in March for housing that starts in August.
Example timeline:
Residence Start: August 15, 2025 (when students move in)
Residence End: May 15, 2026 (when students move out)
Application Phase: March 1 - April 15, 2025 (5 months before residence starts)
Room Selection Phase: May 1 - May 15, 2025 (3 months before residence starts)
What residence dates control:
The contractual period for housing agreements
When billing transactions should begin
When check-in can occur
When students are considered "current residents"
Reporting scope for occupancy and assignments
Cannot Edit Once Active: Residence start and end dates lock when the cycle becomes active. Plan carefully before activating your cycle.
External Term Code
Field: External Term Code
This code connects your housing cycle to your Student Information System (SIS) term structure. When included, it tells both Housing.Cloud and your SIS how to categorize assignments, meal plans, and billing for this housing period.
Common SIS term code formats:
Banner: "202510" (Fall 2025), "202520" (Spring 2026), "202530" (Summer 2026)
Colleague: "2025FA," "2026SP," "2026SU"
PeopleSoft: "2251," "2262," "2263"
How to find your term code:
Check with your Registrar or SIS administrator
Review existing term codes in your SIS
Follow your institution's established term code convention
Critical for Integration: If this code doesn't match your SIS exactly, billing transactions may not sync correctly. Always verify with your SIS or integration team before saving.
When to Include a Term Code
Include a term code when:
The cycle manages standard academic housing (Fall, Spring, Summer)
Billing and transactions should sync to your SIS automatically
The housing period aligns with an institutional academic term
You need housing data categorized under a specific term for reporting
When to Leave Term Code Blank
Leave the term code blank when:
Managing short-term programs outside the academic calendar (camps, conferences)
Housing activity shouldn't post to institutional term-based records
Your IT or finance team will handle billing manually or through separate processes
The cycle operates independently of academic term structures
Integration Behavior: Housing.Cloud will always generate and send housing data when an integration is active. However, the presence of a term code determines how (or if) your SIS processes that data. Cycles without term codes may require manual export or custom handling by your IT team. If your institution uses Ellucian Ethos, term codes are required—Ethos enforces strict alignment with academic term structures and will not accept data without a valid term code.
Applicability Tags: Controlling Who Can Access Your Cycle
Applicability tags act as the gatekeeper for your housing cycle. They determine which students can see the cycle in their portal and submit applications. This is how you ensure first-years only see first-year cycles, or commuters only see commuter meal plan cycles.
You configure applicability using three types of tag logic that work together:
Applicability Tags (And)
Logic: Students must have ALL of these tags to access the cycle.
Use when: You need students to meet multiple criteria simultaneously.
Example 1: First-Year Only Housing
Add tag: "First-Year"
Result: Only students tagged as first-years can see this cycle
Example 2: International First-Years
Add tags: "First-Year" AND "International Student"
Result: Students must have both tags to access the cycle
Applicability Tags (Or)
Logic: Students need AT LEAST ONE of these tags to access the cycle.
Use when: Multiple different student populations should access the same cycle.
Example 1: Upperclassmen Housing
Add tags: "Sophomore" OR "Junior" OR "Senior"
Result: Any student with one of these class year tags can access the cycle
Example 2: Priority Populations
Add tags: "Student-Athlete" OR "Honors Program" OR "Medical Accommodation"
Result: Students with any of these tags qualify for this priority housing cycle
Excluded Tags
Logic: Students with ANY of these tags are blocked from the cycle, even if they meet applicability requirements.
Use when: You need to explicitly prevent certain populations from accessing housing.
Example 1: Exclude Commuters from Residential Housing
Add tag: "Commuter"
Result: Even if a student meets applicability criteria, having the "Commuter" tag blocks access
Example 2: Exclude Students with Disciplinary Holds
Add tags: "Housing Suspended" OR "Disciplinary Hold"
Result: Students with either tag cannot access housing regardless of other qualifications
Common Mistake: Forgetting to exclude commuter students from on-campus housing cycles. Always review your exclusion tags to ensure you're not accidentally showing housing to students who shouldn't apply.
Combining Tag Logic
You can use all three types together for precise control over cycle access:
Example: Graduate Student Housing
And: "Graduate Student"
Or: "Full-Time" OR "Part-Time with Housing Approval"
Exclude: "Commuter" OR "Off-Campus Program"
Result: Graduate students who are either full-time OR part-time with approval can access the cycle, UNLESS they're tagged as commuters or in off-campus programs.
Testing Your Tag Logic
Before activating your cycle, verify your tag logic works correctly:
Create test student profiles with different tag combinations
Log in as each test student (or have colleagues test using impersonation)
Verify which students can see the cycle in their portal
Adjust tags if needed before activating
Tag Strategy: Create a spreadsheet mapping your student populations to tag requirements before configuring cycles. This helps you visualize which students should access which cycles and catch overlaps or gaps early.
Additional Settings
Require Link to Apply
Toggle: Require Link to Apply
When enabled, the cycle does NOT appear in the public cycle list. Students can only access it via a direct link.
Use when:
Running a special or invite-only housing process
Testing a cycle before public launch
Managing housing for specific cohorts privately
Behavior:
Enabled: Cycle is hidden from the main list; students need the direct URL
Disabled: Cycle appears in the portal for all students who meet applicability tag requirements
Allow Room Browsing for Non-Approved Applications
Toggle: Allow Room Browsing for Non-Approved Applications
Controls whether students can browse available rooms before their application is approved.
Behavior:
Enabled: Students can preview rooms immediately after applying, even while "Under Review"
Disabled: Students must wait for application approval before browsing inventory
When to enable:
You want to build excitement and transparency by showing available inventory early
Your approval process is automatic and you want students exploring options immediately
When to disable:
You manually review and may reject applications; you don't want rejected students browsing rooms
Inventory isn't finalized and you don't want to show incomplete room lists
Saving Your General Settings
After configuring the General tab:
Review all fields: Ensure required fields (name, residence dates) are completed
Verify tag logic: Double-check your applicability and exclusion tags
Confirm term code: If included, verify it matches your SIS exactly
Click "Save" or navigate to the next tab (settings auto-save in the wizard)
Foundation Complete: With the General tab configured, you've created the cycle container and defined who can access it. Next, you'll configure how students apply for housing and start adding the components that power your housing process.
Key Takeaways
Cycles are containers that organize applications, assignments, billing, and move management under one framework
The General tab establishes cycle identity, the housing period, and eligibility rules
Cycle name and residence dates lock when the cycle becomes active
Residence dates define when students live in housing; phase dates define when they can take actions
External term codes connect cycles to your SIS for billing integration
Applicability tags use And/Or/Exclude logic to control who can access the cycle
"And" requires all tags, "Or" requires at least one, "Exclude" blocks access
Always test your tag logic with sample students before activating
"Require Link to Apply" hides the cycle from public listing
Common Questions
Can I change the cycle name after it's created?
Yes, but only until the cycle becomes active. Once any phase starts, the name locks. Choose carefully before activating.
What's the difference between residence dates and phase dates?
Residence dates define the housing period (when students live on campus). Phase dates define activity windows (when students can apply, select rooms, etc.). Phase dates typically occur months before the residence period begins.
What happens if I don't set an external term code?
Housing.Cloud will still generate housing data, but it may not sync to your SIS automatically. Your IT team will need to decide how to handle that data. If you use Ellucian Ethos, term codes are required for data to sync.
Can one student be eligible for multiple cycles?
Yes, if their tags meet the applicability requirements for multiple cycles. Use exclusion tags carefully to prevent unintended overlap and ensure students only see relevant cycles.
What if I use "And" and "Or" tags together?
Students must have ALL "And" tags AND at least ONE "Or" tag to access the cycle. Example: ("Graduate Student" AND "Full-Time") allows full-time graduate students to access the cycle.
Can I create cycles without a term code?
Yes. Cycles without term codes are useful for short-term programs, conferences, or specialized housing that operates outside your academic calendar. Just coordinate with your IT team on how to handle billing and data export.
What's Next: PLS-6B
Now that you've configured basic cycle settings and applicability, you're ready to set up how students apply for housing.
In PLS-6B: Application Phase Configuration, you'll learn:
How to set application phase dates
How to assign YOUR application form (from PLS-5)
How to assign YOUR ruleset (from PLS-4)
How to configure auto-accept and application limits