For CoC Administrators

What Problem Does This Solve?

Right now, when an outreach worker needs to place a family in emergency shelter, they make serial phone calls. They call shelters that may be closed, full, or unable to serve that family's needs. There is no shared, real-time system for bed availability in most US communities.

Finding A Bed Tonight gives your outreach workers a live view of every shelter bed in your CoC. Coordinators update their bed counts through a simple dashboard. Workers search, filter, and place a temporary hold on a bed in under a minute. You, as the CoC administrator, see the whole picture: which shelters are full, where demand exceeds supply, and what your community's unmet need looks like over time.

What Can You Do Right Now?

HUD Reporting

The analytics module includes HIC/PIT data export aligned with the HUD Inventory.csv schema (FY2024+).

HIC export columns: InventoryID, ProjectID, CoCCode, HouseholdType, Availability, UnitInventory, BedInventory, veteran bed breakdown, ESBedType, InventoryStartDate, InventoryEndDate. All coded fields use HUD integer values.

DV shelters: Aggregated in both exports per HUD guidance. Suppressed entirely if fewer than 3 DV shelters exist (small-cell protection). DV shelters report HMISParticipation=2 (Comparable Database).

Important clarification: The export is designed to support HUD reporting requirements. It has not been certified by HUD. You should review exported data against your existing submission process before relying on it as your sole source.

How to Onboard a New Shelter

A typical onboarding takes about 7 days:

Day 1-2: Setup

1. Create the shelter profile in the admin panel -- or bulk-import from a 211 CSV file (Admin → Imports → 2-1-1 Import)
2. Review imported data and edit any details that need correction via the Edit link on the Shelters tab
3. If your CoC will operate any DV shelters, first enable DV shelter operations at the CoC level (Admin → Settings → DV Shelter Operations); without this, the per-shelter DV toggle is rejected. This step acknowledges that the CoC has the necessary review processes and trained staff in place to manage DV shelters responsibly. The change is auditable and takes effect immediately.
4. If the shelter serves DV survivors, enable the DV Shelter toggle on the shelter -- this activates address redaction and audit logging
5. Create a coordinator user account for the shelter's point person
6. Assign the coordinator to the shelter

Day 3-4: Verification

1. The coordinator logs in and verifies the shelter information is correct
2. They make their first bed count update to confirm the flow works
3. You review the data on your admin dashboard to confirm it appears correctly

Day 5-7: Go Live

1. The shelter begins regular updates (2-4 times per day recommended)
2. Outreach workers can now see the shelter's availability in search results

No developer is needed for any of these steps. The entire process is done through the admin interface.

DV Shelter Protection

What the system stores about a DV shelter

For DV shelters specifically:

• The shelter exists (name, general service area, population types)
• Current bed availability (number only)
• No client names. No client information of any kind. Zero PII.
• The shelter's physical address is never stored in the system.

How referrals work

DV shelters are invisible in public search results. An outreach worker cannot see them unless they use the opaque referral flow:

1. The outreach worker requests a referral (no client name entered)
2. The DV shelter coordinator receives the request and screens it
3. If accepted, the coordinator calls the outreach worker directly (warm handoff)
4. The shelter address is shared verbally, never through the platform

Referral tokens are hard-deleted within 24 hours. Not archived. Not soft-deleted. Permanently destroyed.

Legal framing

The DV protection architecture is designed to support VAWA and FVPSA requirements. It has not been independently certified as compliant. The zero-PII, zero-address, 24-hour hard-delete design means there is effectively nothing to subpoena -- the data does not exist.

DV Shelter Operations — CoC-level acknowledgement (v0.56+)

Before any shelter in your CoC can be flipped to dvShelter=true, the CoC itself must acknowledge that it operates DV-shelter infrastructure. This is a one-time tenant-level acknowledgement, not a per-shelter setting.

Where to find it

Admin → Settings → DV Shelter Operations panel (sits adjacent to the Bed Hold Duration panel). The panel shows the current state and a toggle. Flipping the toggle opens an extra-confirm modal that describes what the change means before it commits.

Why this exists

The existing per-shelter dvShelter flag triggers DV protections (address redaction, restricted access, audit-suppressed referrals). All those protections presuppose that the CoC has the necessary review processes and trained staff in place. The CoC-level acknowledgement makes that presupposition explicit and auditable. Without this acknowledgement, the per-shelter DV toggle is rejected at the API boundary with a clear error directing the operator here.

How to use it

1. If your CoC is migrating from v0.55 with existing DV shelters, the flag has been auto-enabled by the V97 migration -- no action needed.
2. For a new CoC: enable DV shelter operations before creating any DV shelter. The order matters; reversing it produces an actionable error message.
3. To disable: every active DV shelter must first be deactivated. The system reports the count of remaining DV shelters in the rejection if disable is attempted while DV shelters exist; the error includes a link to the filtered Shelters tab so you can identify them. Re-enabling is unrestricted.

Permissions

Both COC_ADMIN role and dvAccess=true on the user account are required to flip this flag. The two together represent "trained operator authorized to manage DV-shelter posture." Platform Operators do not have this capability by default; the operational responsibility sits with the CoC.

Audit trail

Every flag change emits a TENANT_CONFIG_UPDATED audit row. So does every rejected disable attempt -- the attempt itself is forensically interesting. Cross-tenant probe attempts (a CoC admin from tenant A trying to flip tenant B's flag) emit a defense-in-depth audit row and surface as a 403 with no inventory leak.

Reentry-Mode Tenant Flag (v0.55+)

v0.55 introduces optional support for transitional and reentry shelters serving people returning from incarceration or other institutional settings. This work is opt-in. Your CoC sees the v0.54 platform until you choose to flip the reentryMode tenant flag.

What enabling reentryMode does

Flipping the flag unlocks two surfaces. First, the eligibility-criteria editor on the shelter form, which lets coordinators of REENTRY_TRANSITIONAL-typed shelters document criminal-record policy, program requirements, documentation needed, and intake hours. Second, optional client-attribution fields on the bed-hold dialog: client name, date of birth, and notes. These fields are encrypted at rest with a per-tenant key, and they appear in the dialog and in API responses only when the reentryMode flag is set on the requesting session. The DV referral flow is a separate code path and does not collect or display these fields.

Default off; CoC admin controls the flip

Every tenant ships with features.reentryMode = false. As a CoC admin you enable it yourself via the Admin panel (Tenants → Settings). No developer is needed. Flipping the flag does not auto-enable PII collection on any specific hold -- a navigator still chooses whether to enter optional fields when placing each hold.

Privacy posture for hold-attribution PII

When a navigator records optional client name, date of birth, or notes, those values are encrypted at rest with a tenant-scoped data encryption key. Read access is gated at the API serialization layer by the same reentryMode flag, carried as a claim on the user's JWT session; the claim is refreshed at most every 60 seconds and naturally rotates with the 15-minute JWT TTL, so a flag flip propagates to readers within at most 15 minutes. Encrypted PII is erased no later than 25 hours after the hold ends. The 25-hour SLA is currently unmonitored -- see the compliance posture matrix for the honest disclosure of this gap.

For the operator-facing walkthrough -- with screenshots and end-to-end navigator flow -- see the reentry story page. For the configuration runbook see the reentry mode user guide. For pilot CoC inquiries or to request a deployment-readiness conversation about reentry-mode (or any feature on this page), the project team contact is in the section below.

Pilot CoC Inquiries

Open to conversations with Continua of Care evaluating a pilot deployment. The project team can walk through deployment-tier sizing (lite / standard / full), the operator runbook, and what an initial deployment-readiness conversation looks like for your CoC. There is no fixed pilot program -- each conversation starts from your CoC's specific operational context.

For pilot CoC inquiries, contact the FABT project team:

HMIS Connectivity

Deployment Cost

Your Checklist Before Bringing This to Partner Agencies