Skip to content

Dynamic JSON Schema & Workflows

Instead of maintaining brittle database migrations every time a new client has a slightly different factory process, Foot Factory utilizes a meta-driven approach.

The Problem

A shoe factory (Mascot) requires Steps: Cutting -> Upper -> Bottom -> Packing. They need to track Color and Sole Type on their products. An umbrella factory requires Steps: Frame Assembly -> Canopy -> Quality Check. They strictly need to track Canopy Pattern and Rod Material.

The Solution

A single MongoDB Collection: TenantConfig.

{
  "tenantId": "5f9c...",
  "jobSteps": [
    { "name": "Frame Assembly", "order": 1, "isPaid": true },
    { "name": "Quality Check", "order": 2, "isPaid": false }
  ],
  "articleAttributes": [
    { "name": "color", "label": "Color", "type": "string", "isRequired": true },
    {
      "name": "material",
      "label": "Material",
      "type": "string",
      "isRequired": true
    }
  ]
}

1. Super Admin Schema Builder

The Super Admin dashboard (dot-foot-factory-admin) provides a graphical UI to drag, drop, and configure this JSON array at onboarding time. It pushes the schema via POST /api/v1/tenant-config.

2. Client Dashboard Parsing

The overarching provider TenantConfigContext.tsx in the Client application fetches GET /api/v1/tenant-config/:myTenantId when the client logs in.

  • Forms: The Article.tsx loops over articleAttributes to dynamically mount Input fields (rather than having hardcoded HTML templates).
  • Wages: The Job.steps inherently loop over the config's jobSteps assigning task-inputs conditionally.

3. Backend Execution

The backend Job schema drops hardcoded relationships (cuttingWorkerId, bottomWorkerId) and replaces them with an array:

"steps": [
   { "stepName": "Frame Assembly", "workerId": "abc1234", "status": "Completed" }
]

When Job.steps transitioning logic sees "Completed", it credits the Ledger instantly utilizing the dynamic steps Array, eliminating hardcoupled SQL columns entirely.