What SeqDesk doesn’t do (yet)

SeqDesk is opinionated. Several adjacent features that sequencing-management tools sometimes ship are deliberately absent (or are still on the roadmap). This page lists the most common ones so you can plan around them — and so you don’t go looking for an admin toggle that doesn’t exist.

If something here is a blocker for you, open an issue at hzi-bifo/SeqDesk  — most of these will probably ship eventually, and we use the issue tracker to prioritize.

Authentication

• No OAuth or SSO. Authentication is the NextAuth credentials provider only. Users sign in with email + password against the local User table. There is no Google/Microsoft/GitHub/SAML/OIDC login. If your facility requires SSO, run SeqDesk behind an identity-aware proxy (e.g., Cloudflare Access, Pomerium) and trust its forwarded headers in front of the credentials login.
• No per-user API tokens. All API access uses the same NextAuth session cookie that the UI uses. There is no “personal access token” UI and no long-lived bearer token for scripts. Automation today usually shells out to curl with the session cookie or uses an admin-only service account.

Notifications

• No self-hosted SMTP. SeqDesk does not run its own mail server. There is an optional, admin-gated hosted email relay that can send a handful of transactional notifications (order submitted, order status changed, samples sent, ticket created, ticket reply) through seqdesk.com once an admin enables the Notifications module and configures a relay token. It does not cover everything: there are no password-reset emails, for example. If the relay is disabled (the default), no outbound mail is sent at all — the in-app Tickets system covers researcher ↔ admin communication.
• No outbound webhooks. There is no POST configured-url on event X mechanism for user-defined integrations; external systems need to poll the relevant API endpoint or read database state directly. (SeqDesk does expose one inbound webhook — the Nextflow weblog endpoint that pipelines call to report live progress — but that is internal plumbing, not a general-purpose event fan-out.)

Search and bulk operations

• No global search. The sidebar has filtering and sorting per page (orders, samples, studies, runs), but there is no top-level search bar that crosses entity types. A researcher hunting for “the order that contained sample S42” pages through the orders list rather than typing into a global search.
• No bulk-CSV sample import outside the order wizard. The order wizard supports CSV/clipboard paste for sample tables. There is no admin-side “import 200 samples into existing order” path; samples have to flow through the wizard.

Data export

• File downloads exist for individual files (assemblies, reads, QC reports) via the in-app browser.
• Bulk export of all data for a study or order as a single archive is not built in. Use database snapshots or scripted downloads via /api/files/download if you need an offline copy.

Demo mode caveats

The demo mode intentionally disables a few real-world side effects:

• File downloads return 403.
• ENA submissions silently fall back to test mode.
• Pipelines can be inspected but not actually launched.

This is by design and not configurable per-instance.

Things that look configurable but aren’t

• Telemetry payload. The heartbeat schema is fixed; you can disable telemetry entirely or change the endpoint, but there is no opt-out for individual fields.
• Module set. The list of available modules is baked into the build. Admins toggle modules on/off, but new modules require code changes — see Adding Pipelines for the closest extension point that doesn’t need a fork.

What does work for these gaps