Your QMS stores the SOP. It does not prove the SOP is alive.

Let us be fair to the tools first, because the fair version is the useful one. Veeva Vault and MasterControl are strong document vaults. If your controlled SOP needs version control, an approval workflow, an audit trail on the document itself, and retention that survives an inspection, that is what these systems do, and they do it well. For a GDP-regulated pharma logistics operation, the QMS is the right home for the controlled document. This piece is not an argument to rip it out.

It is an argument that the vault answers a narrower question than most teams assume. A QMS proves a controlled document exists and is the current version. It does not route that document by scenario, does not show the process is actually being run on the floor, and does not resolve to the exact steps for this shipment. Those are different jobs, and no document vault was built to do them.

What the vault proves, and what it cannot

Picture an assessor tracing a real consignment: a temperature-controlled pharma pallet that also carried a dangerous goods item, accepted on a late shift. In your QMS you can produce the acceptance SOP, version 6, approved and signed. Good. Now the harder questions arrive. Which of the fourteen pages applied to this specific build? Where did the dangerous goods exception route sit relative to the cold chain handling step? Who executed each step, and against which version, on that night? The vault has the document. It does not have the run.

That is the structural limit. A document store is a record of the SOP. It is not a record of the process. The two are easy to conflate because the SOP describes the process, but a description is not evidence of execution. The gap between the approved document and the executed work is precisely where the most common GDP and GxP finding lives: SOP not followed. The vault cannot close that finding because it cannot see the floor.

Three things a document vault does not do

• It does not route by scenario. The vault serves the same flat document to everyone. It cannot resolve a single master SOP down to your steps, for this shipment, in this situation, with the dangerous goods and excursion exceptions pulled in. That resolution has to happen in someone's head, and that is where steps get dropped.
• It does not show the process is being run. An approved SOP in the vault is silent about whether anyone followed it today. There is no live signal that the procedure and the practice are the same thing. You find out they diverged when an auditor pulls a thread.
• It does not resolve to the right steps for this shipment. The vault gives you the whole document and leaves the filtering to the operator. Under a cut-off, at night, that filtering is exactly the work that fails.

The empty middle in the regulated stack

Look at how the regulated logistics stack actually splits. On one side, the monitoring vendors sell the sensor: they prove the temperature. On the other, the QMS vendors sell the vault: they prove the document. Both are legitimate and both are strong at their job. But neither owns the living, governed process that sits between them, the logic that says for this shipment, in this scenario, here are the exact steps, here is who owns them, here is the version in force, and here is the trail showing they were run. That uncontested middle is where the findings cluster, because it is the layer nobody is keeping true.

This is the same gap that makes GDP inspection readiness feel like a project instead of a state, and the same reason a temperature excursion investigation so often turns into an archaeology dig. The document was fine. The record of the process was scattered across heads, chat threads, and a diagram that went stale on export.

Keep the QMS. Add the living process.

The move is not replacement, it is addition. The controlled SOP stays in Veeva Vault or MasterControl, where document control belongs. On top of it sits a living process that carries the operational logic: one master process that resolves to the exact route for the situation, with owners, versions, sign-off, and an audit trail of execution. The living process feeds the controlled document, so the SOP in the vault reflects how the work is actually run, and it proves the document is current and followed rather than merely stored.

If you have ever asked why not just run this in ServiceNow, the answer is that execution platforms run the process after you have figured it out and written it down. They are downstream of the design. The living process is where the logic is authored and kept true in the first place, and it can feed both your QMS and your execution platform. Most teams who work through it end up wanting both, which is the honest read in the FLOW and ServiceNow comparison.

Where FLOW fits

FLOW is the living process layer above the vault. Your SOP lives as one master process that resolves to the exact steps for the shipment and scenario in front of the operator, exceptions and all, carrying owner, version, sign-off, and an audit trail of who did what against which version. It keeps your QMS exactly where it is as the controlled document store and feeds it a process that is provably alive and followed. That is the direct handle for the quality leader who says we already have a QMS: you keep it, and FLOW is the living process that proves the SOP is current and adhered to, not just filed. The category argument is in the process system of record, and the process graveyard audit will tell you in ten minutes how many of your controlled SOPs are quietly being worked around on the floor right now.

Common questions