Case study

Dynamics 365–HubSpot integration

The challenge was not a point-to-point sync. It was coordinating three platforms with different responsibilities without allowing updates to become ambiguous or circular.

Client

NOLS

Role

Middleware architecture and integration development

Year

2025–2026

Summary

Built middleware coordinating data movement between Dynamics 365, WordPress, and HubSpot so three distinct systems could participate in one dependable workflow.

The brief

NOLS needed Dynamics 365, WordPress, and HubSpot to exchange information as part of a shared customer and marketing workflow.

I built a middleware application that coordinated those systems while keeping their individual responsibilities visible.

Why three-system integrations are different

In a point-to-point integration, ownership can often be expressed as a relationship between two records. With three systems, the number of possible paths grows quickly.

A WordPress action may need to reach Dynamics, HubSpot, or both. A change in Dynamics may affect the context HubSpot uses. If every platform can update every other platform without a clear contract, loops, stale values, and conflicting records become difficult to avoid.

The approach

The middleware served as the coordination layer rather than embedding integration logic independently in each platform.

The implementation focused on:

  • explicit ownership for values shared across systems;
  • stable identifiers used to correlate related records;
  • normalized payloads at each platform boundary;
  • controlled event and update paths;
  • idempotent behavior when work was retried; and
  • visible failure information for operational recovery.

WordPress remained responsible for the relevant website experience, Dynamics retained its application and business role, and HubSpot received the context required for its CRM and marketing workflows.

Why the middleware boundary mattered

Centralizing the integration contract made the system easier to reason about. Platform-specific API behavior could be handled at the edge, while the core workflow used a consistent internal representation.

It also reduced coupling. A change to one API or field mapping did not need to be reproduced across two separate direct integrations.

The takeaway

This project demonstrates how I approach multi-system architecture: make ownership explicit, coordinate through a focused boundary, and design retries and failures as normal operating states. That discipline keeps a three-platform workflow from becoming three competing sources of truth.

Related writing