Phase 1:
Foundation
CMT-driven workflows, sync engine, portal, and document engine -- the layer that makes Delivery Hub a configurable platform instead of a hardcoded app.
What's Included
The six pillars that form the foundation of Delivery Hub.
CMT-Driven Workflow Engine
5 workflow types (Software Delivery, Loan Approval, etc.) with 71 stages, all defined as Custom Metadata Type records. Adding a new workflow requires zero code changes -- just deploy new CMT records.
Multi-Entity Data Model
NetworkEntity__c provides tenant isolation. Each client org is a separate entity with its own work items, boards, dashboards, and sync configuration. One Salesforce org serves many clients.
Sync Engine V3
Bidirectional sync between Salesforce orgs via push/pull architecture. Echo suppression prevents infinite loops, GlobalSourceId tracks data lineage, and the kill-switch stops routing when target matches origin.
Portal + REST API
Full client portal at cloudnimbusllc.com/portal with REST endpoints that mirror every LWC capability. Token-based auth, passkey support, and magic link login for non-Salesforce users.
Document Engine
Invoice generation, client agreements, and contractor agreements rendered as PDFs via a React bundle in a Salesforce Static Resource. Documents are served through SF Sites with token-based access.
Ghost Recorder
Automatic activity tracking that records field changes, stage transitions, and user interactions. Captures who did what and when without requiring manual input from the team.
Design Choices
Why we built it this way. Every decision has a reason.
Why Custom Metadata Types instead of custom objects for workflow config
CMT records deploy with the package via git, survive org refreshes, and are queryable in Apex without DML. Admins can edit them in Setup without writing code. This is why adding a new workflow type is a metadata deployment, not a code change.
Why a 3-CMT hierarchy (WorkflowType, WorkflowStage, WorkflowPersonaView)
WorkflowType defines a workflow. WorkflowStage defines each stage within a workflow (colors, transitions, terminal states). WorkflowPersonaView defines which columns each persona sees on the board. Three objects because each has a different audience: type = admin, stage = developer, view = persona.
Why NetworkEntity instead of standard Account for multi-tenancy
Account is shared across all apps in an org and carries CRM baggage. A dedicated NetworkEntity__c object gives Delivery Hub clean isolation, custom fields (SyncEnabled, PortalAccessToken, EntityType), and no collision with existing CRM processes.
Why echo suppression uses static memory (not custom settings)
Echo suppression needs to work within a single transaction. A Set<String> of blocked origins in static memory is checked before routing. Custom settings would require a query and DML per check -- too expensive in a trigger context with bulk operations.
Why GlobalSourceId for data lineage tracking
In a multi-org sync chain (Client Prod -> Sandbox -> Dev Hub), an item could bounce between orgs forever. GlobalSourceId is a UUID assigned at creation time and propagated via HTTP headers. Any org that sees its own GlobalSourceId knows to stop routing.
Why React-in-Static-Resource for documents (not Visualforce renderAs=pdf)
Visualforce PDF rendering has severe CSS limitations, no modern layout support, and breaks with complex designs. A React bundle deployed as a Static Resource renders on a Salesforce Site with full CSS control and produces consistent PDFs across browsers.
Architecture
Three layers: UI, services, and data. Every component is replaceable.
Three-Layer Architecture
deliveryHubBoard
Kanban Board
deliveryClientDashboard
Client Dashboard
deliveryGettingStarted
Setup Wizard
Portal (Next.js)
Web Client
SyncEngine
Push/Pull Routing
WorkflowConfigService
CMT Queries
WorkItemETAService
ETA Calculations
DeliveryHubController
@AuraEnabled
WorkItem__c
Core Work Items
NetworkEntity__c
Multi-Tenancy
Sync_Item__c
Sync Queue
WorkflowType__mdt
Config (CMT)
Sync Chain (Live in Production)
Client Prod
Client Org
Sandbox
Vendor Org
Dev Hub
Package Org
Portal
Next.js Web
Push: Sync_Item__c queue + SyncItemProcessor queueable. Pull: DeliveryHubPoller + @HttpGet /changes.
Key PRs & Milestones
The major contributions that built the foundation.
Core Package (v0.1 - v0.100)
Initial package structure, custom objects (WorkItem__c, NetworkEntity__c, Sync_Item__c, WorkLog__c), workflow CMT records, and base LWC components.
Sync Engine V3
Push/pull architecture, echo suppression, GlobalSourceId lineage tracking, kill-switch, X-Global-Source-Id HTTP header injection, two-step dedup in SyncItemIngestor.
Portal + REST API
Next.js portal with passkey, password, and magic link authentication. REST endpoints mirror all LWC capabilities. Token-based document access.
Document Engine
React-in-Static-Resource rendering for invoices and agreements. PDF generation via SF Sites. Email delivery with CC to billing contacts.
Ghost Recorder + Activity Tracking
Automatic field change detection, ActivityLog__c event stream, cleanup job for log rotation. Captures stage transitions, field edits, and user actions.
CMT Workflow Platform (gb226)
WorkflowType__mdt, WorkflowStage__mdt, WorkflowPersonaView__mdt. Eliminated all hardcoded stage maps from deliveryHubBoard.js. Added WorkflowTypeTxt__c field to WorkItem__c.
Related Pages
Phase 1 established the platform. Phase 2 made it production-ready.