Study Workflow

A study has no status column. Its state is the combination of a handful of boolean and timestamp fields, and every badge and gate in the interface is derived from them. Knowing which field means what is the fastest way to work out why a button is disabled.

The badge you see

The order matters: submitted wins over everything, and an accession outranks the ready flag.

Draft

A newly created study starts with submitted: false and readyForSubmission: false.

• Samples can be added and removed freely.
• Metadata can be edited without restriction.
• The study can be deleted (subject to the rules below).
• The Change Study Information button on the Overview opens the edit page.

Marking a study ready

readyForSubmission is a hand-raised signal: this study’s metadata is complete and I want it registered. It does not lock anything.

The Submission Status card on the Overview holds the controls:

“All metadata is complete” means: the study’s schema has loaded, it has at least one sample, and — when the questionnaire has a sample-metadata section — every sample has at least one non-empty value in checklistData or customFields. A study with no samples can never be marked ready. The completion percentage next to the card is samples with metadata ÷ total samples.

Marking ready sets readyAt to the current time. Back to Draft clears both readyForSubmission and readyAt — the original timestamp is not kept.

Test submissions

ENA runs a development server that accepts submissions and returns real-looking accessions without publishing anything. Use it. A production submission cannot be undone.

• A successful test registration stamps testRegisteredAt and stores the returned studyAccessionId.
• Test accessions expire 24 hours after registration. The interface counts down (expires in 6h, expires in 12m) and then shows Test Expired.
• Production submission requires an active — not expired — test registration, in addition to the other checks.

The Publishing surface shows a Production Requirements checklist covering, at minimum:

If the test registration has expired, re-register on the test server before submitting to production.

After submission

• submitted becomes true, submittedAt is stamped and studyAccessionId holds the ENA project accession (PRJEB…).
• Each sample receives its own sampleAccessionNumber / biosampleNumber, and each read gets experimentAccessionNumber (ERX…) and runAccessionNumber (ERR…).
• The interface treats the study as read-only for most fields: the Change Study Information button is hidden from non-admins, and the ready/unready controls disappear.

Running pipelines from a study

Studies are the launch point for analyses that combine several samples — assembly, binning, taxonomic profiling, submission preparation.

1. Open the study and go to Analysis in the sidebar (facility admins only).
2. Choose a pipeline.
3. Select which of the study’s samples to include. Every selected sample must have reads linked.
4. Set the pipeline parameters.
5. Launch.

SeqDesk generates the pipeline’s input from canonical records — for MAG, a samplesheet whose group column is the study id, so all the study’s samples co-assemble. See Running a Pipeline.

Pipeline results

Completed runs link results back to the study:

They appear on the study’s Analysis surface and on the individual samples. See Pipeline Results.

Internal notes

Every study has a free-text notes field, edited from the notes panel beside the study. SeqDesk records notesEditedAt and notesEditedById on each save, so the panel can show who last touched it and when. Notes are not versioned — a save replaces the previous text.

Deleting a study

Deleting a study never deletes samples. It unassigns them (studyId → null) and they stay in their sequencing orders with all their metadata. Pipeline runs that referenced the study are preserved.

Two guards:

The second guard exists because with per-study questionnaires the samples’ answers were captured against this study’s form. Deleting the study would orphan them, so SeqDesk makes you decide where those samples go first. Remove them from the study (or move them to another study) and the delete proceeds.

Without the dynamic-studies module, an unsubmitted study can be deleted with samples still attached; they are unassigned automatically.

Addressing a study

GET, PUT and DELETE on /api/studies/[id] resolve the path segment in three ways, in order:

1. as a study id (cuid);
2. as a study alias;
3. as a sequencing order id — returning the most recent study that contains a sample from that order.

So /studies/soil-2026 works if that is the alias, and a link built from an order id resolves to the study its samples ended up in. Aliases are not enforced unique, so the most recently created match wins.

Troubleshooting

Next

• Preparing a Submission — the real pre-flight checks.
• Running a Pipeline — study-scoped analysis runs in detail.