Skip to content
02Part 2 of 3One mycoplasma test, from the SOP to the signed record

How do you turn a written protocol into a workflow the bench can run?

An SOP becomes a runnable workflow: steps, materials, a wait the software enforces, a QC checkpoint, and a released version every run names.

6 min readArticle 002

02OperationsWorkflows, inventory, orders

Short answer / Operations

Break the protocol into steps, each with its materials, equipment, time and the data it records. Turn timing rules into enforced waits between steps and pass or fail rules into checkpoints, so the run applies them. Then validate the workflow, compare it with the last version and release it. Each experiment runs from one released version and names it.

An SOP says "collect the medium at least 72 hours after the last feed". A workflow makes the collect step impossible to start before then. That's most of the difference between the two, and it's why I think an SOP on its own isn't enough for anything a lab runs every month.

Our example lab has just released version 4 of its mycoplasma SOP. It adds an internal control to every PCR well, so a failed reaction can't pass for a clean sample, and it moves the sampling wait from 48 to 72 hours. None of that helps until it's in what the bench actually runs. So this is how v4 became version 3 of the lab's "Mycoplasma PCR screen" workflow, what each rule turned into, and what that costs.

What is the difference between a protocol and a workflow?

A protocol is written for a person to read. A workflow is the same method as steps that software can schedule, run and record against. The protocol explains the method; the workflow is what actually runs.

Just look at the 72-hour rule. In the SOP it's one sentence in section 2, and it relies on someone remembering on Thursday morning when the cultures were fed on Monday. In the workflow it's a delay on the connection between two steps. The runner counts it down and won't start the next step until it's done.

The SOP still matters. It's where the reasoning lives, and nobody should run a method they don't understand. But the SOP is read once and skimmed after that. The workflow is there every time.

How do you break a protocol into steps?

Make one step for each thing a person does in one sitting and can check at the end. For the mycoplasma screen, that gives six steps and one wait.

# Step What it carries
1 Feed cultures, antibiotic-free Medium without antibiotics, 15 minutes
72-hour wait Was 48 hours in v2
2 Collect and heat spent medium Heat block, 30 minutes
3 Set up the plate The SOP, three mix components, 30 minutes
4 Run the PCR The qPCR instrument, 90 minutes
5 Check the plate controls A QA/QC checkpoint
6 Record and call the results A data table, sealed when submitted

The mistake I'd expect is too many steps, not too few. A workflow with forty steps of "pipette 5 µL" gets clicked through, and a record nobody reads while they're making it is probably worse than a short honest one.

Which rules should the workflow enforce?

The ones where a mistake gives you a believable wrong answer. v4 has three, and each became a different kind of thing.

  • The 72 hours became a mandatory wait. Start stays disabled until it has elapsed. Someone can still start early with Override Mandatory Wait, but it asks for a reason and records who did it. The wait also keeps counting if the run is paused, because the cultures don't stop growing when someone goes to lunch.
  • The internal control became a material. Step 3 now lists the primer and probe mix with the internal control, 35.2 µL, from inventory. Scheduling the experiment reserves it against a lot. A lab that has never stocked it finds out when it schedules, not at the bench on the day, and the first lot gets a check run before it's released for use.
  • The control check became a QA/QC checkpoint. The positive control has to come up and the no-template control has to stay clean. "Pass continues. Fail ends the experiment." Nobody reads sample results off a plate whose controls failed.

That said, enforcement has a cost. A gate that's wrong is worse than a sentence that's wrong, because people can't use their judgement around it. The override exists for that reason. It's a recorded exception, which is a lot better than a workaround.

Where do the results go?

They go into a table whose columns are fixed before the run, so every month's results have the same shape.

The "Mycoplasma PCR results" table has four columns: the sample, the target Ct, the internal control Ct, and a Call column that works itself out from the other two.

IF(target_ct < 35, "Positive",
  IF(target_ct < 40, "Inconclusive",
    IF(ic_ct < 32, "Negative", "Invalid")))

No amplification is entered as 40, the last cycle. Each sample runs in two wells, and its row takes the earlier target Ct and the later internal control Ct of the pair, never the average, so one bad well can't hide behind a good one. A late target signal is Inconclusive and gets retested, and a sample with no signal in either channel reads Invalid. The paper version of the same result is usually "myco neg, all OK" and a photo, which tells you what someone concluded but not how.

The table is locked at the bench. You can't add a column mid-run, and that will annoy someone eventually. We did it on purpose: a column added on the day is a column the next run won't have, and then two months of results don't line up.

Why does the workflow need its own version number?

Because a result has to name exactly what ran, and the SOP number alone doesn't do that. In CCA Labs a routine experiment can't run from a draft. It's built from one released version and keeps it, even after the next release.

Releasing v3 went like this. The editor's check found two things first: an error, because the new primer and probe mix had no quantity, and a warning, because the checkpoint, copied from step 6, still had step 6's title. Errors block a release and warnings don't, but both were worth fixing.

Compare draft against v2 showed the three changes and nothing else, which is the check that matters. Then Release This Workflow, with release notes naming SOP v4. This lab's policy asks for a signature on a workflow release, so it was Sign to Release, by the lab manager. Released versions can't be edited, releasing an identical workflow is refused, and version numbers are never reused.

What doesn't it do?

A few things, and it's better you hear them from me.

  • The step links the SOP document, not a particular release of it, and the bench sees the document as it currently stands. The version that's pinned is the workflow's. Salavat covers what that means for SOP control in how a lab should control its SOP versions.
  • There's no separate review-and-approve step before a workflow release. Releasing needs an Admin, and a signature if your policy asks for one.
  • Nothing talks to the qPCR instrument. The Ct values are pasted in from its export, which the table accepts straight from a spreadsheet.

Building one in CCA Labs

You can build a workflow as a flowchart or as a list; they're two views of the same thing. Steps come as Operation, Incubate (hold samples on an instrument and capture its sensor data), QA/QC Checkpoint and Alert. Loops have an exit condition and a maximum number of passes, and delays sit on the connections between steps.

A step can carry materials, from inventory or from an earlier step's output, and its equipment, documents, data tables, time and labour. Workflow Stats then adds up total time, waiting time and cost per run. It's all on the all-in-one lab page, and you can create your lab to build your own.

Released on a Wednesday, v3 still needs a week to happen in. The cultures get fed on Monday, a reagent the lab has never stocked is still on its way, and the plate is on Thursday. The workflow doesn't plan any of that. People do, and that's the next part: how a lab team plans its week at the bench.

The whole story / one floor at a time

One mycoplasma test, from the SOP to the signed record

One routine test, followed through a lab: the monthly mycoplasma PCR that clears the example lab's new HEK293 cell bank. Operations releases a new SOP and builds it into a workflow, the bench plans the week and runs the plate, QA signs the record, and what the run taught goes back into the SOP. Each part is written for the people on that floor.

Next, on floor 04How should a lab team plan its week at the bench?

FAQ / asked about this

Frequently asked questions

What is the difference between a protocol and a workflow?
A protocol, or SOP, is written for a person to read and follow. A workflow is the same method as structured steps that software can schedule and run, with materials, equipment, waits, checks and data fields attached, and it records what happened at each step. The SOP explains why; the workflow is what gets run.
Should every protocol become a workflow?
No. Work you repeat, such as QC tests, passaging, banking and standard assays, gains the most, because its rules and data are the same every time. A one-off exploratory experiment can be recorded more loosely, and forcing it into a rigid workflow first mostly slows it down.
What happens to running experiments when a workflow changes?
Nothing. In CCA Labs an experiment is built from one released workflow version and keeps it. A new release only applies to experiments created from it afterwards, so the record of a past run never changes under it.

Run the whole lab in one system

Start with one team. Add workspaces as the work grows.