Organization Directory and Geographic Search

Why we built it

We were building a Drupal community platform used by multiple customer organizations. Members needed more than a basic profile: each organization could create a small microsite, describe its services, publish locations, and connect with other members.

Organizations were not all shaped the same way. Some had a single office, some had hundreds of locations, and some served a whole region without a physical presence in it. As the directory grew, discovery became its own problem: people needed to search by name, service, category, and geography, and the result list and map needed to stay consistent with one another.

My role

I designed and built the organization and location entities, the service that coordinates two Search API indexes into a single result set, the index processors that keep unpublished and access-restricted records out of search, and the AJAX behavior that keeps the result list and map in step.

I also established the cache metadata and queue patterns used in this part of the platform and reviewed the work that built on them.

What it unlocked

Members could present their organizations and find others either nearby or serving their area. Customer organizations could shape the directory around their own categories and geography while editors continued managing familiar Drupal content.

For the team, the design also gave us clear places to extend search, troubleshoot synchronization problems, and recover when indexed data became stale.

What we added to the platform

Organizations, locations, service areas, and categories remained structured Drupal entities, so editors retained normal Drupal workflows and each directory entry could function as a microsite. A service-area record described where an organization worked rather than where it sat, at the level of an address, city, county, state, or country, so an organization could be found for a place it served even without an office there. Separate Search API indexes handled organization and location data. A coordinating service used the geographic results to limit the organization search, then Views rendered one shared result set for both the list and map.

Index processors excluded restricted or unpublished parents before their locations could appear in search. Queue workers handled imports and synchronization in manageable batches. This kept the visitor experience responsive while giving support teams clear ways to diagnose stale or missing records.

How a search worked

A member could enter text, select Facets, or search within an area, either from coordinates or from a recognizable place name. The server normalized those criteria, found matching locations and service areas, and applied the eligible organization identifiers to the main search. Views returned one response for the results and markers. If someone moved the map or changed a filter quickly, newer requests superseded older ones so a delayed response could not redraw the interface with stale information.

Drupal under the hood

Entity and Field APIs

Modeled organizations, locations, services, references, validation, access, and display.

Views, Search API, and Facets

Provided configurable displays, indexed search, exposed forms, filters, and administrative reporting.

AJAX and Drupal behaviors

Kept filters, results, and the map synchronized while preserving a conventional server-rendered form.

Queue and Cache APIs

Moved synchronization out of visitor requests and kept reusable output correct as content and access changed.

Why I chose this approach

I chose separate search indexes for organizations and locations because they represented different things in the directory. An organization might have one location or hundreds, and the map needed to show those individual locations while the search results still represented the organization as a whole.

The organization index drove the main results, while the location index supplied geographic matches and map pins. That gave us a clean way to support organizations of very different sizes without duplicating the organization record for every location.

We also needed to support organizations that served an area without having a physical office there. I created service-area records that could describe coverage by address, city, county, state, or country. That meant someone searching an area could find both organizations physically nearby and organizations that specifically served that area.