Architecture &
Scalability
How one platform supports unlimited workflow types, entities, and personas -- without changing a line of code.
The Three-Layer Architecture
Configuration at the bottom, services in the middle, UI on top. Zero hardcoded assumptions.
deliveryHubBoard
Kanban Board
deliveryClientDashboard
Metrics + Attention
deliveryDocumentViewer
Invoices & Agreements
deliveryPortalDashboard
External Client View
WorkflowConfigService
Reads CMT config
WorkItemETAService
Calculates ETAs
BoardController
Entity-scoped queries
SyncEngine
Multi-org sync
EscalationService
CMT-driven rules
WorkflowType__mdt
Defines a workflow (Software Delivery, Loan Approval, etc.)
WorkflowStage__mdt
Defines stages per workflow type with colors, phases, transitions
WorkflowPersonaView__mdt
Defines what each role sees on the board (columns, sort order)
Key insight: Adding a new workflow type (e.g., "Insurance Claims") requires zero Apex or LWC changes. You deploy new CMT records -- WorkflowType, WorkflowStages, and WorkflowPersonaViews -- and the entire stack (board, dashboard, ETA service, escalations) automatically adapts. The runtime engine reads config at query time, not compile time.
★ The Scalability Unlock (PR #471)
Three fixes. 6-8 hours. Unlimited workflow types and client entities.
These 3 fixes required ~6-8 hours of work and unlock Delivery Hub for unlimited workflow types and client entities.
No new objects, no new fields, no schema changes — just parameterizing what was already built.
Fix 1: ETA Service Parameterization
DeliveryWorkItemETAService.cls — the brain that calculates when work items will land
Fix 2: Portal Dashboard Dynamic Phases
DeliveryPortalController.cls — what clients see when they log into the portal
Loan Approval client sees 6 empty software phases:
None of these phases apply to Loan Approval
Phases pulled from CMT — shows the RIGHT phases:
Correct phases for Loan Approval workflow
Fix 3: Board Entity Scoping
DeliveryHubBoardController.cls — who sees what on the Kanban board
Board shows ALL items from ALL clients:
MF sees Nimba test data and ACME items
Board filtered by entity — each client sees only theirs:
MF only sees MF items. Admin can still see all.
How Workflow Types Work
Click a workflow type to explore its stages, phases, and persona views.
Software Delivery
End-to-end software project delivery from initial request through planning, development, testing, UAT, and deployment. Designed for consulting firms managing client work.
37
Stages
6
Phases
4
Personas
Persona Views
Stage Pipeline
Entity Isolation
NetworkEntity__c provides multi-tenant isolation. Each client sees only their data.
Cloud Nimbus (Mothership)
Sees ALL entities -- admin view of entire ecosystem
Mobilization Funding
47 items
Sees only own items
Client B
23 items
Sees only own items
Client C
15 items
Sees only own items
Client D
8 items
Sees only own items
Board Scoping
WHERE NetworkEntityId__c = :currentEntity. Every board query filters by the user's active entity.
API Scoping
API key maps to a NetworkEntity__c record. All responses filtered by that entity's ID.
Report Scoping
Standard Salesforce reports respect entity field filters. Dashboard widgets pre-filter by entity.
The Sync Chain
Push, pull, and echo suppression across a multi-org topology.
Live Sync Chain
MF Prod
Client Org
Nimba Sandbox
Hub / Aggregator
Dev Hub
Central Hub
Portal
cloudnimbusllc.com
GlobalSourceId
Every record carries its origin ID. Kill-switch aborts routing when target matches source.
blockedOrigins Set
SyncEngine maintains a static memory set of origins to ignore during the current transaction.
HTTP Header Injection
X-Global-Source-Id header on every outbound callout lets the receiver identify the chain origin.
What's Configurable vs Hardcoded
The goal is zero hardcoded assumptions. Here's where we stand.
- Workflow types and stages
- Stage transitions and backtrack rules
- Persona board views
- Escalation rules
- Card colors and display names
- Terminal / blocked / attention flags
- Document templates
- ETA service workflow type NOW parameterized
- Portal dashboard phases NOW CMT-driven
- Board entity filtering NOW scoped by entity
PR #471 resolved these hardcoded dependencies.
- No historical velocity tracking
- No developer capacity / sprint planning
- No template management UI
- Onboarding wizard doesn't auto-create entities
Architectural Decisions: Pros & Cons
Every decision has trade-offs. Click to expand the analysis.
Scaling Roadmap
From foundation to intelligence -- a four-phase journey.
Phase 1: Foundation
Complete- CMT-driven workflows
- Multi-entity data model
- Sync engine V3
- Portal + API
Phase 2: Polish
In Progress- ETA parameterization (PR #471)
- Portal phase mapping (PR #471)
- Board entity scoping (PR #471)
- Activity tracking + reports (PR #468)
- Report navigation (PR #464)
Phase 3: Self-Service
Next Up- One-click entity onboarding
- Template management UI
- Workflow type picker in wizard
- Self-service portal auth (Redis migration)
Phase 4: Intelligence
Future- Historical velocity tracking
- Developer capacity planning
- AI-driven ETA estimation
- Sprint / burndown visualization
- Usage-driven feature prioritization
About This Document
This architecture explainer covers the current state of Delivery Hub as of March 2026. The three-layer CMT architecture was designed to support unlimited workflow types without code changes -- every new workflow is a set of metadata records, not a pull request. The sync engine (V3) handles multi-org topology with echo suppression, and entity-based isolation provides multi-tenant data separation at the application layer.