PLS-6A: Basic Cycle Settings & Applicability

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

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 /residency

• Application, 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 /nonresident

• Application status and cycle information only

• Documents to sign (if assigned)

• Meal plans (if applicable)

• No roommate finder, no room selection, no move-in scheduling

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

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.

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

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

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

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

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:

1. Create test student profiles with different tag combinations

2. Log in as each test student (or have colleagues test using impersonation)

3. Verify which students can see the cycle in their portal

4. Adjust tags if needed before activating

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:

1. Review all fields: Ensure required fields (name, residence dates) are completed

2. Verify tag logic: Double-check your applicability and exclusion tags

3. Confirm term code: If included, verify it matches your SIS exactly

4. Click "Save" or navigate to the next tab (settings auto-save in the wizard)

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

Continue to PLS-6B →