I spent most of last quarter evaluating eQMS platforms for a manufacturing function that handles roughly 40 suppliers on behalf of three OEMs. Every demo ended the same way: the "workflow engine" turned out to be a form builder with conditional fields, an email step, and a status column.
This post is the genuine ask, framed from the supplier side. If you're a small to mid-size medtech manufacturer (Class I to IIb, two-person QA/RA, a CAPA queue that keeps you up, change control that lives in someone's inbox), here's what I think you're actually hunting for and why most shortlists quietly collapse.
The form-builder trap
A form builder lets you do this:
- Define a CAPA form with fields
- Add conditional routing — "if Risk = High, route to QA Manager"
- Send an email when the form is saved
- Show a status column in a list view
That covers maybe 30% of what ISO 13485 §4.1.4 and 21 CFR §820.40 actually ask for from process control. The other 70% is process behaviour: state machines, parallel branches, SLA escalation, rollback on rejection, automatic re-trigger when a related record changes, and an audit trail at the process-instance level — not just the form-revision level.
The litmus test I now use in demos: when a user clicks "Reject" mid-flow, does the system know what state the record should return to, who needs to be notified, whether dependent records are now invalidated, and what the regulatory significance of that rollback is? Form builders hand-roll each of those rules as field logic. Real process engines model them inside the workflow definition itself.
What the standards actually ask for
ISO 13485:2016 §4.1.4 wants processes to be planned, monitored, and records that "provide evidence that the processes are carried out as planned." §8.5.2 (CAPA) and §8.5.6 (control of changes) want documented procedures, plus verification of effectiveness.
21 CFR §820.40 spells it out for CAPA — documented procedures that include requirements for:
- analysing process and quality data to identify nonconformities
- investigating the cause of nonconformities
- verifying that the corrective action does not adversely affect the ability to meet regulatory requirements
- implementing and documenting changes
That last bullet — changes — is where form builders consistently fall over. In our world a CAPA triggers a change in an incoming inspection plan, which then has to push to a supplier corrective action request, which may itself loop back as a new CAPA. A form builder wants three separate forms with three separate workflows and a tired human gluing them together at every step.
What a real workflow engine gives you
In my current stack — custom Python + Postgres, rebuilt twice in five years — these are the things I'd refuse to give up:
- A state machine per record type. Not field values driving routing. An explicit model of states and transitions, with the audit trail living on the transitions themselves.
- Process-instance IDs that survive across modules. A CAPA that triggers a change triggers a risk re-assessment. The engine should use one ID that traces through all three.
- SLA escalation that is configurable, not scripted. When the CAPA owner hasn't responded in 14 days, the engine routes to their manager — it does not only send a reminder email.
- Conditional subprocesses that can run in parallel. A risk re-assessment might need input from regulatory while a document update goes to document control simultaneously.
- Replayable history. When a notified body or an OEM customer asks "show me every state this CAPA has been in," I want a query answer, not a screenshot chain.
The honest shortlist criteria
If I were rebuilding the shortlist today for a small medtech team with limited bandwidth, I'd ask each vendor four things:
- Show me a CAPA workflow with parallel branches, a rollback path, and an SLA escalation. Show me the process definition, not the form.
- When a CAPA closes and downstream records are still open, does the engine know — or does it require a human?
- Show me the audit trail for a process instance, not a form revision.
- Show me a change request that automatically triggers CAPA, risk, and document control records — and trace the linkage between them with one ID.
If they can only show form revisions and email logs, you have a form builder. The branding won't save you.
What I'd do differently next time
I'd stop shortlisting from feature comparison spreadsheets. The features matter, but the architecture underneath does more of the work. I'd ask for a reference customer in the same regulatory class, ask to see their worst-case workflow (not the demo workflow), and ask what the vendor cannot do. That last question has saved me more time than any demo.
If you've actually seen a platform handle the CAPA → Change → Risk loop without a human being the glue, I'd genuinely like to know which one. The shortlists I keep building collapse back to form routing, and I'd like to know what a real option looks like.
Top comments (0)