Nationwide Organization Directory Network

The challenge

A nationwide network wanted to increase awareness of its participating organizations and make it easier for them to find and connect with one another. Each participating customer website maintained its own directory of organizations, but separate directories on separate sites offered no view across the network.

The listings needed to come together in a national directory without taking away each website’s ability to manage its own entries. The directory also had to handle organizations of very different shapes: some had a single office, some had hundreds of locations, and some served a region without a physical presence there. Visitors needed to search by name, service, category, and geography, and the result list and map needed to stay consistent with one another.

The solution

I designed and developed reusable Drupal directory functionality that ran across customer deployments of our community platform. Organizations, their locations, and the areas they served became structured Drupal content, and each directory entry could function as a small microsite describing the organization and its services.

Each participating website managed its own local directory, and queue-based synchronization brought those listings into a central national directory. Visitors could search by text, category, service, and location and find organizations either physically nearby or serving the area they searched, with the result list and interactive map updating together as filters or the map area changed.

Results and capabilities

The platform was deployed and used in production. Participating websites kept managing their own directories while contributing listings to the national directory, and the national site gave the network a central place to discover organizations from across it, in support of the network’s goal of making those organizations more visible and connected.

Customer organizations could shape their directories around their own categories and geography while editors continued managing familiar Drupal content. For the development and support team, the design also gave us clear places to extend search, troubleshoot synchronization problems, and recover when indexed data became stale.

My role

I designed and built the organization, location, and service-area entities; the queue-based import and synchronization that brought local listings into the national directory; 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 and on-demand map popups that keep 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.

Technical implementation

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, including bringing local listings into the national directory, 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 visitor 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 imports and 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.

Examples of how I used AI

I used it across implementation, debugging, refactoring, and automated testing, while remaining responsible for the architecture, technical decisions, review, and final result. The examples below show a few places where it provided particularly useful leverage.

On-demand map popups

Map pins originally loaded through the Drupal Views map display, which rendered popup content for every location during the initial request. For organizations with hundreds of locations, that made the response unnecessarily heavy. I designed an approach where each marker carried only the information needed to identify it, then used AI to help work through the implementation that fetched and cached the Drupal-rendered popup only when someone selected the pin.

Coordinated search

I used AI while iterating on the service that coordinated the organization and location indexes, including request handling that prevented slower, outdated searches from replacing newer results. It was useful for working through implementation options and debugging interactions among the search, AJAX, and map behavior.

Automated testing

AI also let me spend more time building automated coverage than the project schedule would normally have allowed. I used it to accelerate the creation and refinement of PHPUnit tests for backend behavior and Playwright tests for browser-level workflows, then reviewed and ran those tests as part of validating the implementation.

My role

I decided what to build and how it should fit the platform, supplied the context and constraints AI needed, and reviewed the resulting code and tests. AI increased the amount I could explore and validate; I remained responsible for what shipped.