Anatomy of a sample: the basic SENAITE workflow

Every sample in SENAITE moves through the same five states on the happy path. Learning them takes ten minutes. The rest of the system (worksheets, verification, reporting) is just detail hanging off this backbone.

The five states

1. Sample due (sample_due). The sample has been registered but hasn’t yet arrived. Useful when clients book jobs in advance.
2. Sample received (sample_received). Physically at the lab. Reception time is stamped. Analyses now sit on worksheets or on the sample itself; analysts submit results. The sample stays in sample_received until every analysis on it has been submitted.
3. To be verified (to_be_verified). All analyses have been submitted. A different user with the right role now needs to confirm them.
4. Verified (verified). Results are approved and locked. Nothing changes without an amendment.
5. Published (published). The report has been generated and sent. Anything downstream (client portal, PDF, invoice) hangs off this transition.

There is no separate “to be tested” state — the analysis work happens inside sample_received. The sample state advances when the last analysis reaches its next state.

Why the state matters more than the buttons

Every button in the SENAITE UI is a transition between two states. Once you know which state you’re in and which state you want to reach, the interface stops being a maze. The buttons available at any moment are exactly the ones the current state allows.

The audit log is your friend

Every transition writes a log entry with a user and a timestamp. That log is the entire chain of custody for the sample. If a customer asks “who verified this and when?”, one click answers it.

The advanced workflows (retractions, invalidations, sample partitions, dispose and dispatch) all sit on top of this basic five-state flow. Get this one solid and the rest reads intuitively.