This guide reinforces what you explored in your admin portal foundations session. Use it to review core concepts, practice essential workflows, and complete hands-on homework that builds navigation fluency.
Who this is for: Housing admins learning to navigate the Housing.Cloud admin portal for the first time.
Learning outcomes: Confidently log in, navigate between sections, find students and rooms, use tables and filters, and understand how inventory is organized.
Time to complete: 90 minutes (60 minutes for modules + 30 minutes for homework)
Core Concepts to Remember
The admin portal lives at
yourschool.housing.cloud/admin— bookmark the full URL including /adminYour sidebar shows only what your role permits — limited navigation means you need a role assigned
Quick Search (Cmd/Ctrl+K) is the fastest way to find anything — use it instead of clicking through menus
The list-to-detail pattern appears everywhere: table → click blue underlined name → detail page
Inventory follows a hierarchy: Building → Suite → Room → Bed → Furniture (like nesting dolls)
Breadcrumbs at the top show where you are and let you jump back to any level
Filters apply only to the current table — saved views let you reuse filters without rebuilding them
Profiles are all students; Applications are students who applied; Residents are students with room assignments
Module 1: Access and Admin Portal URL
Mini-Lesson
The admin portal is your command center for managing housing applications, assignments, resident communications, and operations. Unlike the student portal where applicants submit forms, the admin portal gives you tools to review applications, assign beds, track occupancy, and configure the system.
Why this matters: Many new admins accidentally land on the student portal and wonder why they can't see admin tools. The admin portal requires a specific URL format and proper authentication.
Scenario: You're setting up your workstation on your first day. You type your school's housing URL but see a student application form instead of the admin dashboard. You're missing the /admin path in the URL. The correct format is yourschool.housing.cloud/admin, not just yourschool.housing.cloud.
Key vocabulary:
Admin portal: The staff-facing interface where you manage housing operations
Student portal: The student-facing interface where applicants submit applications and view assignments
SSO (Single Sign-On): Authentication using your campus credentials instead of a separate password
SAML: The technical protocol that connects Housing.Cloud to your campus authentication system
What to remember:
Always use the full admin URL including
/admin— bookmark it to avoid mistakesSSO means no separate password; you use your campus login credentials
If SSO fails repeatedly, your IT team needs to verify your email in the SAML configuration
(268 words)
Practice
Try this in the admin portal:
Open your browser and navigate to
yourschool.housing.cloud/adminClick Sign in with SSO
Complete authentication using your campus credentials (and MFA if prompted)
Verify you land on the Dashboard with occupancy metrics and calendar
Bookmark the full admin URL in your browser for one-click access
Click your profile icon (top-right corner) to explore user settings
Toggle between Light Mode and Dark Mode to see visual themes
Log out and log back in to practice the authentication flow
Checkpoint
What happens if you navigate to
yourschool.housing.cloudwithout/admin? You land on the student portal instead of the admin portal. The/adminpath is required for staff access.Your SSO authentication succeeds but you see "You do not have a valid account." What does this mean? Your campus SSO credentials work, but you don't have a Housing.Cloud admin account yet. Contact your system owner to create your admin account.
Common Mistakes
Forgetting to include
/adminin the URL and landing on the student portal insteadExpecting immediate access after SSO works, but not realizing you also need an admin account created
Using the browser back button after SSO redirects, which can trigger infinite redirect loops (clear cookies if this happens)
Go Deeper
For comprehensive technical details, see PLS-1A: Logging In and Basic System Navigation.
Module 2: Dashboard Orientation
Mini-Lesson
After login, the Dashboard is your landing page. It provides a snapshot of current housing operations through metrics, activity feeds, and calendar views. Think of it as mission control — a high-level overview before you dive into specific sections.
Why this matters: The Dashboard adapts to your role and permissions. What you see depends on your assigned responsibilities. In a sandbox environment, the Dashboard may appear empty or show placeholder data because no real housing cycles or students exist yet.
Scenario: It's Monday morning during application season. You open the Dashboard and immediately see 47 new applications submitted over the weekend, current occupancy at 78%, and a notification that the Fall 2025 room selection window opens in 3 days. You can click directly on "47 Applications" to jump to the Applications section filtered to "Submitted" status, saving several navigation clicks.
Key vocabulary:
Overview tab: Shows operational metrics like occupancy rate, pending applications, and recent activity
Calendar tab: Displays upcoming move-in/move-out dates and housing cycle milestones
Quick actions: Contextual shortcuts to frequently-used tasks based on your role
Sandbox environment: A practice system with no real students or housing data, used for training
What to remember:
Dashboard widgets are role-dependent — your view differs from colleagues with different permissions
Empty or minimal Dashboard data in sandbox environments is normal and expected
Calendar tab shows housing cycle dates you configured in Setup, not system-wide defaults
(271 words)
Practice
Try this in the admin portal:
Click Dashboard in the sidebar (if you're not already there after login)
Identify the Overview tab and note what metrics appear (occupancy, applications, move-ins)
Click the Calendar tab and check for any scheduled housing dates
Return to the Overview tab and look for quick action shortcuts
Note which sections appear empty or sparse — this is expected in sandbox environments
Checkpoint
Why might your Dashboard look different from a colleague's Dashboard? Dashboard widgets are personalized based on assigned roles and permissions. Different roles see different metrics relevant to their responsibilities.
You see a completely empty Dashboard with no metrics. Is this a problem? Not necessarily. In a sandbox environment with no housing cycles or student data, an empty Dashboard is normal. In a production environment, contact your super admin to verify your role is assigned correctly.
Common Mistakes
Expecting detailed metrics in a sandbox environment where no housing data exists yet
Assuming Dashboard widgets are universal when they're actually role-dependent
Go Deeper
For comprehensive technical details, see PLS-1A: Logging In and Basic System Navigation.
Module 3: Global Navigation
Mini-Lesson
The navigation sidebar is how you move between different functional areas of the admin portal. It sits on the left edge of your screen and contains links to all major sections you have permission to access. Think of it as a table of contents that stays visible as you work.
Why this matters: The sidebar adapts to your role. If you only see Dashboard and Profiles after logging in, your account likely doesn't have a role assigned. Logging in successfully doesn't automatically grant permissions — your profile must have a role that specifies what you can see and do.
Scenario: You're reviewing a housing application and need to check the student's profile, verify their room assignment in Residents, and then check bed availability in Inventory. The persistent sidebar lets you jump between Applications → Profiles → Residents → Inventory without "backing out" to a home screen. You stay oriented because the sidebar always shows where you are.
Key vocabulary:
Sidebar: The navigation panel on the left showing all accessible sections
Subsections: Nested options under Inventory and Setup that expand when clicked
Active indicator: Visual highlight showing which section you're currently in
Permission-based visibility: Sidebar items appear only if your role grants access to them
Profile menu: The icon in the top-right corner for settings, help, and logout
What to remember:
Inventory and Setup contain subsections — click to expand and access specific areas
Limited sidebar visibility means you need a role assigned, not a technical problem
The sidebar groups sections logically: people first, infrastructure middle, configuration bottom
(310 words)
Practice
Try this in the admin portal:
Scan the sidebar and identify which sections appear for your role
Click Inventory and note the subsections that expand (Buildings, Rooms, Beds, etc.)
Click Setup and note those subsections (Forms, Housing Cycles, Tags, etc.)
Click Profiles to navigate to that section, then observe the active indicator highlight in the sidebar
Click your profile icon (top-right) to access user settings, help, and accessibility tools
Practice jumping between three sections: Profiles → Applications → Residents
Click Dashboard to return to your starting point
Checkpoint
You only see Dashboard and Profiles in your sidebar. What should you do? Contact your institution's Housing.Cloud super admin and request that they assign you an appropriate role. After the role is assigned, log out and log back in to see updated navigation.
How do you access the Beds section of Inventory? Click Inventory in the sidebar to expand subsections, then click Beds.
Common Mistakes
Assuming limited navigation is a bug when it's actually expected behavior for accounts without assigned roles
Missing the Inventory and Setup subsections because you didn't click to expand them
Using the browser back button instead of sidebar navigation, which can clear filters or cause unexpected navigation
Go Deeper
For comprehensive technical details, see PLS-1B: Navigating the Admin Portal.
Module 4: Quick Search
Mini-Lesson
Quick Search is the fastest way to find students, rooms, tasks, and pages without clicking through menus. Press Cmd/Ctrl+K from anywhere to open a universal search modal that searches across all resource types simultaneously. Power users navigate 2-3x faster by using Quick Search instead of manual sidebar clicking.
Why this matters: Quick Search isn't just a search tool — it's also a navigation shortcut and action launcher. You can search for a student, view their application, approve it, and assign a bed all from the Quick Search modal without ever touching the sidebar.
Scenario: A student calls asking about their housing assignment. Instead of clicking Residents → searching the table → clicking their name, you press Cmd/Ctrl+K, type "Sarah Johnson," click her name in results, and see her assignment in 3 seconds. Quick Search also shows contextual actions like "Assign Bed" or "View Profile" directly on search results.
Key vocabulary:
Cmd/Ctrl+K: The keyboard shortcut to open Quick Search from anywhere
Resource types: Categories of searchable items (profiles, residents, rooms, tasks, etc.)
Contextual actions: Actions available directly on search results based on the resource type
Navigation shortcuts: Typing section names like "forms" or "applications" to jump directly there
What to remember:
Memorize Cmd/Ctrl+K — it's the single most important keyboard shortcut in the system
Quick Search works as both a finder (search for students/rooms) and navigator (jump to sections)
Actions appear on search results, so you can approve applications or assign beds without opening detail pages
(310 words)
Practice
Try this in the admin portal:
Press Cmd+K (Mac) or Ctrl+K (Windows) from anywhere to open Quick Search
Type a student name (if any exist in your environment) and observe grouped results
Click a search result to view available actions (View Profile, Assign Bed, Add Tag, etc.)
Press Escape to close Quick Search
Open Quick Search again and type "profiles" to see the navigation shortcut appear
Press Enter to jump directly to the Profiles section
Open Quick Search and type "forms" to jump to Setup › Forms
Practice opening and closing Quick Search five times to build muscle memory
Checkpoint
What's the keyboard shortcut to open Quick Search? Cmd+K on Mac or Ctrl+K on Windows/Linux.
Besides searching for students and rooms, what else can Quick Search do? Quick Search also serves as a navigation tool — you can type section names like "applications" or "inventory" to jump directly to those sections without clicking through the sidebar.
Common Mistakes
Clicking through sidebar menus when Quick Search would be faster (use it for everything to build the habit)
Not realizing Quick Search shows contextual actions, so you unnecessarily navigate to detail pages
Forgetting the Cmd/Ctrl+K shortcut and clicking the search button instead (practice until it's automatic)
Go Deeper
For comprehensive technical details, see PLS-1C: Quick Search.
Module 5: List → Detail Navigation
Mini-Lesson
The list-to-detail pattern is the core navigation model used everywhere in Housing.Cloud. You start with a table of multiple records, click a blue underlined name to view complete details, and use breadcrumbs to navigate back. This pattern works identically for profiles, residents, applications, rooms, buildings, and all other sections.
Why this matters: Learn this pattern once and you automatically know how to navigate every section of the system. The consistent design means the skills you develop looking up a student transfer directly to looking up a room, a task, or an application.
Scenario: You need to check who lives in Room 201A. You navigate to Inventory → Rooms, search for "201A," click the blue underlined room name, and see the detail page showing current residents, furniture, condition reports, and keys. At the top, breadcrumbs show Inventory/Rooms > Room 201A. Click "Inventory/Rooms" in the breadcrumb to return to the full table without losing your search filters.
Key vocabulary:
Table view: The list showing multiple records with columns and rows
Detail page: The comprehensive view of a single record with tabs and full information
Breadcrumbs: The trail of links at the top showing your location in the hierarchy
Clickable links: Blue and underlined text indicating you can click to view details
Section tabs: Tabs on detail pages that let you jump between different areas of information
What to remember:
Blue + underlined = clickable; gray or black text = display-only
Use breadcrumbs instead of the browser back button to preserve filters and context
Detail pages show tabs near the top — click tabs instead of scrolling to jump to specific sections
(327 words)
Practice
Try this in the admin portal:
Navigate to Profiles using the sidebar
Identify blue underlined names in the table (these are clickable)
Click a student name to view their detail page
Observe the breadcrumb trail at the top (e.g.,
Profiles > Student Name)Look for section tabs on the detail page and click through them
Click the "Profiles" part of the breadcrumb to return to the table
Navigate to Inventory > Buildings
Click a building name to view its detail page
Notice the same list-to-detail pattern applies to inventory just like it did to profiles
Use breadcrumbs to return to the Buildings table
Checkpoint
How do you know if text in a table is clickable? Clickable text appears in blue with an underline. Gray or black text without underlines is display-only information.
Why should you use breadcrumbs instead of the browser back button? Breadcrumbs keep your filters and searches active, while the back button can take you to unexpected pages or clear your applied filters.
Common Mistakes
Using the browser back button and losing applied filters instead of clicking breadcrumbs
Scrolling through long detail pages instead of clicking section tabs to jump directly to specific information
Not recognizing the blue underlined text as clickable and missing opportunities to drill down
Go Deeper
For comprehensive technical details, see PLS-1F: Navigating Tables and Detail Views.
Module 6: Tables
Mini-Lesson
Tables are how Housing.Cloud displays lists of records — students, applications, rooms, tasks, or any collection of items. Every table has the same basic structure: column headers, rows of data, a search box, filter button, checkboxes for bulk selection, and action buttons. Learn how to work with one table and you automatically know how to work with all tables throughout the system.
Why this matters: Tables include powerful tools for narrowing down exactly what you need. Filters let you show only records matching specific criteria. Saved views let you reuse common filter combinations without rebuilding them. Exports respect your filters, so you can download exactly the data you need for reports.
Scenario: You need to approve all first-year housing applications submitted for Fall 2024. You navigate to Applications, click Filter, select Cycle: "Fall 2024," Status: "Submitted," and Class Year: "First-year." The table updates to show only matching applications. You save this filter combination as "Fall 2024 First-Years - Pending" so you can reuse it tomorrow with one click. You select all visible applications using the header checkbox, click Bulk Actions → Approve Applications, and approve them all at once instead of one by one.
Key vocabulary:
Filters: Criteria you apply to narrow table results (class year, status, building, etc.)
Saved views: Named filter combinations you can reuse without rebuilding them
Bulk actions: Operations you perform on multiple selected records simultaneously
Export: Download table data as a spreadsheet (CSV or Excel) respecting current filters
Column customization: Reordering, resizing, showing, or hiding columns to match your workflow
What to remember:
Filter first, then export — you'll get exactly the data you need without extra cleanup
Saved views are personal shortcuts; other admins can create their own without affecting yours
Bulk actions can't always be undone (like canceling residencies) — double-check selections before confirming
(341 words)
Practice
Try this in the admin portal:
Navigate to Profiles or Applications (whichever has data in your environment)
Click the Filter button to open the filter panel
Apply any available filter (class year, status, tags) and observe the table update
Click Save View if available, name it, and save
Clear filters to see the full table again
Select your saved view from the dropdown to reapply filters with one click
Click checkboxes next to a few table rows to select them
Observe the Bulk Actions menu appear at the top
Click the header checkbox to select all visible records
Look for an Export button and note what file formats are available
Checkpoint
You apply filters to show only first-year students, then click Export. What data downloads? Only the filtered data (first-year students) downloads. Exports respect your current filters, so you get exactly what you're viewing in the table.
What's the benefit of saved views compared to manually applying filters each time? Saved views let you apply common filter combinations with one click instead of rebuilding them every time. This saves time for frequently-used filters like "Fall 2024 First-Years - Pending."
Common Mistakes
Exporting without filtering first and getting unnecessary data that requires manual cleanup
Rebuilding the same filters repeatedly instead of saving them as a reusable view
Confirming bulk actions without double-checking selections, especially for irreversible operations
Go Deeper
For comprehensive technical details, see PLS-1E: Working with Tables, Filters, and Bulk Actions.
Module 7: People Records
Mini-Lesson
Housing.Cloud tracks students through three related but distinct concepts: Profiles, Applications, and Residencies. Think of them as nesting dolls — every student has a Profile, some Profiles have Applications for specific terms, and some Applications result in Residencies when students are assigned rooms.
Why this matters: Understanding the relationship between Profiles, Applications, and Residencies prevents confusion when searching for students. A student might appear in Profiles but not Applications (if they haven't applied yet), or in Applications but not Residents (if approved but not assigned a room).
Scenario: A parent calls asking if their student is approved for Fall 2024 housing. You search in Residents but don't find them. This doesn't mean they weren't approved — it means they haven't been assigned a room yet. You search in Applications, filter by Fall 2024, and find the student with status "Approved - Awaiting Assignment." The distinction between approved (Application) and assigned (Residency) clarifies the parent's question.
Key vocabulary:
Profile: The master student record with contact info, demographics, tags, and history — exists for every student
Application: A term-specific housing request (Fall 2024, Spring 2025) with status like Submitted, Approved, or Denied
Residency: An active or past room assignment with check-in/check-out dates, billing, and roommate details
Term-aware: Applications and Residencies are tied to specific housing cycles; Profiles are not
What to remember:
All students have Profiles; only students who applied have Applications; only assigned students have Residencies
Profiles persist across terms, but Applications and Residencies are term-specific
A student can have multiple Applications (Fall 2024, Spring 2025) and multiple Residencies (historical assignments)
(308 words)
Practice
Try this in the admin portal:
Navigate to Profiles and observe the full list of all students
Click a student name to view their detail page
Look for tabs like Applications and Residencies on the profile detail page
Navigate to Applications using the sidebar
Filter by a specific housing cycle (if available) and note how Applications are term-specific
Navigate to Residents using the sidebar
Observe that Residents shows only students with active or past room assignments
Compare the counts: Profiles (largest) → Applications (subset) → Residents (smallest subset)
Checkpoint
A student has a Profile but doesn't appear in Applications. Why? They haven't submitted a housing application for any term yet. Profiles exist for all students; Applications exist only for students who've applied.
A student has an approved Application but doesn't appear in Residents. What does this mean? They're approved for housing but haven't been assigned a room yet. Residencies are created when students are assigned beds, not when applications are approved.
Common Mistakes
Searching in Residents for students who are approved but not yet assigned, then assuming they weren't approved
Not realizing Applications and Residencies are term-specific while Profiles persist across all terms
Confusing the terms "applicant" (has an Application) and "resident" (has a Residency)
Go Deeper
For comprehensive technical details, see PLS-1B: Navigating the Admin Portal.
Module 8: Inventory Hierarchy
Mini-Lesson
Housing.Cloud organizes your housing inventory in a hierarchical structure: Building → Suite → Room → Bed → Furniture. Think of it like giving directions to a specific bed — you start broad (which building?) and get progressively more specific (which suite, which room, which bed, which piece of furniture?).
Why this matters: The hierarchy ensures precise room assignments and accurate occupancy tracking at every level. You can check availability for an entire building, a specific suite, or an individual bed. You can export furniture inventory for one building or across your entire system. Every bed has an unambiguous location.
Scenario: A student calls asking "What room am I in?" You search for the student in Residents, click their name, and see: East Hall > Suite 201 > Room 201A > Bed 1. The hierarchy makes the answer instantly clear. Later, your director asks for a furniture inventory for East Hall. You navigate to Inventory → Buildings, click "East Hall," click the Furniture tab, and click Export. Because furniture is tracked hierarchically, you get exactly the data scoped to that building.
Key vocabulary:
Building: The residence hall or housing structure (top level)
Suite: A group of rooms sharing common space (optional; not all buildings use suites)
Room: The specific room within a building or suite
Bed: The individual bed space within a room (the assignment level for students)
Furniture: Tracked items like desks, chairs, mattresses, dressers
What to remember:
Students are assigned to beds, not rooms — a room with two beds means two separate assignments
Not all buildings use suites; if yours doesn't, your hierarchy goes Building → Room → Bed → Furniture
You can navigate top-down (drill from Building → Bed) or jump directly to the level you need
(327 words)
Practice
Try this in the admin portal:
Navigate to Inventory > Buildings
Click a building name to view its detail page
Look for tabs like Suites, Rooms, or Occupancy
Click a suite name (if your building has suites) to drill down one level
Click a room name to drill down further
Observe the breadcrumb trail grow as you drill down:
Buildings > East Hall > Suite 201 > Room 201AClick any part of the breadcrumb to jump back to that level without clicking back repeatedly
Navigate to Inventory > Beds directly to skip drilling and jump straight to the bed level
Search for a specific bed or room number to practice direct navigation
Checkpoint
Your building doesn't use suites. What does your inventory hierarchy look like? Building → Room → Bed → Furniture. The system adapts to your actual inventory structure; suites are optional.
What's the advantage of navigating directly to Inventory > Beds versus drilling down from Buildings? Direct navigation saves time when you know exactly what you're looking for (a specific bed or room number). Drilling down is better for exploration and context (seeing everything in a building).
Common Mistakes
Always drilling down from Buildings when you could jump directly to Rooms or Beds for faster navigation
Using the browser back button instead of breadcrumbs to navigate up the hierarchy
Expecting all buildings to have suites when the structure adapts to your actual inventory
Go Deeper
For comprehensive technical details, see PLS-1G: Understanding Inventory Hierarchy.
Practice Drills (10 minutes)
Complete these three drills to reinforce what you've learned. Each drill combines multiple concepts from the modules.
Drill 1: Quick Search Speed Test
Press Cmd/Ctrl+K to open Quick Search
Type "profiles" and press Enter to jump to that section
Press Cmd/Ctrl+K again
Type "forms" and press Enter to jump to Setup › Forms
Press Cmd/Ctrl+K again
Type a student name (if any exist) and observe search results
Press Escape to close without selecting anything
Repeat this sequence three times to build muscle memory
What this tests: Quick Search keyboard shortcut, navigation shortcuts, and resource search.
Drill 2: Saved View Creation
Navigate to Applications or Profiles (whichever has data in your environment)
Click the Filter button
Apply 2-3 filters (class year, status, tags, or any available options)
Observe the table update to show only matching records
Click Save View and name it descriptively (e.g., "First-Years - Pending Approval")
Clear all filters to see the full table
Select your saved view from the dropdown
Verify the filters reapply instantly without rebuilding them
What this tests: Table filters, saved views, and filter reusability.
Drill 3: Inventory Drill-Down
Navigate to Inventory > Buildings
Click a building name to view its detail page
Drill down through the hierarchy: click a suite (if available) → click a room → click a bed
Observe the breadcrumb trail showing your full path
Click the building name in the breadcrumb to jump back to the top level
Navigate to Inventory > Rooms directly
Search for a specific room number
Click the room name and compare: drilling down vs. direct navigation
What this tests: Inventory hierarchy navigation, breadcrumb usage, and direct vs. drill-down approaches.
Homework (30-45 minutes)
Complete these tasks in your sandbox environment to validate your navigation fluency and data understanding. Submit your findings using the format below.
Task 1: Navigation Fluency Test
Using only Quick Search (Cmd/Ctrl+K) and no sidebar clicking, navigate to the following sections in this order and record the exact text you typed:
Applications section
Setup › Housing Cycles
Inventory › Beds
Profiles section
Setup › Forms
What to submit: The exact search terms you used for each section (e.g., "applications," "cycles," "beds").
Task 2: Saved View Creation and URL Validation
Navigate to Applications or Profiles (whichever has data)
Create a saved view with at least 2 filters applied
Name it descriptively
Copy the full browser URL while the saved view is active
Clear all filters and verify the table shows unfiltered data
Reapply your saved view and verify the URL changes
What to submit:
The name of your saved view
The filters you applied
The full URL with the saved view active
Task 3: Inventory Hierarchy Verification
Navigate to Inventory › Buildings
Select one building and drill down as far as the hierarchy allows (Building → Suite → Room → Bed or Building → Room → Bed)
At the deepest level (a bed detail page), copy the breadcrumb trail
Click the building name in the breadcrumb and verify you jump back to the building detail page
Navigate to Inventory › Beds directly
Search for the same bed you just viewed via drilling
Compare the two approaches: drilling vs. direct navigation
What to submit:
The full breadcrumb trail from the deepest level you reached
A one-sentence explanation of when you'd use drilling vs. direct navigation
Task 4: People Records Verification
Count the total number of records in Profiles
Count the total number of records in Applications (if any exist)
Count the total number of records in Residents (if any exist)
Explain the relationship: why the counts differ and what each section represents
What to submit:
Profile count: [number]
Application count: [number]
Resident count: [number]
Two-sentence explanation of why the numbers differ
Task 5: Screenshot and Question
Navigate to any detail page (a student profile, a room, a building, or an application)
Take a screenshot showing the breadcrumb trail, section tabs, and at least one piece of detail information
Formulate one specific question about something you're uncertain about or want clarification on
What to submit:
Your screenshot (upload or paste into submission)
One specific question about navigation, data structure, or functionality
Submission Requirements
Done means:
You successfully navigated to all five sections in Task 1 using only Quick Search
You created and applied a saved view with the URL documented in Task 2
You recorded a breadcrumb trail and explained drilling vs. direct navigation in Task 3
You documented Profile, Application, and Resident counts with an explanation in Task 4
You submitted a screenshot and one question in Task 5
All tasks completed in your sandbox environment (not production)
Go Deeper
For comprehensive technical details on each module topic, see the master PLS-1 articles: