We Built a Visual Workflow Engine for Pharma in 3 Weeks — Here’s the Architecture

We Built a Visual Workflow Engine for Pharma in 3 Weeks — Here’s the Architecture

If you’ve spent any time in regulatory operations, you know the drill: critical processes like document reviews, submission approvals, and safety report routing often live in a chaotic mix of email chains, shared drives, and manual follow-ups. Or, if you’re “lucky,” you’re using an enterprise Business Process Management (BPM) tool that cost millions, took years to configure, and still doesn’t quite speak the language of regulatory affairs.

We saw this problem repeatedly across our engagements with global pharma companies. And frankly, we were tired of it. So, we decided to do something radical: we built our own domain-specific visual workflow engine directly into the DnXT platform. And the best part? We shipped Version 2, a complete overhaul, in just three weeks. This isn’t just about speed; it’s about building purpose-fit pharmaceutical workflow engine technology that truly understands regulatory operations.

The Problem with Off-the-Shelf BPM for Regulatory

Traditional BPM tools are powerful, no doubt. Solutions like Camunda or jBPM offer incredible flexibility for general business processes. But for regulatory operations, they come with significant baggage. They’re often generic, requiring extensive customization to understand concepts like submission lifecycles, country-specific requirements, or the nuances of document types like SmPCs versus PI sheets. This customization adds immense cost, complexity, and a dependency burden that most pharma companies don’t need or want.

Our goal at DnXT has always been to provide highly specialized tools for life sciences, not generalist platforms. We realized that to truly empower regulatory teams with regulatory automation architecture, we needed a workflow engine that was inherently regulatory-aware, built from the ground up for their specific needs.

The Engineering Decisions: Build vs. Buy, and Why

The decision to build our own workflow engine was a strategic one. We evaluated several existing BPM solutions, but ultimately, they felt like bringing a bazooka to a knife fight. Our workflows, while complex, are also highly structured around regulatory artifacts and processes. We didn’t need the full BPMN 2.0 specification; we needed a powerful, intuitive, visual tool that regulatory professionals could actually design and manage themselves, without becoming IT experts.

This led us to a few key architectural choices:

• Database: Oracle Tables for Simplicity and Scale. Our entire platform runs on Oracle, leveraging its robust capabilities for tenant isolation, security, and scalability. Instead of introducing a separate workflow-specific database or graph database, we opted to extend our existing schema. We designed and implemented 17 new Oracle tables to manage everything: workflow definitions, individual workflow instances, task assignments, decision points, and a comprehensive audit trail. This approach kept our operational model simple and consistent.
• Visual Canvas Editor: Cytoscape.js. For the visual design canvas, we chose Cytoscape.js. Why? It’s a lightweight, powerful open-source graph visualization library that our front-end team was already familiar with. It allowed us to quickly build a drag-and-connect interface where users can intuitively design complex workflows by adding and linking nodes. We didn’t need a full-blown BPMN editor; we needed something that regulatory professionals, not developers, could grasp instantly.
• Domain-Specific State and Task Types. We defined a set of highly specific nodes tailored to regulatory operations. Our engine supports 11 distinct state types: Start, End, Human Task, System Task, AI Agent Task, Decision, Parallel-Split, Parallel-Join, Loop, Sub-Workflow, Wait, Error, and Terminate. Complementing these are 13 task types, covering everything from simple human approvals and data entry to complex system integrations, email notifications, and direct API calls to external systems.

We didn’t need a full-blown BPMN editor; we needed something that regulatory professionals, not developers, could grasp instantly.

Powering Regulatory Automation with AI Agents

One of the most exciting aspects of our new pharmaceutical workflow engine regulatory automation architecture is its deep integration with AI. We built in the ability to embed AI agent tasks directly into any workflow. This means a workflow can seamlessly transition from a human review to an automated AI action, and back again. We currently support 9 distinct AI agent types that can be dropped into a workflow:

• Document Classification
• Document Summarization
• Quality Checks (e.g., content consistency, compliance adherence)
• Metadata Extraction (from documents)
• Content Comparison
• Query Answering (RAG-based)
• Translation
• Data Harmonization
• Regulatory Intelligence Monitoring

The beauty of our AI integration lies in its abstraction. Each AI task node simply calls our internal AI Gateway service. The workflow engine doesn’t know or care which specific Large Language Model (LLM) or machine learning model is behind that gateway; it just sends a task and expects a structured result. This future-proofs our system, allowing us to swap out or upgrade AI models without impacting workflow definitions.

Handling Complexity: Parallelism and Compliance

Regulatory processes are rarely linear. A single submission, for example, might require parallel reviews from medical, legal, and commercial teams, each with their own deadlines and approval steps. Our workflow engine handles this with robust parallel branching capabilities. A “Parallel-Split” node can initiate multiple independent review streams simultaneously. A “Parallel-Join” node then brings them back together, with configurable conditions (e.g., “all must approve,” “any one approval,” or “majority approval”) to proceed to the next stage.

And, of course, for a pharmaceutical workflow engine, compliance is non-negotiable. Every single state transition within an active workflow instance is captured in a comprehensive audit trail. This includes who performed an action, when it happened, what the action was, and why (e.g., comments, decision rationale). This meticulous logging ensures full traceability and adherence to regulations like 21 CFR Part 11.

Why This Matters: Real Cloud-Native Regulatory Technology

Building something this ambitious in just three weeks might sound impossible, but it’s a testament to a focused team, deep domain knowledge, and owning the full technology stack. We didn’t spend months integrating with a third-party BPM; we built exactly what we needed, precisely how we needed it.

This is what “cloud-native regulatory technology” truly means at DnXT. It’s not just about hosting legacy software in the cloud. It’s about designing and building purpose-fit, highly efficient, and intrinsically intelligent tools that leverage the power of the platform and integrate seamlessly with AI from day one. It means pharmaceutical companies can deploy sophisticated regulatory automation solutions in weeks, not years, and start seeing real value faster.

We’re incredibly proud of what our team accomplished. This workflow engine is already transforming how our clients manage their regulatory operations, moving them away from manual drudgery towards intelligent, automated processes.

See the Workflow Engine Demo