Public Data & Directory Applications

I have developed and maintained several public directory applications that make information managed internally in Salesforce available through public-facing websites.

Although individual implementations vary, they share a common architecture: Salesforce remains the authoritative source for organization and contact information, while a Django application periodically retrieves the appropriate records, validates and transforms the data, and stores a public representation in PostgreSQL.

The website can then provide fast searching, filtering, geographic lookup, and mapping without querying Salesforce during normal visitor requests.

Wagtail provides content management for the surrounding website, while Django handles the directory application, data synchronization, geographic processing, search, and filtering.

These applications are intentionally one-directional.

Staff maintain organization, contact, program, and eligibility information in Salesforce as part of their existing business processes. A scheduled synchronization retrieves the records intended for publication and converts them into the structure required by the website.

This avoids maintaining separate versions of the same information in Salesforce and the CMS. Staff can update the system they already use, and those changes are reflected automatically in the public directory after synchronization.

The approach improves data consistency while reducing the administrative work required to keep public information current.

Salesforce data is not always stored in the format most useful for a public website.

During synchronization, Django normalizes and validates incoming information before updating the local database. This can include formatting contact information, interpreting relationships between organizations and individuals, translating Salesforce fields into website-specific filters, and determining which records should be publicly available.

Addresses are also prepared for geographic search and mapping. Where appropriate, addresses are geocoded and their coordinates stored locally so the application does not need to repeatedly geocode the same records during visitor searches.

Keeping this processing in the synchronization workflow allows the public application to work with clean, purpose-built data without changing how staff maintain the underlying records in Salesforce.

Once synchronized, the directory behaves as a normal Django application backed by PostgreSQL rather than as a live view into Salesforce.

Visitors can search by location and narrow results using criteria appropriate to the individual program. Depending on the implementation, filters may represent services, technologies, certifications, program participation, service territories, organizational characteristics, or other Salesforce-managed information.

For location-based directories, the application can calculate proximity to a visitor's search location, sort results by distance, and display matching locations on an interactive map.

The results list remains the primary representation of the directory data, with mapping providing an additional geographic view rather than being the only way to access the information.

Although these directories serve different programs and expose different information, the underlying engineering pattern is reusable.

The synchronization layer determines which Salesforce records and fields are needed. Django models provide a local representation optimized for the public application. Program-specific filters and display rules can then be added without changing the fundamental architecture.

This makes it possible to reuse proven approaches for synchronization, geographic processing, search, mapping, error handling, and deployment while still tailoring each application to the needs of a particular program.

Wagtail can be added where broader content management is required, allowing the directory to exist alongside normal editorial pages without making the CMS responsible for managing the directory data itself.

The primary goal of these applications is not simply to display Salesforce data on a website. It is to create a reliable boundary between an internal business system and a public application.

Salesforce remains the authoritative source, while scheduled synchronization ensures the public database is regularly refreshed. Errors can be logged and investigated during synchronization rather than surfacing as failed Salesforce requests to website visitors.

Because information flows in one direction, the architecture is also deliberately simple: public users cannot modify Salesforce records, and content managers do not need to reproduce Salesforce-managed information in Wagtail.

The result is a public directory that can evolve independently as a web application while preserving a single source of truth for the staff responsible for maintaining the underlying information.