Configurable Workflow Platform
Every organization works differently. Delivery Hub's workflow engine is driven entirely by Custom Metadata — no code changes needed to define new workflow types, stages, or persona views. Software delivery, loan approval, support triage, or any process your team runs — configure it once in metadata and the board adapts automatically.
Key Features
Custom Metadata-Driven
Every aspect of the workflow engine is driven by Custom Metadata Types. New workflow types, stages, colors, transitions, and persona views are all defined declaratively — no Apex changes, no LWC changes, no deployment required. Subscribers configure workflows the same way they configure any other Salesforce metadata.
Seven Built-in Workflow Types
Delivery Hub ships with seven workflow types covering the most common business processes. Software Delivery (37 stages, full SDLC), Implementation Project (11 stages, consulting/SI delivery), Loan Approval (8 stages, disbursement tracking), Support Triage (8 stages, fast linear flow), Onboarding Checklist (7 stages, employee/customer onboarding), Change Management (12 stages, CAB review and rollback tracking), and Operations (9 stages, IT/facilities/HR service desk). Subscribers create their own workflow types by adding CMT records.
Stage Configuration
Each stage record defines an API value, display name, card color, header background and text colors, owner persona, phase (Planning, Development, Testing, or Deployment), and boolean flags for terminal, blocked, and attention states. Forward and backtrack transitions control exactly which stage-to-stage moves are allowed.
Persona Views
Different users see different board columns. A developer sees Dev, Code Review, and Testing. A client sees Backlog, In Progress, UAT, and Done. A project manager sees everything. All of this is configured through WorkflowPersonaView__mdt records — no code changes to show or hide columns per role.
Dynamic Kanban Board
The deliveryHubBoard LWC reads all configuration from @wire(getWorkflowConfig) at runtime. Zero hardcoded color maps, zero hardcoded column lists, zero hardcoded transition rules. Colors, columns, allowed transitions, and persona filtering are all resolved dynamically from the CMT records loaded at board initialization. The board includes a saved filters feature (DeliverySavedFilter__c) so users can recall their favorite filter combinations with one click, and a hide-empty-columns toggle that collapses columns with zero work items to declutter the view.
Saved Board Filters
Save, name, and recall your favorite board filter combinations with one click. The DeliverySavedFilter__c object stores filter criteria (assignee, priority, status, date range, workflow type) per user. The DeliverySavedFilterController handles CRUD operations. Filters are private to each user and persist across sessions — no more re-selecting the same filters every morning.
Hide Empty Columns
Toggle to collapse Kanban board columns with zero work items. Workflows with many stages often have only a few active columns at any given time. The toggle declutters the board and the state persists per user across sessions. Especially useful for the Software Delivery workflow with 37 stages.
Stage Gate Enforcement
Stage gates block transitions when required fields are missing, enforced via WorkflowStageRequirement__mdt records. Each requirement record specifies a stage, a required field, and a validation message. The board evaluates requirements at transition time and disables the forward button with a clear explanation of what is missing. No manual oversight needed — the metadata configuration itself is the enforcement mechanism.
Action Center
Context-aware guidance appears on every work item. The Action Center shows what is needed to advance to the next stage — assign a developer, define acceptance criteria, complete code review — and blocks transitions when prerequisites are not met. Guidance adapts automatically based on the current stage and workflow type.
Phase Grouping
Stages are organized into phases: Planning, Development, Testing, and Deployment. Phases provide high-level progress visibility across the board and power analytics rollups. Each stage belongs to exactly one phase, and phases are displayed as visual groupings in the board header.
Dynamic Forms
Context-aware form layouts on all record pages, including the admin WorkItem page which uses Salesforce Dynamic Forms for field-section-level control. Fields shown adapt based on workflow type, current stage, and user persona. A developer in the Development stage sees code review fields; a client in UAT sees acceptance criteria and sign-off fields. No more irrelevant fields cluttering the screen — the form adapts to the context.
Dashboard Workflow Type Support
All dashboard components support workflow type filtering. Toggle between any of the seven built-in workflow types — or any custom workflow type — to see only the relevant metrics, charts, and activity. Time range toggles (7/30/60/90 days) apply across all dashboard views.
Three Custom Metadata Objects
The entire workflow engine is powered by three Custom Metadata Types. Together they define what workflows exist, what stages each workflow has, and what each persona sees on their board.
WorkflowType__mdt
Defines a workflow type
Each record represents a complete workflow definition — Software Delivery, Loan Approval, or any custom process. The WorkflowTypeTxt__c field on WorkItem__c links each work item to its workflow type. Adding a new workflow type is a single CMT record.
Examples: Software_Delivery, Loan_Approval
WorkflowStage__mdt
Defines stages within a workflow type
92 records across all seven workflow types: 37 for Software Delivery, 12 for Change Management, 11 for Implementation Project, 9 for Operations, 8 for Loan Approval, 8 for Support Triage, and 7 for Onboarding Checklist. Each stage specifies its display name, API value, card color, header colors, owner persona, phase, sort order, and transition rules.
Examples: Development, Code_Review, UAT, Deployed
WorkflowPersonaView__mdt
Controls board columns per persona
90 records for Software Delivery alone. Each record maps a persona (Developer, Client, PM, Admin) to a column name and the stages that appear in that column. Extended columns are collapsed by default. Sort order controls left-to-right column arrangement.
Examples: Developer sees Dev | Code Review | Testing
Stage Configuration
Every stage is fully configurable. Each WorkflowStage__mdt record defines these fields:
| Field | Description |
|---|---|
| API Value | Unique identifier used in Apex and LWC (e.g., Development, Code_Review) |
| Display Name | Human-readable label shown on the board column header |
| Card Color | Background color for work item cards in this stage |
| Header Bg Color | Column header background color |
| Header Text Color | Column header text color |
| Owner Persona | Which persona owns work in this stage (Developer, Client, PM) |
| Phase | Planning, Development, Testing, or Deployment |
| Is Terminal | Stage ends the workflow (e.g., Deployed, Cancelled) |
| Is Blocked State | Triggers blocked visual indicator on the board |
| Is Attention State | Triggers attention dot and urgency scoring |
| Forward Transitions | Comma-separated list of stages this stage can advance to |
| Backtrack Transitions | Comma-separated list of stages this stage can return to |
Persona View Example
The same workflow looks different depending on who is viewing it. Each persona sees only the columns relevant to their role.
How Transitions Work
Stage transitions are not free-form. Each stage explicitly declares which stages it can move forward to and which it can backtrack to. The board enforces these rules at runtime.
Technical Details
The workflow platform is built entirely on native Salesforce — Custom Metadata Types for configuration, Apex for query and resolution, and a single LWC that reads everything dynamically.
| Component | Details |
|---|---|
| DeliveryWorkflowConfigService.cls | 5 methods: getWorkflowTypes, getWorkflowConfig, getTerminalStageValues, getAttentionStageValues, getStagePhaseMap |
| WorkflowType__mdt | 7 records out of the box: Software Delivery, Implementation Project, Loan Approval, Support Triage, Onboarding Checklist, Change Management, Operations — extensible by subscribers |
| WorkflowStage__mdt | 92 records total (37 SD + 12 CM + 11 IP + 9 OP + 8 LA + 8 ST + 7 OC) with full color and transition config |
| WorkflowPersonaView__mdt | 90+ records defining column layouts for Developer, Client, PM, and Admin personas |
| DeliverySavedFilterController.cls | CRUD operations for saved board filter presets — save, load, delete per user |
| deliveryHubBoard LWC | Dynamic board powered by @wire(getWorkflowConfig) — saved filters, hide-empty-columns, zero hardcoded maps |
| WorkItem__c.WorkflowTypeTxt__c | Text(80) field linking each work item to its workflow type, default: Software_Delivery |
Action Center
The Action Center provides context-aware guidance on every work item. Instead of guessing what needs to happen next, the system tells you.
Prerequisites per Stage
Each stage can define prerequisites that must be met before a work item can transition forward. Missing a developer assignment? No acceptance criteria defined? The Action Center surfaces exactly what is blocking progress and prevents premature transitions.
Contextual Guidance
Guidance adapts based on the current stage and workflow type. A work item in Development shows different actions than one in UAT. The system knows what the next step should be and presents it clearly — no tribal knowledge required.
Transition Blocking
When prerequisites are not met, the forward transition button is disabled with a clear explanation of what is missing. This enforces process discipline without requiring manual oversight — the workflow configuration itself is the enforcement mechanism.
Ready to configure your own workflow?
The Configurable Workflow Platform is included in every Delivery Hub installation. Seven workflow types ship out of the box \u2014 Software Delivery, Implementation Project, Loan Approval, Support Triage, Onboarding Checklist, Change Management, and Operations. To create a custom workflow, add records to the three Custom Metadata Types and assign the workflow type to your work items.