Business Directory & CRM-Integrated Plugin

Custom WordPress directory plugin with CRM sync, workflow automation, and controlled data sourcing.

Project summary

Designed and extended a reusable WordPress plugin architecture for agency clients who needed directory management inside WordPress while keeping CRM and automation systems synchronized.

A WordPress directory that stays in sync with CRM and automation systems without brittle manual work.

Abstract network illustration for the business directory plugin

Project summary

Sync model

Two-way WordPress and GoHighLevel

Automation layer

Pabbly-triggered workflows

Designed and extended a reusable WordPress plugin architecture for agency clients who needed directory management inside WordPress while keeping CRM and automation systems synchronized.

Buyer-facing summary

Client problem

The business needed a searchable WordPress directory connected to CRM and automation workflows instead of managing records manually.

What I delivered

I built custom plugin logic, data structure, search and filter behavior, and integration flows for syncing external systems with WordPress.

Business result

The team could manage directory data through a structured workflow instead of relying on scattered manual updates.

Problem

Agency clients needed searchable business directories in WordPress, but the real complexity lived outside the front-end listings: the same records also had to exist in GoHighLevel, trigger workflows in Pabbly, and sometimes be sourced from systems without a usable API.

Directory plugins can handle the display layer. The cross-system data ownership problem had to be built from scratch.

Different client field mappings meant the plugin needed to stay modular instead of hard-coding one directory model.

Some source sites offered no clean API, which forced scheduled collection workflows instead of direct integrations.

What I built

Custom directory plugin core

Structured the plugin around custom post types and custom fields so listings stayed queryable and adaptable as client requirements changed.

Two-way GoHighLevel sync

Integrated directly with GoHighLevel’s API so updates could move in both directions with field mappings tailored to each client’s actual workflow.

Pabbly workflow triggers

Sent the right payloads at the right time for listing submissions, approvals, and status changes so follow-up automations could run without manual intervention.

Scheduled data sourcing

Built Selenium-driven collection flows for data sources that did not provide a clean API, keeping the work scheduled and controlled rather than scraping live user paths.

Custom directory plugin coreTwo-way GoHighLevel synchronizationPabbly-triggered workflow automationScheduled Selenium-based data sourcing

Technical decisions

The hardest problem was avoiding sync loops between WordPress and GoHighLevel while still supporting real two-way updates.

Field mapping needed explicit tracking for which system last changed a record so updates would not bounce back and forth endlessly.

Two-way sync sounds simple until both systems can edit the same record. Avoiding loops and conflicts was the core technical problem.

The plugin architecture needed to support variations in field requirements without turning into a fork-per-client maintenance burden.

Outcome

Directory records stay aligned across WordPress and GoHighLevel instead of drifting apart through manual edits.

Automation workflows now start from real product events, which reduced operational handoffs for clients.

The plugin became a reusable foundation instead of a one-off build tied to a single directory implementation.

What I would improve

I would push sync-conflict handling into the design even earlier, before the first live test reveals where state ownership is ambiguous.

That part is easy to underestimate in kickoff conversations because the happy path sounds much simpler than the real update lifecycle.

Tech stack

WordPressGoHighLevelPabblySeleniumCustom REST APIs

Next step

If you need similar work, let’s talk through the constraints first.

The useful part of a project like this usually starts before code: understanding what the CMS should own, what should live in a backend service, and where integrations or automation can stay maintainable.

Start a conversation

Related work

Client platform

AudioMazes

Custom WordPress audio platform with persistent playback, gated access, and secure AWS-backed delivery.