Anatomy of a sample: the basic SENAITE workflow

A sample in SENAITE is not a record you edit freely. It moves through a fixed sequence of states, and the state decides which fields can still be changed, which buttons appear and who may press them. When a user reports that a button is missing, the answer is almost always the state of the sample, or the state of one of its analyses.

This is the path a sample takes when nothing goes wrong. The walkthrough below follows a drinking water sample with three analyses: pH, conductivity and nitrate.

Registered

A clerk registers the sample in the add form, or a client contact registers it through the client portal. It lands in Registered and leaves that state immediately. The next state depends on one setting. With the sampling workflow switched off (the default), the sample moves on to Sample due. With it switched on, it goes to To be sampled and waits for a sampler to record who took it and when.

Sample due

The lab knows the sample is coming but does not hold it yet. This is the state for printing labels in advance, so the bottles go out to the sampling point already marked with their ID.

The step to Received has one precondition that catches people in their first week: the sample needs a Date Sampled. Without it the Receive button does not appear. If clients register their own samples and leave the field empty, reception stalls until someone fills it in.

Received

Receiving is the moment the lab accepts the physical sample. The clerk checks container, preservation and holding time, selects the sample in the listing and clicks Receive. SENAITE stamps the reception date with the current time and makes the analyses ready for work: from now on they can be put on worksheets, and results can be entered.

If your lab registers only samples it already holds, the setup option Auto-receive samples skips this manual step.

The sample stays in Received while the analysts work. There is no separate “in testing” state.

To be verified

Nobody presses a Submit button on the sample. Analysts submit results on the analyses, either in the sample view or on a worksheet. When the last analysis that counts is submitted, the sample follows on its own and moves to To be verified.

“That counts” matters here. Analyses that were cancelled, rejected or retracted are left out. If the nitrate analysis was rejected because the bottle was not acidified, the sample moves on once pH and conductivity are submitted.

Verified

Verification also happens per analysis. A user with the Verifier or Lab Manager role reviews each submitted result and verifies it. When all analyses are verified, the sample becomes Verified automatically. How many verifications a result needs, and whether the submitter may verify their own result, are setup decisions; the post on multi-level verification covers them.

From this point on, a client contact with portal access can see the results, even before a report is published.

Published

Publishing generates the results report and moves the sample to Published. In practice that happens when the report is sent by email from the publish view, or when it is marked as published in the reports listing. Sending a report again later is a Republish and leaves the sample in Published.

A report can also go out before every analysis is verified, as long as at least one result has been submitted. That is a Prepublish: the client gets the preliminary results, and the sample keeps its state until the rest is done.

The ways back

The happy path is the easy part. The states matter most when a result turns out to be wrong.

Before verification, a Lab Manager retracts the analysis. The retracted result stays in the record, a retest of the same analysis takes its place, and the sample drops back from To be verified to Received. The same rollback happens when someone adds an analysis to a sample that was already waiting for verification.

After verification, results can no longer be changed. The way out is to invalidate the sample. It moves to Invalid and keeps its results and report as they were, and SENAITE creates a retest sample with the suffix -R01 that starts in Received. The record shows both what was reported and what replaced it.

Before any work, a sample registered by mistake is cancelled. Cancelling is possible while no result has been submitted, and Reinstate undoes it. A sample that arrived unusable is rejected instead. Rejection needs the rejection workflow enabled in the setup, and it cannot be undone.

What to decide before go-live

Three settings shape this workflow more than any other:

• Sampling workflow. Only if your staff collect samples in the field and you need to record the sampler.
• Auto-receive samples. Useful for in-house labs that create samples for material already on the bench. Contract labs usually want the explicit reception check.
• Rejection workflow. Enable it with a short list of rejection reasons (“container broken”, “insufficient volume”) if you need to tell clients why a sample was not tested.

Everything else builds on these states. Partitions run through the same workflow as their primary sample, and dispatch and dispose add an end of life for the physical material.

The record of who did what

Every transition is written to the sample’s history with the user, the time and, where the form asks for one, a comment. When a client asks who verified a result and when, the answer is stored with the sample.