Form builders are not workflow engines: a CMO's eQMS shortlist problem

The form-builder trap

I have built an eQMS shortlist six times in the last three years. Twice for the CMO I work at, once for a friend running a Class IIa startup in Eindhoven, three times for consulting engagements. Every single shortlist collapses the same way: five vendors, four of them are form builders with branding.

That is not quite fair. They are very good form builders. The validation is solid. The audit trail is there. The e-signatures work. But when I ask the demo engineer to show me how their workflow engine handles a real cross-object flow — say, an incoming COA fails a critical spec, triggers a non-conformance, opens a CAPA, and routes the CAPA to the supplier-quality engineer and the OEM customer's complaint owner in parallel — the answer is almost always: "you can configure that with our form rules."

Form rules. Not a process engine. Not an event-driven workflow. Rules on a form.

What "process engine" means at a CMO

At a contract manufacturer, supplier quality is a different shape than it is at an OEM. I have 42 active suppliers, three OEM customers, and I receive close to a thousand certificates of analysis a quarter. The work is not "device history record management." The work is cross-record orchestration:

• A COA lands in our supplier portal. I need it parsed, the values checked against the incoming inspection spec, and the result routed without a human touching it unless something is off.
• If a value is off, a non-conformance opens automatically, attaches to the lot, and triggers an automated supplier CAPA.
• The CAPA has to link to the right OEM customer complaint record, because their notified body audit is in eight weeks and they need to show a connected workflow between their field signal and my supplier signal.
• When the supplier responds, my QA reviewer has to be able to see the chain — COA, NC, CAPA, root cause, effectiveness check — in one place. Traceability is not a report. It is the system.

That is a process server. That is event routing. That is a state machine for a quality record. None of that is "form rules."

What I look for in a demo

I have started carrying a checklist. The questions that separate a real process engine from a form builder:

• Can I model a state machine, not just a sequence of steps? Real CAPAs branch. They reopen. They get parked. They have sub-states. The state machine is the workflow; a form with checkboxes is not.
• Can a transition on Object A trigger actions on Object B without me writing a custom integration? If the answer is "use our API and a webhook," that is an integration tax.
• Are SLA timers, escalations, and parallel routing first-class? Or are they "available in the enterprise tier"?
• Is the audit log structured around events, or around field changes? I need to answer "what happened to this lot between receipt and disposition" in one query, not by stitching six reports.
• Can I version a workflow? When the CAPA process changes after the next notified body audit, the old CAPAs need to run on the old workflow. Form rules do not version well. (This is the part where I pause, refill the filter coffee, and ask the demo engineer to take the question again, slowly.)

Where qmsWrapper fits, and where it does not

I should disclose something here. I work on qmsWrapper. I build the supplier-side automation on top of it. So my view is biased and I say so plainly.

qmsWrapper is built for device makers and SaMD teams. The way change, CAPA, risk, and document control actually link to each other is genuinely well done for that buyer. If you are a Class IIa team in the Netherlands with two QA people and a mounting CAPA queue, the native workflow integration will save you from a lot of glue code. Every state change is logged, every approval is traceable.

What it is not built for, and where I would push back, is the CMO supplier-quality side. There is no first-class supplier COA object. There is no incoming inspection workflow out of the box. I run that layer in Python and Postgres on my side, which is fine for me, but if you are a smaller CMO without an automation person, the gap is real. The marketing page does not pretend otherwise; the partner pitch from resellers sometimes does.

I work on qmsWrapper and have given my honest read of where it does not fit a CMO supplier-quality use case.

The CMO shortlist that actually works

The platforms I have seen that pass my five questions tend to fall into two buckets. The first is enterprise QMS that costs as much as a flat in Whitefield and assumes you have a QMS administrator. The second is BPM-first platforms that have a real process server, and a QMS-shaped skin on top, but the skin is thin.

I have not found a mid-market eQMS that is genuinely process-engine-first and CMO-shaped. If you have, I want to hear about it.

What am I missing?

If you are running supplier quality at a CMO or a contract testing lab, what does your eQMS actually do for cross-record orchestration? Which vendor surprised you? Which one disappointed? I am especially interested in platforms that handle the supplier COA → NC → CAPA → OEM complaint chain as one connected workflow, not four separate forms with email notifications between them.