I've sat through a lot of eQMS demos. The salesperson opens a neat document register, shows a form, signs it off electronically, and calls that "workflow automation." In practice, for regulated medtech work (ISO 13485, MDR, 21 CFR 820) that's only half the problem. Digitizing forms is necessary — but what I really need is a process server: a system that executes rules, timers, escalations, and integrations so the work flows to the right people at the right time without the QA team manually chasing it.
Below I share what I actually look for when I evaluate eQMS vendors for Class II-ish devices, what I learned from demos (yes, one vendor had a built-in Workflow Process Editor), and practical gotchas to watch for when you want true connected workflow instead of glorified e-forms.
Why forms alone are not enough
Paper chase -> e-form is a visible improvement, but:
- Forms still rely on human follow-up unless the system enforces and routes tasks.
- Conditional branches (if things are risky, go to CAPA) are often handled by a checkbox + manual email, not by the system.
- Timing and escalations (X reviewer hasn't responded in 3 days, escalate to manager) are handled outside the QMS in spreadsheets or ticket systems.
- Integrations (trigger a JIRA ticket, kick off a build review, notify a supplier portal) typically require custom work.
Regulators expect evidence that your QMS procedures are followed and reviewable. That evidence is far easier to produce when the system is the active enforcer of the process (and when the process itself is versioned and auditable).
What I mean by a "process server" in an eQMS
A process server is the component that executes and enforces your business process definitions. In practical terms it should give you:
- A workflow builder/editor (visual or declarative) where you can define nodes, transitions, conditions, timers, and role assignments.
- Runtime execution: the system runs instances of those workflows, tracking state, timestamps, and responsible users.
- Escalation and SLA enforcement (timers, reminders, auto-escalation).
- Conditional branching and sub-workflows (e.g., risk > threshold -> route to RA + open CAPA).
- Integration primitives: webhooks, REST API calls, and connectors to ticket systems, CI, or supplier portals.
- Auditability: immutable event log per workflow instance, version history for process definitions.
- Change control for the workflows themselves: treat process definitions as controlled artifacts.
- A sandbox/testing mode so you can validate a change to a workflow without impacting production.
I saw a demo where a vendor had a "Workflow Process Editor" built-in — that was promising. But having an editor doesn't mean the workflows are safe, testable, or easy to govern.
Real example: automating CAPA routing (what I built mentally during demos)
A CAPA should not be a manual hand-off. A workable automated CAPA flow looks like:
- NCR logged (form filled) -> process server creates CAPA instance.
- Auto-assess risk based on inputs; if high, assign RA reviewer in parallel with QA.
- If owner does not accept assignment in 48 hours, escalate to manager (timer + auto-escalation).
- When root cause is entered, trigger a template-populated CAPA report and open a linked JIRA dev task (API).
- When verification is marked complete, process server closes CAPA and records timestamps; notifications and CAPA metrics update automatically.
That level of automation reduces manual follow-up and gives you consistent, reviewable evidence during audits. It also forces you to think through decision criteria (which is good under MDR/ISO).
Practical validation and governance concerns
A process server isn't magic — it introduces new validation and governance work:
- The workflow definitions are part of your QMS: they need version control, change control, risk assessment, and release notes.
- You must validate the automation (CSV): testing scripts, test cases for conditional paths, and evidence of successful runs.
- Training: people need to understand automated hand-offs; automation can create new failure modes if misconfigured.
- Vendor lock-in and migration: workflows can be proprietary. Ask how to export definitions and instance logs for migration or audit.
Document and Record Control is the first critical process to define before everything else. If your eQMS can't make that process enforceable and auditable, you've only moved the paper into a database.
Integration and developer ergonomics I actually care about
If you're going to treat an eQMS as an active process engine, the technical surface matters:
- RESTful APIs and webhooks for event-driven integration (not just occasional exports).
- Idempotent endpoints, retries, and clear error handling for automation stability.
- A sandbox environment and CLI or IaC-friendly way to script deployments (we use these during validation).
- Clear schema for exported audit logs so you can ingest them into analytics or SIEM for monitoring.
If the eQMS's "automation" is limited to email alerts and forced electronic signatures, you won't gain the efficiency or traceability you'd expect from a process server.
Buyer's checklist — quick must-haves before you commit
- Visual workflow editor + runtime execution
- Versioned process definitions under change control
- Timers, escalations, conditional branching
- REST API + webhooks; example integrations (JIRA, SCM, CI)
- Audit log per workflow instance, tamper-evident
- Sandbox/test environment and validation support
- Exportable process definitions/instance logs for migration or audit
Final caveats from my demos
I evaluated several vendors. Most treat workflows as templates that create tasks; only a few actually execute a state machine with timers and conditions. One vendor I demoed had a built-in Workflow Process Editor which checked several boxes, but we paused because we couldn't get comfortable with how workflows would be governed and validated at scale.
Automation should help you satisfy ISO 13485 and MDR evidence requirements, not create more undocumented behavior that you then have to explain in an audit.
What have you actually put into production as a process server inside an eQMS, and how did you validate and govern those workflows for audits?
