This release covers both the applicant portal and the Public House package inside your Salesforce org. It is focused on security and reliability: communication between the browser and Public House is now encrypted end to end, integration credentials are encrypted at rest in Salesforce, endpoints that act on your data verify who is calling them, and the causes of several outages and frozen-page reports have been fixed at their source. There are also three new configuration and verification tools for staff.
Security & Privacy
- Application data is now encrypted end to end - Every request the application sends is sealed in an AES-256 authenticated encryption envelope before it leaves the browser, and the reply comes back sealed the same way. This covers applicant information such as household composition, income and identity documents. Each browser session receives its own encryption key, which is exchanged in a way that never exposes it on the network and expires after 30 minutes.
- Requests can no longer be captured and re-sent - Each sealed request carries a timestamp and a single-use marker, so a request intercepted in transit cannot be replayed, and it is locked to the exact endpoint it was sent to.
- Routing credentials no longer travel in plain text - The values that tell our server which organization a request belongs to used to be readable on the wire, and anyone who knew an organization's id could ask the server to act on that organization's behalf. Those values now travel inside the encrypted envelope, so a caller must hold a key our server issued before it can ask for anything at all.
- Integration credentials are encrypted at rest in Salesforce - Your Amazon S3, Box, Dropbox, Google Drive and Stripe keys, secrets and access tokens previously sat in plain text in a Salesforce settings record, readable by anyone who could open it. They now live on a dedicated Public House Configuration record with every secret AES-256 encrypted, and are decrypted only at the moment a request is made. A one-time migration moves existing values across; anything not yet migrated keeps working from its old location, so there is no cut-over outage.
- Credentials are no longer written to Salesforce logs - Saving the setup screen used to record every credential, in full and in plain text, into the configuration change log. It now records who made the change with the values redacted. The Dropbox and Google Drive connection steps have had the same treatment, so an app secret is never written to the debug log during a token exchange.
- Invalid sign-in links now return a single, uniform message - The Salesforce API behind passwordless email and text links used to return different error text depending on exactly why a link failed to decode. Those differences are enough for an attacker to work out a valid link by trial and error. Every failure now returns the same message, with the real reason recorded server-side only. This is the Salesforce half of the fix; the web tier separately limits and alerts on repeated attempts.
- Staff-only functions now verify the signed-in user - The endpoint behind lottery email notifications previously accepted an organization id as proof of identity, which is not a secret. It now requires the staff member's own Salesforce session, verifies that session with Salesforce before reading anything, and confirms it belongs to the same organization as the request.
- Protection against automated credential guessing - The magic-link sign-in path is now rate limited to a tight ceiling, with alerting well below the point at which requests are blocked, so a slow distributed attempt is still visible. The application's normal traffic is unaffected: the limit applies only to a request shape that legitimate use never produces. A second, workspace-wide limit now logs unusual volume from any single source.
- Outbound requests are locked to verified Salesforce addresses - Any Salesforce address supplied in a request is now checked against an allowlist of genuine Salesforce domains and must be a plain secure address with no additional path or parameters. This closes a category of trick in which a caller could have our server send an authenticated request somewhere else entirely.
- Credentials are never written to web server logs - Session identifiers, encryption keys and request contents are excluded from all logging; only a non-reversible fingerprint is recorded, which is enough to trace one session through the logs without the logs becoming a place to harvest credentials from. Rejected requests all return the same message, so error text gives an attacker nothing to work with.
- Salesforce integrations protected from accidental breakage - Requests Salesforce sends to Public House (SMS sends, email templates, status checks, storage checks) cannot be encrypted, because Salesforce has no way to hold a key. The server now refuses to start if any of those endpoints is ever placed behind encryption by mistake, which prevents a class of silent failure where text messages or emails simply stop going out with no visible error.
New for Staff
- Nightly document verification across all cloud storage providers - A scheduled job now confirms that every uploaded document still exists in your storage provider, and records the result and the date it was checked on each file. It runs nightly against new and changed files, and re-checks every file on a rolling 60-day cycle, so a document deleted directly in storage is caught even when nothing changed in Salesforce. Box has been added alongside Amazon S3, Dropbox and Google Drive, so all four providers are covered by one job that adapts to whichever provider your org uses.
- Upcoming invitation reminder dates for lotteries - Invitation-only lottery screenings now return the dates of their upcoming applicant reminders, calculated from the campaign end date and your reminder configuration, so staff can see what applicants will receive and when.
Reliability
- A single upstream hiccup can no longer take the platform down - On 21 August an interrupted connection from an upstream service crashed the application servers one after the other, leaving roughly two minutes with no service and 173 failed requests across 11 client sites, including applications that were mid-submission. That failure is now handled where it occurs. A related problem, where an upstream service that stopped responding part-way through left the browser waiting indefinitely, is also fixed.
- Graceful shutdown instead of severed connections - If an unexpected error does still bring a server down, it now stops accepting new work and lets requests already in progress finish, so users receive a proper response rather than being cut off mid-action.
- Bulk updates no longer fail on income limit lookups - Updating service files in bulk - a data load, or a mass update from a list view - could hit Salesforce's limit on the number of queries a single operation may run, and fail outright. Income limit configuration is now loaded once per operation and reused, instead of being re-read for every record.
- Smarter retries on failed requests - A failed request used to be re-sent up to three times regardless of the reason, which tripled the delay on exactly the calls that were already failing and risked submitting the same change twice. The application now retries only when the connection dropped with no response at all - the one case where nothing was processed - and surfaces every other failure immediately.
- Reminder text message failures are now recorded properly - When the messaging service returned an error page rather than a normal response, the reminder job could not read it and the real reason was lost. Failures now record the response status and content, so a messaging outage is visible in the log instead of appearing as reminders that quietly did not send.
Fixes
- Login links missing for Person Account orgs - In orgs that store applicants as Person Accounts, the passwordless email and phone login links were never generated, because writing the applicant through the Account does not trigger the logic that creates them. Those links are now produced on every path. A related problem, where an applicant with only a mobile number on file got an empty phone login link, is also fixed. Links already issued remain valid.
- Frozen page when opening a Photo ID with an expiry date - Opening a Photo ID document that had an expiry date on file locked up the browser tab. Other document types were unaffected, which is why this often looked like a slow network or a stuck upload. Fixed.
- Payment card fields not appearing - On the payment screen and the payment pop-up, the card entry fields could silently fail to appear, leaving applicants unable to pay. Fixed. The payment screen also no longer keeps retrying in the background after a user navigates away, which could cause a second set of card fields to load later and be rejected by the payment provider.
- Error messages no longer freeze the screen - Over a hundred blocking pop-up alerts have been replaced with notifications that appear without halting the page. Previously, because several document panels load at the same time, one failing document could stall every other request behind a dialog the user had not noticed.
- Dashboard loading errors - An intermittent "cannot read properties of undefined" failure while the dashboard was still loading its configuration has been fixed at source rather than page by page, along with a related error that could leave the loading overlay on screen indefinitely.
- Candidate Pool - Not Interested page - The page now shows the correct heading (it previously read "Property Invitations Test"), displays the property address, and loads your program's logo in the header.
- Candidate pool offer checkboxes - The offer checkboxes in the candidate list now render correctly, can be clicked, and are labelled for screen readers.
- Staff campaign pages loading empty - After a recent web address change, several staff-only campaign management pages were being treated as applicant links and loaded without their data. Fixed.
- Clear message when email limits cannot be checked - Before sending lottery notifications the system checks your organization's remaining email capacity. If that check failed, the screen used to report that there was no capacity left - a plausible but wrong explanation. It now says what actually happened and tells you whether to reload or retry.
- Waitlist application due dates kept in step - When a campaign member's application due date changed, the matching waitlist entry was not always updated with it. Fixed.
- PDF viewer and document merge - Fixed a document merge failure and packaged the PDF viewer's supporting files correctly, so document previews and combined PDFs work consistently.
Rollout notes
Encryption of browser traffic is being introduced in monitoring mode first. During this period the platform accepts both encrypted and unencrypted requests and records which is which, so that any browser still running a cached copy of the previous version keeps working. Once those records show that all traffic has moved over, strict enforcement is switched on and unencrypted requests are rejected.
On the Salesforce side, two steps are run once per org after the package upgrade: the credential migration, which moves existing integration secrets into the new encrypted configuration record, and scheduling the nightly document verification job. Both are safe to re-run. The Public House API permission set has been extended to cover the new configuration record and reminder settings, so it should be reapplied as part of the upgrade.