Skip to main content
The Bloom Common Application is the multi-step digital form housing seekers use to apply for affordable housing listings. Applications capture household composition, income, demographics, preferences, and contact information. Partners review and manage applications through the Partners Portal, while applicants track their submissions through the public portal.

Application sections

An application (Application DTO, application.dto.ts) collects data across several sections:

Applicant

Primary applicant name, date of birth, email, phone number, work-in-region flag, full-time student status, home address, and work address.

Household members

Additional people in the household. Each member has a name, date of birth, relationship to the primary applicant, home and work addresses, and a same-address flag. Supported relationships (HouseholdMemberRelationship): spouse, registeredDomesticPartner, parent, child, sibling, cousin, aunt, uncle, nephew, niece, grandparent, greatGrandparent, inLaw, friend, aideOrAttendant, other.

Demographics

Optional self-reported demographic data including race, ethnicity, gender, sexual orientation, and how the applicant heard about the listing. Collected to meet fair housing reporting obligations. The disableEthnicityQuestion feature flag can suppress the ethnicity question per jurisdiction.

Preferences

Multiselect questions that correspond to listing preferences (e.g., Live/Work in the City, Displaced Tenant). Applicant responses are stored in applicationSelections and linked to MultiselectQuestion records via applicationMultiselectQuestions. Preference responses can trigger geocoding validation when enableGeocodingPreferences is enabled.

Income

Reported household income amount and period (monthly or annual per IncomePeriodEnum). The enableVerifyIncome feature flag enables server-side validation of reported income against AMI limits for the listing’s units.

Alternate contact

An optional secondary contact who can receive application-related communications on behalf of the applicant. Relationship types (AlternateContactRelationship): familyMember, friend, caseManager, other, noContact.

Accessibility

Optional accessibility needs for the unit: hearing, mobility, vision, other (boolean flags).

Addresses

Home address, mailing address (if different), and alternate address. Each address includes street, city, county, state, zip, and optional latitude/longitude for geocoding.

Application statuses

The ApplicationStatusEnum (from @prisma/client) defines valid submission states:
StatusDescription
draftApplicant has started but not yet submitted the application
submittedApplication has been formally submitted
removedApplication has been withdrawn or removed
The ApplicationReviewStatusEnum tracks partner review state:
StatusDescription
validApplication is eligible and ready for review
duplicateApplication has been marked as a duplicate
pendingVerificationApplication is awaiting verification
Applications also carry a markedAsDuplicate boolean flag that is set by the flagged set resolution workflow.

Flagged sets (duplicate detection)

When multiple applications appear to share the same household (matching name, date of birth, or address combinations), Bloom creates an Application Flagged Set (AFS). The afsLastRunAt field on the listing records when this process last ran. Flagged sets allow partners to:
  • Review potentially duplicate applications side-by-side
  • Mark one application as the canonical record
  • Mark others as markedAsDuplicate: true, which excludes them from the lottery
Duplicate detection runs automatically as part of the listing close process. Applications marked as duplicates are excluded from lottery randomization.

Submission paths

Housing seekers use POST /applications/submit to submit their application. This endpoint:
  • Requires validation groups default and applicants
  • Sends a confirmation email via EmailService
  • Associates the application with the authenticated user’s account if signed in
  • Runs geocoding if enableGeocodingPreferences is active on the listing’s jurisdiction
Use POST /applications/verify to pre-validate an application payload without saving it.

Partners portal workflow

1

View applications

Navigate to a listing in the Partners Portal and open the Applications tab. The list view uses the partnerList application view, which includes applicant name, DOB, contact info, address, and submission metadata.
2

Review flagged sets

Open the Flagged tab to review duplicate application sets. Resolve each flagged set by selecting which application to retain.
3

Edit an application

Partners can update an application via PUT /applications/:id. Use POST /applications/:id/notify-update to send the applicant an email notification about the change.
4

Export applications

Use the Export button to download a CSV or spreadsheet of all applications for the listing.

Public portal: application status

When the enableApplicationStatus feature flag is enabled on a jurisdiction, applicants can view the status of their submitted applications from their account page. The GET /applications/publicAppsView endpoint returns a summary of an applicant’s applications (grouped by listing) suitable for display on the public portal. The GET /applications/mostRecentlyCreated endpoint returns the most recently submitted application for the authenticated user, filtered by listing ID.

API endpoints

MethodPathDescription
GET/applicationsGet a paginated set of applications (ApplicationQueryParams)
GET/applications/:applicationIdGet a single application by UUID
GET/applications/mostRecentlyCreatedGet the most recent application for the current user
GET/applications/publicAppsViewGet public application status summary for the current user
POST/applicationsCreate an application (partner hand-entry)
POST/applications/submitSubmit an application (applicant flow)
POST/applications/verifyValidate an application payload without saving
PUT/applications/:idUpdate an application by UUID
POST/applications/:id/notify-updateSend applicant an update notification email
DELETE/applicationsDelete an application by ID (passed in request body)
PUT/applications/removePIICronJobManually trigger the PII removal cron job

CSV and spreadsheet export

Applications can be exported in two formats:
EndpointFormatDescription
GET /applications/csvZIP of CSV filesStandard application export
GET /applications/spreadsheetZIP (spreadsheet format)Formatted spreadsheet export
GET /applications/csvSecureSigned URLSecure CSV download link
GET /applications/spreadsheetSecureSigned URLSecure spreadsheet download link
All exports accept ApplicationCsvQueryParams and require partner-level permissions.
When enablePartnerDemographics is enabled on the jurisdiction, demographic data is included in exports. Disable this flag to omit demographic fields for jurisdictions with stricter data policies.

PII deletion (data expiry)

Bloom includes a scheduled cron job that removes personally identifiable information from applications older than a configured threshold. This is controlled by the APPLICATION_DAYS_TILL_EXPIRY environment variable. When the cron runs, it calls removePII() for each eligible application, which nulls out the following fields:
  • Applicant: firstName, lastName, middleName, birthDay, birthMonth, birthYear, emailAddress, phoneNumber
  • Household member names, dates of birth, and contact information
  • Alternate contact details
  • All associated address records (applicant home, work, mailing, alternate)
The wasPIICleared flag is set to true on the application record after deletion.
PII deletion is irreversible. Set APPLICATION_DAYS_TILL_EXPIRY carefully. If the variable is not set, the cron job will not run.
The job can also be triggered manually by calling PUT /applications/removePIICronJob.

Build docs developers (and LLMs) love