
Coordinated entry is the CoC-wide process for how people experiencing or at risk of homelessness access the system, get assessed with a standard tool, and are prioritized and referred to housing and services using consistent standards, no matter which door they enter through. It is a federal requirement. 24 CFR 578.7(a)(8) directs every Continuum of Care to "establish and operate either a centralized or coordinated assessment system that provides an initial, comprehensive assessment of the needs of individuals and families for housing and services."
Read that requirement again and notice the noun. Assessment. That one word shapes every coordinated entry system in the country, and it explains much of why your case managers still keep a spreadsheet.
What HUD Asks You to Record
HUD names four core components of coordinated entry, and its guidance is precise about what the data standards do with them. The coordinated entry data elements "standardize data collection on core components of CE – access, assessment, referral, and prioritization," per HUD Exchange. The verb is collection.
HUD lists those components in that order. The working sequence runs access, assessment, prioritization, referral, because a referral cannot be decided before a priority is, and that is the order this article and the table below follow.
In the FY 2026 HMIS Data Standards Manual, all four are carried by two client-level elements. 4.19 Coordinated Entry Assessment holds an assessment date, location, type and level, the CoC's own questions and results, and a prioritization status. 4.20 Coordinated Entry Event holds referral and placement events with their results. A third, 2.09 Coordinated Entry Participation Status, is a project-level flag.
Set that against how specific the rest of the manual is. Counting its own element list, HUD names 13 Universal Data Elements and 16 Common Program Specific Data Elements collected about clients. That is 29 fields of federal precision about what must be recorded, and two carry the whole of coordinated entry.

Every Field Inside Elements 4.19 and 4.20
Two elements sounds thin until you open them, so here is the whole of both, field by field, as the FY 2026 manual writes them. Sixteen fields carry coordinated entry in an HMIS. Nine sit in 4.19 and seven sit in 4.20. Reading the list is the fastest way to see what your system is actually required to hold, and what it is quietly leaving to you.
4.19 Coordinated Entry Assessment: nine fields
Notice how much of that list HUD hands back to you. Assessment Type, Assessment Level and Prioritization Status arrive with fixed response options, so three of the nine fields are standardized nationally. One is a date. The remaining five, meaning the location list and all four question and result fields, are marked "locally determined" or administrator-managed, which is HUD saying your CoC decides. That flexibility is deliberate and it is the reason two CoCs can run entirely different assessments and both be compliant. It is also the reason nobody can hand you a configuration and call it done.
4.20 Coordinated Entry Event: seven fields
The Event field is where the real detail lives. Its options run from problem-solving conversations and referrals to a scheduled assessment, through service referrals for street outreach and housing navigation, and on to referrals against an actual vacancy in emergency shelter, transitional housing, joint TH-RRH, rapid rehousing, permanent supportive housing, other permanent housing, and a Housing Stability Voucher. HUD marks the subset that means a door genuinely opened: "Recording any event in Field 2, Responses 10 through 15, 17 and 18 indicates there is an opening for the client to be housed by the project."
One caution worth carrying into a configuration review. On that same page, seven of the listed options carry the sentence about an opening in their own descriptions, while the instruction above numbers eight. The response codes and the printed label order do not line up one to one, so map your event codes from the HMIS CSV specification rather than from the position of a label on the page. Teams that count down the visible list instead of reading the codes get their opening metrics wrong by one category, and it surfaces at reporting time.
Now hold the whole sixteen-field picture in view, because the gap is the point.

Why a Compliance Record Cannot Run a Caseload
Look at how HUD tells you to collect these sixteen fields. The collection point for each element is "At Occurrence," and each is collected about the Head of Household. Both details sit on the element pages.
So the record the federal government asks for is a log of things that already happened, attached to one person per household. That is reasonable for a funder to want. It produces a defensible APR, it lets a CoC prioritize across a region, and it shows whether referrals turn into placements. Every one of those is a real use, and an HMIS that does them well is doing its job.
An event log answers a different question than a case manager asks.
A log tells you what happened. A case manager needs to know which referral has gone quiet, whose income verification is about to expire, and which household is one document short of a unit about to be offered to somebody else. None of those questions is answerable from the sixteen fields, because none of them holds an owner, a due date, or a next action. HUD never asked it to. The manual is a reporting specification, and it is a good one.
CUBE84 argued this about housing technology generally in a webinar on why most housing systems were built to report rather than to run. Coordinated entry is where the pattern bites first, because it carries the most handoffs.
One Intake Conversation, Four Places to Type It
A director of housing services at a homeless services nonprofit described this to us before a scheduled demo, unprompted. Staff there document into HMIS and into a separate electronic health record, with an interface between the two still under construction. Until it lands, the same client conversation gets typed twice, by the same person, on the same afternoon.
That is one organization, so read it as an illustration rather than a measurement. The shape will be familiar anyway.

Every arrow away from the required record is where a version of the truth starts to drift. The spreadsheet knows who needs a call back. HMIS knows what HUD will be told. The referral email knows what the partner agency was asked for. None of them knows what the others know, so somebody rebuilds the picture before doing anything useful. Case managers do that reconstruction daily and rarely count it as work. It looks like getting ready to start.
Four Questions to Run Against Your Own Coordinated Entry System
None of these needs a vendor in the room. Each one traces back to something specific in the sixteen fields above, which is what makes them diagnostic rather than rhetorical. Run them against the system you have, write the answers down, and treat those answers as the requirements for whatever you do next.

1. Can one person complete intake, assessment, and referral without leaving the system?
Time it with a real case that is already open, and with the staffer who normally does it. The reason this question works is structural: 4.19 and 4.20 are two elements with two collection points, and most systems reflect that split in their screens. So the moment assessment finishes, somebody navigates somewhere else to record the referral, and often somewhere else again to tell the receiving project.
A bad answer sounds like a list of steps rather than a number of minutes. If your staff describe a route through three screens and an email, the count of context switches is your real measurement, and each one is a place where the record and the reality drift apart. Watch particularly for the phrase "then I copy it into." That is double entry being described by someone who has stopped noticing it.
What to do about it: put this question into your procurement document verbatim. It names an outcome rather than an architecture, so no vendor can satisfy it on paper, and it is testable in a live demo in under ten minutes. Ask to drive the demo yourself with a household of four.
2. When a referral goes quiet, what tells somebody?
This is the question that separates a record from a workflow. Referral Result in 4.20 has three response options, and all three are recorded after somebody follows up and learns the answer. Date of Result is filled in when the outcome becomes known. Neither field creates the follow-up, and nothing in the sixteen fields sets a date by which silence becomes a problem.
If the honest answer is a person remembering, memory is your control. Memory does not survive turnover, and in homeless services turnover is the norm rather than the exception. The version of this answer to worry about most is "our team is really good about that," because it is usually true and it is entirely dependent on the people currently in the chairs.
What to do about it: this is the cheapest of the four to fix and the fastest to show a result. Put an owner and a due date on every open referral in whatever system already holds them, then review the overdue list weekly with names attached. You are adding two fields and one meeting, and you will find referrals that have been quiet for months. Fix this one first if you want early credibility for a larger change.
3. Where does a household member who is not the head of household appear?
Both elements say "Data Collected About: Head of Household." That is an efficient rule for regional prioritization, since a CoC ranks households rather than individuals. It also means the federal record of your coordinated entry work describes one person per family.
A bad answer is any answer that names a location outside your system of record: a case note, an attachment, a shared drive, somebody's own tracker. Ask specifically about a teenager aging toward eighteen, a household member with a disability affecting unit selection, and a member whose income changes eligibility. Those three details decide placements, and they routinely live nowhere official.
What to do about it: decide deliberately where household-level detail belongs, write it down, and make it the same place every time. The failure here is rarely that teams have no answer. It is that they have four answers, one per case manager, and none of them is wrong enough to force a decision.
4. In the week before a report is due, does anyone stop serving clients?
HUD's instruction for both elements is "At Occurrence," which means data is meant to be captured as the work happens. A reporting crunch is evidence that it is being assembled afterward instead. The crunch is the symptom, and the cause sits upstream in when and how validation happens.
A yes tells you something more specific than "we are busy." It tells you your data quality checks run at reporting time rather than at entry time, so errors are discovered weeks after the conversation that could have resolved them. By then the client may be unreachable, and the person fixing the record is guessing. That guessing is the quiet reason data quality work feels demoralizing.
What to do about it: move validation to the point of entry. Required fields, plausibility checks and inline warnings while the client is still in the room cost a few seconds each and remove whole days from the reporting cycle. Then measure the change by timing the next submission rather than by asking whether it felt easier. Our walkthrough of what makes APR and CAPER submission harder than it should be covers the mechanics.
Which Symptom to Fix First
Fixing this begins with deciding which symptom costs your team the most time this quarter, because sequence matters more than scope. Each pairing below is explained underneath the table.
Take double entry first, because it compounds. Every duplicated record adds a second place to be wrong. Referrals going quiet is the cheapest to fix, since a due date and a named owner on an existing record needs no new system. Data quality flags at reporting time come from the timing of validation rather than the diligence of staff, and that is the part leadership most often gets backwards. The governance question belongs last on the list and first on your calendar, because confirming who can decide costs one conversation and unblocks everything after it.

None of this asks you to replace HMIS. HMIS is where HUD's numbers live and it does that job. Moving one household from crisis to stability is a different job, and it needs a record that carries the next action rather than a log of the last one. If you inherited a vendor decision, our side-by-side look at how the main HMIS products compare sets out the criteria worth holding a product against.
Sources
24 CFR 578.7, Responsibilities of the Continuum of Care — paragraph (a)(8) carries the centralized or coordinated assessment system requirement, quoted verbatim above.
HUD Exchange, Coordinated Entry — the four core components, and the statement that the CE data elements standardize data collection on them.
FY 2026 HMIS Data Standards Manual — the Universal and Common Program Specific element lists the counts of 13, 16 and 2 were taken from.
4.19 Coordinated Entry Assessment — the nine-field Response Descriptions table reproduced above, the "At Occurrence" collection point, and the head-of-household scope. Read 24 August 2026.
4.20 Coordinated Entry Event — the seven-field Response Descriptions table reproduced above, the Event response list, and the quoted instruction on Responses 10 through 15, 17 and 18. Read 24 August 2026.


