Skip to main content

B2B SaaS Workflow Automation Platform

Designing dynamic workflow orchestration and document automation in an AI-driven B2B SaaS platform.

~10 months · 2022 — 2023 (Actyv.ai)
B2B SaaSWorkflow EngineCamundaAutomationDistributed Systems

Context

In an AI-driven B2B SaaS platform, clients required configurable business workflows — loan processing, vendor onboarding, document validation, and third-party API orchestration.

The existing implementation relied on hardcoded workflow logic embedded inside backend services. This made onboarding new clients slow and risky, since every new workflow variation required code changes and redeployments.

The goal was to design a system that allowed dynamic workflow configuration without rewriting core services for each new business process.

Architectural Direction

I introduced a workflow orchestration layer using Camunda, supported by:

  • Dynamic schema design in MongoDB
  • Node.js/NestJS backend services
  • Node-RED for external API automation
  • Asynchronous document processing services

The system moved from static workflow code to declarative workflow configuration.

System Design

Design principle: separate business process definition from business logic execution.

Key Architectural Components

  • Workflow Engine (Camunda) — Orchestrated multi-step business processes.
  • Dynamic Data Model (MongoDB) — Supported flexible document structures per client.
  • API Automation (Node-RED) — Managed third-party integrations without tightly coupling them to core backend services.
  • Document Processing Microservices — Handled PDF conversion, parsing, and OCR workflows asynchronously.

Dynamic Workflow Configuration

Previously, adding a new client workflow required:

  • Backend code changes
  • Manual branching logic
  • Redeployment cycles

After introducing workflow orchestration:

  • Business processes were modeled declaratively.
  • Task routing and conditional paths were configurable.
  • Backend services remained stable while workflows evolved.

This reduced engineering dependency for workflow customization.

// validate-document-handler.ts — Camunda external task worker.
// One BPMN service-task type, many client-specific schemas.
import { Client, Variables } from "camunda-external-task-client-js";

const client = new Client({ baseUrl: process.env.CAMUNDA_REST_URL! });

client.subscribe("validate-document", async ({ task, taskService }) => {
  const docId = task.variables.get("documentId") as string;
  const schema = await schemas.loadForTenant(task.tenantId!);

  const doc = await documents.fetch(docId);
  const extracted = await ocr.extract(doc, schema.extractionRules);
  const errors = validate(extracted, schema.validationRules);

  const out = new Variables();
  out.set("extractedFields", extracted.fields);
  out.set("isValid", errors.length === 0);

  if (errors.length === 0) {
    return taskService.complete(task, out);
  }
  // BPMN error bubbles up to the modeled error boundary event — no code path
  // in the worker, no redeploy when a new error-handling branch is added.
  return taskService.handleBpmnError(
    task,
    "VALIDATION_FAILED",
    errors[0].message,
    out,
  );
});

Document Automation

A major bottleneck was manual document validation.

I engineered microservices responsible for:

  • PDF conversion
  • Structured data extraction
  • OCR processing
  • Normalization before persistence

Processing was asynchronous, ensuring API responsiveness while heavy document workloads ran in the background.

Advanced MongoDB aggregation pipelines were used to optimize retrieval and reduce response latency.

Tradeoffs

Why Camunda instead of custom state machines?

A custom solution would have required significant development effort and ongoing maintenance. Camunda provided visibility, monitoring, and extensibility out of the box.


Why MongoDB for dynamic schemas?

Client workflows varied significantly in structure. A relational schema would have required frequent migrations. MongoDB allowed flexible document shapes while preserving indexed query performance.


Why keep it modular instead of microservices?

Operational simplicity. The platform did not yet require distributed service boundaries, and keeping workflow orchestration inside a modular architecture reduced infrastructure overhead.

Outcomes

  • Reduced workflow deployment time for new clients.
  • Improved API response times through aggregation optimizations.
  • Automated repetitive document validation steps.
  • Reduced third-party integration complexity via the Node-RED abstraction.
  • Increased system flexibility without increasing operational burden.

Reflection

What worked

Separating workflow orchestration from core services was the most impactful decision. It allowed rapid business iteration without destabilizing backend logic.


What I'd improve

  • Introduce formal workflow versioning strategy.
  • Add observability layer specific to workflow state transitions.
  • Consider event streaming for higher throughput use cases.

Future direction

  • Gradual extraction of workflow components into isolated services if scale demands.
  • Introduce schema validation registry for dynamic MongoDB structures.
  • Expand AI-assisted workflow configuration capabilities.