The Complete LabLynx One Platform Documentation Library
Publisher: John Jones
Every LabLynx One Platform manual in one place — User, Administrator, Developer, IT Admin, and IQ/OQ/PQ Validation — fully searchable and cross-linked. Documentation current for LabLynx One core platform version 5.6 · last verified against source documentation July 2026
The Complete LabLynx One
Documentation Library
Every LabLynx One manual in one place — User, Administrator, Developer, IT Admin, Security & Compliance, and IQ/OQ/PQ Validation — fully searchable and cross-linked.
Documentation current for LabLynx One core platform version 5.6 · last verified against source documentation July 2026
LabLynx One User Manual
For researchers and lab staff using LabLynx One day to day.
How to Use This Manual
This manual is written for anyone who uses LabLynx One day-to-day: researchers, analysts, lab managers, quality staff, and administrators. Every significant feature is explained at three levels: what it is, why it works that way, and how it adapts to your specific lab context.
Throughout this manual you will find four types of callout boxes:
Orange Tip boxes offer shortcuts, habits, and practical guidance to help you work faster or more accurately.
Navy Note boxes highlight important limitations, behaviors you might not expect, or configuration requirements.
Green Example boxes show concrete, real-world scenarios written from the perspective of specific lab types — academic, pharma, forensic, clinical, and quality labs.
Purple Use-Case Flexibility boxes summarize the range of ways a feature can be configured or applied across different laboratory types and industries.
Orange Why boxes explain the design reasoning behind each feature — helping you use it more effectively and understanding what problem it was built to solve.
Readers new to LabLynx One should read Chapters 1 through 4 in order. Experienced users can jump to any chapter. Chapter 12 provides ready-to-use configuration patterns for five specific lab types.
Introduction to LabLynx One
LabLynx One is a cloud-hosted, browser-based Electronic Laboratory Notebook designed for scientific organizations of all types and sizes. It replaces physical paper notebooks and disconnected file systems with a single, searchable, audited digital environment.
1.1 What Is LabLynx One?
LabLynx One is built on eLabFTW, a widely adopted open-source ELN platform, and delivered by LabLynx as a fully managed subscription service. LabLynx handles hosting, backups, security patching, and user support so your team can focus on science rather than infrastructure.
The result is a system that feels like a well-organized notebook but behaves like enterprise software: it time-stamps every action, tracks every change, enforces permissions, and produces audit-ready records on demand.
Because LabLynx One is web-based, there is nothing to install on individual computers. Every team member — whether in the lab, at a desk, or working remotely — accesses the same live system with the same data. This eliminates the version-control problems that plague shared document folders, ensures changes are immediately visible to all authorized users, and allows any authorized device (desktop, laptop, tablet, kiosk) to be a full LabLynx One access point.
1.2 The Problem LabLynx One Solves
Most laboratories transitioning to LabLynx One describe one or more of these problems with their existing approach:
- Paper notebooks: Entries are undated or inconsistently dated. Handwriting is illegible to others. Notebooks are lost, damaged, or left behind when a researcher leaves. Critical reagent details cannot be found later.
- Shared drives: Files accumulate with no naming convention. Raw data and final reports are mixed. No record of who changed what or when. Instrument data files are separated from their experimental context.
- Disconnected tools: Protocols live in one place, data in another, reagent inventories in a third. Assembling a complete experiment record takes days when an auditor asks for it.
- No collaboration structure: Sharing work requires emailing files. No formal review or sign-off process. Institutional knowledge walks out the door when people leave.
LabLynx One addresses each of these through structured data entry, automatic timestamping, searchable metadata, resource linking, configurable permissions, and formal review workflows — all within a single platform.
1.3 Cross-Industry Overview: Who Uses LabLynx One?
LabLynx One is designed with enough flexibility to adapt to the documentation culture of any scientific domain.
| Lab Type | Primary Goals | How LabLynx One Helps |
|---|---|---|
| Academic Research | Publication, reproducibility, student training, grant compliance | Flexible templates, unlimited tags for project tracking, PDF export for manuscripts, RFC 3161 timestamps for IP protection |
| Pharma / Biotech QA | 21 CFR Part 11 compliance, CAPA, method validation, batch records | Electronic signatures, cryptographic audit trail, locked steps for SOP enforcement, structured review/sign workflows |
| Forensic / Crime Lab | Chain of custody, evidence traceability, court-ready records | Custom ID fields for case numbers, strict permission controls, complete audit log, signature-on-completion workflows |
| Medical Device R&D | Design controls, IP documentation, multi-team coordination | Bidirectional linking, team-scoped permissions, Ed25519 signatures for invention records, API integration |
| ISO 17025 Testing | Traceable method execution, QC documentation, equipment management | Equipment scheduler with booking history, calibration date metadata, locked protocol steps, approval chains |
| Environmental / Field | Sample tracking, chain of custody, multi-site coordination | QR code labels, container/storage hierarchy, custom ID for sample barcodes, cross-team sharing |
| Neurotechnology / Startup | Rapid deployment, IP protection, investor-ready documentation | Quick templates, RFC 3161 timestamps for prior art, REST API for instrument integration, scalable from 3 to 300 users |
1.4 Three Foundational Concepts
Three concepts underpin the entire system. Understanding them makes every other feature easier to learn.
Concept 1: Experiments are the primary record
An Experiment captures what was done, when, by whom, with which materials, following which protocol, and with what outcome. Every other object — resources, templates, tags, timestamps, signatures — exists to enrich, organize, or authenticate experiments.
Paper notebooks conflate protocol, execution, and result in a single undifferentiated block of text. LabLynx One separates these into structured fields, attached files, linked resources, and body text — making each component independently searchable and verifiable.
Concept 2: Resources are shared, reusable records
A Resource represents anything a researcher uses: a reagent, an antibody, a piece of equipment, a cell line, a reference standard. Resources are created once and linked to as many experiments as needed. When a resource record is updated, every experiment linked to it can be traced.
In a paper notebook, reagent details are copied by hand into each experiment. This creates transcription errors and no connection between experiments that used the same lot. LabLynx One's resource model eliminates redundancy and makes impact analysis possible: if you need to find every experiment that used a specific antibody lot, one search returns the complete list.
Concept 3: Teams control what is visible
LabLynx One organizes users into Teams. Each team has its own experiment and resource library. A user can belong to multiple teams, and experiments can be shared across teams with configurable read or write access.
A single global experiment library would expose every researcher's unpublished work to everyone in the organization — inappropriate for competitive research environments, CROs with multiple clients, or organizations with compartmentalized compliance boundaries. Teams provide natural data boundaries without requiring separate system deployments.
1.5 User Roles and What They Control
| Role | Capabilities | Typical Persons |
|---|---|---|
| User (default) | Creates, edits, and manages their own experiments and resources. Cannot modify system configuration. | Researchers, technicians, students, analysts |
| Admin | All User permissions plus: manage team membership, configure templates and categories, view all team entries regardless of individual permissions. | Lab managers, PIs, quality managers |
| SysAdmin | All Admin permissions plus system-level configuration: user account management, group/team creation, LDAP/SSO integration, API key oversight. | IT administrators, LabLynx support contacts |
| Locked | Read-only access. Can view entries with appropriate permissions but cannot create, edit, or delete. | Auditors, external reviewers, archived accounts |
- Academic lab: Most users are the default User role. The PI is Admin, configuring the team's categories and templates, viewing all team experiments, and managing student onboarding.
- Pharma QA: QA analysts are Users; their supervisor is Admin and executes the formal sign workflow. External auditors are granted Locked accounts during the audit window.
- ISO 17025: The quality manager is Admin and owns all templates and categories. Instrument operators are Users who execute documented methods.
Getting Started
Your first steps with LabLynx One — from logging in securely to configuring your account settings and understanding the navigation bar that anchors every interaction.
2.1 Logging In
Navigate to your organization's LabLynx One URL (typically yourorganization.elabeln.com). You will see one of two login experiences depending on your administrator's configuration:
- Local credentials: Enter the email address and password associated with your LabLynx One account.
- Single Sign-On (SSO): Click the SSO button and authenticate with your organization's identity provider (Microsoft Entra ID, Okta, Google Workspace, SAML 2.0, or LDAP-compatible directory). You will not maintain a separate LabLynx One password.
SSO is strongly recommended for organizations that already manage identities centrally. When a researcher leaves and their Active Directory account is deactivated, their LabLynx One access is immediately revoked without any additional step. This satisfies the user access control requirements of 21 CFR Part 11 and ISO 17025 without manual housekeeping.
If you have forgotten your local password, use the 'Forgot password?' link on the login page. If your organization uses SSO, contact your IT department — LabLynx One cannot reset credentials managed by your identity provider.
Bookmark your organization's specific LabLynx One URL rather than the generic elabeln.com homepage. This takes you directly to your team's login page and saves time every day.
2.2 The Navigation Bar
After logging in, a navigation bar appears at the top of every page. It is the consistent anchor point for all navigation in LabLynx One.
| Element | What It Does |
|---|---|
| Home icon / Logo | Returns you to your personal experiment dashboard — your default view of all experiments you own or can access. |
| Experiments | Opens the full experiment index. By default shows your own experiments. Use the Team dropdown to switch to viewing your team's shared experiments. |
| Templates | Opens the template library. Your team's pre-built experiment formats. Selecting one creates a new experiment pre-populated with its structure. |
| Resources | Opens the resource index organized by category. This is where reagents, equipment, cell lines, and all other resource types live. |
| Team dropdown | Switches your active scope between teams if you belong to more than one. Controls which experiments and resources you see. |
| Search bar | Full-text search across all experiments and resources your current scope gives you access to. Searches titles, body text, metadata fields, tags, and comments. |
| Notification bell | Alerts you to new comments, Request Action notifications from colleagues, and system announcements. |
| User avatar (top right) | Opens account settings, team settings (if Admin), API key management, and logout. |
The navigation bar never changes position or content regardless of what you are doing. This is a deliberate design choice: in a complex research workflow where you might be switching between an experiment, a linked resource, and a template within minutes, a stable navigation anchor prevents disorientation and reduces the time spent thinking about the interface rather than the science.
2.3 Your Account Settings
Click your user avatar in the top right corner and select Account Settings to access three configuration tabs.
General Tab — Preferences and Display
Controls your display name, language, timezone, and interface theme (light or dark mode). Setting your timezone correctly is important: all timestamps in LabLynx One are stored in UTC but displayed in your local timezone. An incorrect timezone makes timestamps misleading.
The dark theme is popular with researchers who work in dimly lit microscopy or instrument rooms. It reduces eye strain during long data entry sessions.
Account Tab — Security and Authentication
This is where you change your local password and enroll in Multi-Factor Authentication (MFA). MFA requires a time-based one-time code from an authenticator app (Google Authenticator, Authy, Microsoft Authenticator, or any TOTP-compatible app) in addition to your password.
21 CFR Part 11 Section 11.300 requires that electronic signatures be unique to one individual and include controls to prevent their use by anyone other than the genuine owner. MFA directly satisfies this requirement. For organizations subject to FDA oversight, enabling MFA is not optional once electronic signatures are in use.
A QA analyst completes a method validation study and is ready to sign the record. She enters her password, is prompted for her MFA code, opens her authenticator app, enters the six-digit code, and signs. The signature record captures her identity, the timestamp, and the fact that two-factor authentication was used. If an FDA inspector asks how the organization prevents unauthorized signature, the MFA log provides the evidence.
API Keys Tab — Programmatic Access
Generate personal API keys for programmatic access to LabLynx One's REST API. Each key can be labeled and revoked independently. Keys are shown only once at generation; store them in a secure credential manager.
Create a separate API key for each integration or script. If one key is compromised or a script is decommissioned, you can revoke that specific key without disrupting other integrations.
Working with Experiments
The Experiment is the core documentation unit in LabLynx One. This chapter covers every field and tool available in an experiment record, explains what each does, and illustrates how each serves different types of laboratory work.
3.1 Browsing and Filtering the Experiment Index
Click Experiments in the navigation bar to open the experiment index. The index displays all experiments within your current scope. Each row shows the experiment's title, category, status, tags, date, and owner.
- Filter by category: Click any category pill in the filter panel to show only experiments of that type.
- Filter by status: Show only Running, Success, Failure, or other statuses to focus on active work.
- Filter by tag: Click one or more tags to find experiments associated with a specific project, compound, or technique.
- Filter by owner: See only experiments created by a specific team member.
- Sort: Click any column header to re-sort by date, title, or status.
Use the Favorites feature (star icon on any experiment) to pin your most-active ongoing experiments to the top of the index. Especially useful during long-running projects where you return to the same 3–5 entries dozens of times per week.
- Academic lab: Researchers use category filtering to separate cell biology from genomics work, and tag filtering to find all experiments in a specific grant project.
- QA lab during an audit: The quality manager filters by status = 'Needs Review' to queue all pending records for sign-off.
- High-throughput analytical lab: Analysts filter by date range and category to generate a complete list of all HPLC runs in a given week for trending.
3.2 Creating an Experiment
Click the + New Experiment button in the top right of the experiment index. A dialog appears with two options:
- Blank experiment: Opens a new empty experiment. You define the structure entirely yourself.
- From template: Select any template defined by your team. The new experiment is pre-populated with the template's structure — including body text, custom metadata fields, and steps.
The two-path creation flow reflects a fundamental tradeoff between flexibility and standardization. Blank experiments let researchers document novel work without fighting a prescribed structure. Template-based experiments ensure that routine procedures are executed consistently every time — the template author has already thought through what must be captured, and the researcher cannot accidentally omit a field.
A biochemist creates a template for their standard SDS-PAGE gel electrophoresis procedure with all standard metadata fields, pre-written protocol steps, and a placeholder table for band measurements. When a team member needs to run a gel, they create from this template. But when the same biochemist tries a completely new pull-down assay for the first time, they start from a blank experiment and capture the protocol as they go — later converting it into a template for future use.
3.3 Understanding Every Experiment Field
Title
The Title is the primary identifier. It appears in all index views, search results, and any link that references this experiment. A well-written title makes an experiment findable years later.
Write titles that will be meaningful to someone who did not create the experiment. Include the technique, the key variable, and the outcome or purpose. Compare: 'Experiment 47' vs. 'Anti-EGFR antibody binding assay — pH 6.8 vs. 7.4 comparison — 2026-06-01'. The second is findable without opening the record.
Date (Started On)
Defaults to today's date at experiment creation, but can be changed by the owner. This field is separate from the system-recorded creation timestamp (which cannot be modified) and captures the scientific start date, which may differ from when the record was created.
A researcher who collects data at 11 PM creates the formal experiment record the next morning. The Date field captures when the work began. The immutable system timestamp records when the record was created. Both are part of the permanent record and serve different roles in an audit or review.
Custom ID
A free-text identifier completely separate from the ELabID. Can hold any value: a LIMS accession number, a project code, a case number, a batch ID, or any other identifier from an external system.
- Forensic lab: Custom ID = case number. All experiments for a case share the same Custom ID, enabling instant retrieval of the complete analytical record.
- Biotech QA: Custom ID = batch number, enabling instant traceability from test result back to production batch.
- Academic: Custom ID = grant project code. Filtering at reporting time produces a complete list of all experiments billable to that grant.
- Environmental: Custom ID = sample barcode, linking physical and digital records without manual transcription.
Category
Administrator-defined labels that classify experiment types. Unlike tags (flexible and user-created), categories are controlled vocabulary — only Admins can create, rename, or delete them. Each experiment belongs to exactly one category.
The distinction between categories (controlled, structural) and tags (flexible, user-created) is fundamental. A category answers 'what kind of experiment is this?' A tag answers 'what does this experiment concern?' Categories appear as columns in the index, drive template assignment, and enable category-level filtering. Tags capture the variable dimensions of what an experiment is about.
Status
Tracks where an experiment is in its lifecycle. Default statuses: Running, Success, Failure, Need to be Redone, Waiting for Something. Administrators can add custom statuses, rename defaults, or remove those that don't fit.
- Pharma QA: In Progress → Pending QA Review → QA Reviewed → Approved → On Hold → Rejected – Needs Rework → Closed
- Forensic: Case Received → Examination Active → Peer Review → Report Drafted → Court Pending → Closed
- Quality lab: Open → Investigation → Root Cause Identified → CAPA Issued → Effectiveness Review → Verified Closed
Tags
User-defined labels that can be applied to any experiment. An experiment can have unlimited tags, and any user can create new ones. Tags are searchable, filterable, and can be visualized as a network graph showing relationships between experiments.
Tags represent a graph-based organizational model rather than a tree-based one. A folder hierarchy forces you to choose one location per item. Tags allow any item to belong to any number of groupings simultaneously — reflecting the actual multi-dimensional nature of laboratory data. 'Show me all Western Blots from Project MR73 using HEK293 cells' is a single multi-tag filter query. In a folder system it requires traversing multiple subfolders and cross-referencing manually.
Permissions
Every experiment has an explicit permission setting controlling who can view and edit it. The owner always has full access. Beyond the owner, four levels are available: Private (owner only), User (team members can view), Team (read/write for all team members), and Organization (all teams can view).
Default privacy protects unpublished work. The opt-in sharing model means researchers actively choose when their work is ready to be seen — protecting IP, preventing premature disclosure, and respecting the competitive nature of scientific research.
3.4 The Main Text Editor — Capturing the Science
The main text editor is the body of the experiment record — the equivalent of the blank page in a paper notebook, but with structured capabilities: rich text formatting, sortable tables, LaTeX mathematical expressions, code blocks, and inline images.
Sortable Tables
LabLynx One's built-in table editor creates tables with configurable rows and columns directly in the experiment body. Tables are sortable: clicking any column header sorts the table by that column, ascending or descending.
An HPLC analyst runs 24 samples. Each sample's result (retention time, area, concentration) is entered into a table. The analyst clicks the Concentration column header to sort ascending — immediately identifying the three samples below the specification limit. The sort operation takes two seconds. Finding the same information in a flat text document would require manual scanning.
Mathematical Expressions — LaTeX
LabLynx One supports LaTeX syntax for mathematical notation. Surround a LaTeX expression with dollar signs ($...$) for inline math or double dollar signs ($$...$$) for display math. The expression renders visually in the saved entry.
The workaround in most digital environments — inserting screenshots of equations — creates images that are not searchable, not renderable at different scales, and not accessible to screen readers. LaTeX renders the equation as a first-class element of the document.
Code Blocks
Insert a code block via the toolbar to include programming code, command-line instructions, or data processing scripts with syntax highlighting and monospace formatting. Code blocks preserve whitespace and indentation, making Python, R, bash, or any other language readable within the experiment record.
Markdown Editor (Alternative to Rich Text)
Users who prefer plain-text authoring can switch the main text editor to Markdown mode via the "Switch editor" button at the bottom right of the text box, or set Markdown as their permanent default from Settings ("Disable the rich text editor and write Markdown directly"). Both modes produce the same underlying record.
Images
Images can be inserted directly into the body by drag-and-drop, copy-paste, or the image insertion tool. They are stored as part of the experiment record and rendered inline at a configurable display size.
Embedding images in the body — rather than attaching them as separate files — preserves the narrative relationship between the image and the text that explains it. A gel image appears immediately below the protocol step that produced it. The record reads as an integrated scientific account rather than a document accompanied by a folder of unlabeled images.
Spreadsheet Editor
A built-in spreadsheet editor lets researchers display and manipulate tabular data directly inside an experiment, with common spreadsheet operations, CSV/XLSX import-export, and formula calculation. Formulas are parsed when a cell expression starts with =, and dependent cells recalculate automatically when referenced values change (reactive updates); copy/paste and drag-fill adjust cell references appropriately.
| Formula | Purpose |
|---|---|
=SUM(A1:A5) | Sum a range of cells |
=D1 - D2, =A5 * E7 | Inline arithmetic between cells |
=CELL() / =COLUMN() / =ROW() | Return the current cell reference, column number, or row number |
=VALUE(c, r) | Return the value at a given column/row |
This is a comparatively new capability and should still be treated as an emerging feature — verify calculated values before relying on them for reportable results, the same way you would with any new tool.
3.5 Custom Metadata Fields — Structured Data Beyond the Body
Custom metadata fields capture specific, defined pieces of information in a machine-readable format — not as unstructured text, but as typed values that can be searched, filtered, validated, and exported.
Free-text body content is human-readable but machine-opaque. A researcher who writes 'temperature: 37 degrees C' in the body has captured the information, but a query asking 'find all experiments run at 37°C' cannot parse it reliably. A metadata Number field labeled 'Incubation Temperature (°C)' with the value 37 is queryable, filterable, and exportable. Metadata fields convert the body's narrative into structured data.
| Field Type | Format | Scientific Use Cases |
|---|---|---|
| Text | Single line of free text | Buffer name, lot number, instrument ID, operator initials, external reference number |
| Text area | Multiple lines of free text | Sample description, deviation notes, observation summary |
| Number | Numeric value with optional units | Concentration (mg/mL), volume (µL), temperature (°C), pH, molecular weight, yield (%) |
| Date | Calendar date picker | Sample receipt date, expiration date, calibration due date, protocol version date |
| Date and time | Date plus hours/minutes | Instrument run start time, autoclave cycle timestamp, centrifugation start/end |
| Checkbox | True/False toggle | GMP-compliant run? / Duplicate performed? / Blank subtracted? / Approved for release? |
| Select | Single choice from a defined list | Instrument used (from calibrated list), analysis method, analyst (from trained personnel list) |
| Multi-select | Multiple choices from a list | Compounds tested, techniques used, co-investigators |
| Radio button | Single choice with visual radio format | Pass/Fail/Inconclusive; Positive/Negative/Equivocal; Compliant/Non-Compliant |
| URL | Hyperlink | Link to instrument raw data in a repository, SOP online, regulatory guidance document |
- Genomics lab: Metadata fields capture read depth (Number), reference genome version (Select), aligner version (Text), and whether the analysis was re-run after QC failure (Checkbox).
- Environmental testing: Fields capture collection site (Select from validated site list), collection time (Date and time), field technician (Select from trained personnel), and preservation method (Select).
- Neurotechnology startup: Metadata fields for device model (Text), firmware version (Text), implantation site (Select), and recording duration (Number) make every neural recording experiment queryable by hardware configuration.
3.6 Steps — Protocol Checklists with Live Timestamps
Steps are a checklist panel attached to an experiment. Each step is a protocol instruction that the researcher checks off as they complete it. When a step is checked, LabLynx One records the exact date, time, and identity of the user who checked it — transforming the protocol from a plan into a live execution record.
Paper SOPs are checked off with a pen, providing no information about when each step occurred, who performed it, or whether the timing between steps was correct. LabLynx One's step timestamps create a time-resolution record of protocol execution. For GMP purposes, this is the difference between a record that says 'I followed the protocol' and one that proves it.
- Step 1: 'Retrieve evidence sample from secure storage' — timestamped at 09:14 by Analyst Kovacs
- Step 2: 'Weigh sample and record net weight' — timestamped at 09:18 by Analyst Kovacs
- Step 3: 'Prepare color test reagents per SOP-DC-003' — timestamped at 09:22 by Analyst Kovacs
- Step 4: 'Perform Scott test' — timestamped at 09:25; note: 'Blue color change observed within 30 seconds'
- Step 6: 'Return evidence to secure storage with chain of custody entry' — timestamped at 09:44
The entire evidence handling chain is documented with minute-level precision, entirely within the LabLynx One record.
- Academic: Steps serve as a protocol reminder. The timestamps confirm the timing of each step in the experiment record.
- Biotech GMP: Locked steps from a validated template cannot be reordered, skipped, or modified. The step completion record proves the validated protocol was followed exactly.
- ISO 17025: Steps document the execution of a standard method. Any deviation from the expected step sequence — visible from the timestamps — triggers a deviation note.
3.7 Linking Experiments and Resources — Building a Knowledge Graph
LabLynx One allows any experiment to be linked to any other experiment or resource. Links are bidirectional: if Experiment A links to Resource B, Resource B's record also shows that Experiment A linked to it. This creates a navigable network of related records rather than isolated documents.
Scientific knowledge is not linear. An experiment builds on previous experiments. A protocol references multiple reagents, each with its own record. A compound's properties span dozens of experiments. In a paper system, cross-references are error-prone and quickly become stale. LabLynx One's linking model makes these relationships first-class, permanent, and navigable.
A researcher records a neural recording experiment and links it to: (1) the Probe Resource record for the specific electrode array; (2) the Animal Resource record for the subject; (3) the previous experiment where the animal was surgically implanted; and (4) the analysis script Resource record documenting spike-sorting parameters. When the team investigates a data quality issue six months later, they navigate directly to all linked records in two clicks.
For ongoing projects, establish a 'Project Summary' experiment at the start and link every subsequent experiment in the project to it. The Project Summary becomes a navigable table of contents for the entire body of work.
3.8 Attaching Files — Preserving Raw Data
The Attachments panel holds any files associated with the experiment. No limit on number or type: instrument raw data files, chromatograms, spectra, gel images, plate reader outputs, analysis scripts, PDFs, videos. Each attachment shows its filename, size, upload timestamp, and uploader identity.
The most common data integrity gap in shared-drive systems is the separation of raw data from the record that explains it. Instrument files accumulate in shared drives named by date or run number, with no connection to the experimental context that generated them. LabLynx One's attachment model makes the raw data and its experimental context inseparable.
Always attach the original raw instrument output file (e.g., .raw, .wiff, .d, .cdf) alongside any processed analysis. This satisfies the ALCOA+ 'Original' requirement: the unprocessed source data is preserved permanently alongside the interpretation, and re-analysis is always possible.
3.9 The Experiment Toolbar — All Actions Explained
| Action | What It Does |
|---|---|
| Edit / Save | Toggles between view mode and edit mode. Changes are auto-saved periodically; click Save to commit immediately. |
| Duplicate | Creates a new experiment with the same structure: same fields, body content, metadata, and steps. New ELabID, new creation timestamp, empty attachment list. |
| Signature | Opens the electronic signature workflow. Three levels available: simple, PDF, or Ed25519 cryptographic. See Chapter 7. |
| RFC 3161 Timestamp | Generates a trusted third-party timestamp. See Chapter 7. |
| Blockchain Timestamp | An alternative to RFC 3161: anchors a hash of the entry to a public blockchain (bloxberg) for independent, decentralized proof of existence at a point in time. |
| Export | Exports to PDF, ZIP archive, or ELN format (RO-Crate). Optionally submit to configured external repositories. |
| Pin Entry | Pins the entry to the top of the index for quick access. |
| Lock / Unlock | Locks the experiment against further editing. The lock event is logged. Only owner or Admin can unlock. |
| Request Action | Sends a structured notification to a colleague: Archive, Lock, Review, Sign, or Timestamp this entry. |
| Ellipsis (…) menu | Transfer Ownership, See Revisions, See Changelog, Archive, Delete. |
3.10 Comments — Preserved Dialogue on the Record
Any user with read access can leave a comment. Comments are timestamped, attributed, threaded, and permanent. Owners and commenters receive notifications when new comments are added. Comments cannot be deleted by anyone — they are part of the permanent record.
The permanence of comments is a deliberate data integrity decision. In any regulated or legally reviewed context, the ability to delete comments would make the record manipulable. Permanent, attributed, timestamped comments create a communication layer on the record that is as trustworthy as the record itself.
3.11 Archiving and Deleting Experiments
Experiments have two distinct "removed from view" states, and it matters which one you use:
| State | How to Get There | Behavior |
|---|---|---|
| Archived | Toolbar → More Options → Archive | Removed from the default list and from exports, but remains fully viewable (read-only) and can be unarchived at any time, individually or in bulk. Use this for completed, still-relevant work you want out of your everyday view. |
| Deleted (soft-delete) | Toolbar → More Options → Delete | Moved to the trash. Excluded from searches and exports, but not permanently destroyed — it can still be opened and restored (individually or in bulk) from the Deleted filter. Use this only for entries that genuinely shouldn't have been created. |
To view either set, open the Experiments list, click Show more filters, and set the state filter to Archived or Deleted. Archived entries show a small archive icon; deleted entries show a trash-bin icon.
Because deletion is a soft-delete, records subject to a regulatory retention requirement are not destroyed by an accidental (or even intentional) delete action — they remain recoverable by an Admin or SysAdmin. This is an important point to make to auditors: nothing in LabLynx One's standard user-facing delete action performs a hard, unrecoverable data destruction.
Working with Resources — The Shared Inventory
Resources are the catalog dimension of LabLynx One. While Experiments document what happened, Resources document what was used. Because Resources are linked to experiments rather than duplicated within them, a single Resource record serves as the authoritative, shared reference across the entire team's experimental history.
The Resource model reflects how laboratories actually operate. A given antibody lot is purchased once, characterized once, and used dozens of times across many experiments. Documenting the characterization once as a Resource — and linking experiments to it — means that if a quality concern arises with that lot, you know the full scope of impact in one click.
4.1 Resource Categories — Unlimited Flexible Classification
Resource Categories are defined by your Administrator and can represent any entity your lab manages. There is no pre-imposed taxonomy.
- Academic research: Antibodies, Cell Lines, Plasmids/Constructs, Chemicals, Equipment, Projects, Personnel
- Pharmaceutical quality: Reference Standards, Reagents, GMP-Qualified Equipment, SOPs, Customers, Suppliers, Finished Products
- Forensic lab: Active Cases, Evidence Items, Analysts, Instruments, External Laboratories
- Neurotechnology startup: Implant Devices (by serial number), Animal Subjects, Surgical Instruments, Software Versions, Study Protocols
Think of Resource Categories as the 'nouns' of your lab's vocabulary. Anything that exists independently of a particular experiment — anything with a serial number, lot number, location, specification, or lifecycle — is a candidate for a Resource entry.
4.2 Creating and Editing Resources
Creating a Resource follows exactly the same process as creating an Experiment: click Create from the Resources page, title the entry, optionally select a Resource Template, and click Create. Resources have the same field types as Experiments: main text, metadata fields, tags, status, steps, links, and attachments.
Title: Anti-p53 Antibody, Clone DO-7, Lot #AB-2024-441
Metadata fields: Vendor (Abcam), Catalog # (ab26), Lot # (AB-2024-441), Concentration (1 mg/mL), Storage Temperature (−20°C), Expiry Date (2026-12-31), QC Status (Pass)
Attachments: Vendor datasheet PDF, validation Western Blot image, Certificate of Analysis
Linked experiments: All experiments that referenced this lot appear here automatically — a complete usage log with zero manual effort.
4.3 The Scheduler — Equipment Booking
Any resource can be made bookable. When an equipment resource has scheduling enabled, a calendar appears on its resource page. Authorized users can book time slots. The scheduler shows all bookings in a color-coded calendar view, preventing double-booking and creating a timestamped access record for every booking.
The Scheduler solves a universal laboratory problem: instrument time conflicts. A paper sign-up sheet is invisible to remote team members, can be altered without a record, and provides no booking history. LabLynx One's Scheduler is visible to the whole team, requires authenticated logins (so every booking has a named owner), and creates an immutable record of who booked what and when.
An Android touchscreen mounted near the HPLC system runs the LabLynx One interface. A technician approaching the instrument authenticates with their LabLynx One credentials, confirms their booking, and begins the session. This creates a timestamped, attributed access record — who used the instrument, for how long, linked to which experiment — without requiring a laptop nearby.
4.4 Procurement — Reorder Management
Any resource can be configured for procurement to allow team members to submit reorder requests. Procurement requests accumulate in the Team page > Procurement Requests tab, where lab managers review, approve, and mark orders as placed or received.
Templates — Encoding Laboratory Standards
Templates are the most powerful tool for standardizing laboratory documentation. A Template is a pre-configured framework that every new experiment of a given type starts from. Rather than relying on each researcher to remember what information to capture, a good template makes correct documentation automatic.
Reproducibility problems in scientific research are often not failures of scientific method — they are failures of documentation. Researchers leave institutions, protocols exist only in memory, and key variables are omitted because 'everyone already knows that'. Templates solve this at the system level: the template defines what must be recorded, and the template is always present when a new experiment starts.
5.1 What a Template Can Contain
Main Text Content
Pre-written protocol structure, placeholder headings, instructional text, example tables, standard disclaimers.
Metadata Fields
Any field type combination with default values and field descriptions explaining what is expected.
Steps
A protocol checklist with task descriptions and optional deadlines and notifications.
Locked Steps
Steps that cannot be modified or deleted after experiment creation — SOP-level enforcement.
Linked Resources
Pre-linked entries (e.g., the relevant SOP, the standard reagent kit) that all experiments of this type reference.
Permission Defaults
Default Visibility and Can Write settings for all experiments created from this template.
5.2 Creating and Managing Templates
Navigate to Experiments → Templates (or Resources → Templates for a resource template). Click Create. Enter a title. Optionally start from an existing template. Build the template: write the main text structure, add metadata fields (click + Extra Field), define steps, link relevant resources, and set permission defaults. Save. The template is now available when creating new experiments of this type.
Build templates incrementally. Start with main text headings and 4–5 core metadata fields. Run 5–10 real experiments using it. Refine based on what you always add manually. A good template evolves with the lab. Schedule an annual template review to update fields and retire obsolete sections.
5.3 Locked Steps — SOP Enforcement in Practice
When a step in a template is locked, experiments created from that template display those steps as read-only. Analysts can check them off (mark complete, with timestamp and attribution) but cannot edit the step description or delete it. The correct procedure is defined once in the template and cannot be circumvented by any user.
An HPLC method has 8 critical steps validated in an SOP. These steps are added to the 'HPLC Method Execution' template with locks enabled. Every analyst who creates a new HPLC experiment sees the same 8 locked steps. As each step is performed, the analyst checks it off. LabLynx One records their name, the system timestamp, and which step was completed. If an FDA inspector asks 'how do you verify analysts follow the HPLC method?', the answer is: every HPLC experiment has an automatically generated, timestamped, attributed step-completion record — for every run.
5.4 Modular Template Composition
From within the main text editor, Insert → Insert Template imports another template's body content at the cursor position. This enables modular assembly: build complex experiments from reusable, independently maintained template sections.
5.5 Pinning — Controlling Which Templates Appear by Default
New templates are "pinned" by default, meaning they appear in the Create pop-up window and in the quick-create menu next to the Create button on the Experiments/Resources page. As a team accumulates templates over months or years, not every template needs to stay in that shortlist — click the thumbtack icon on a template to unpin it. Unpinned templates remain fully usable; they're simply reached by browsing the full Templates list rather than the quick-create shortcut.
Periodically unpin templates for discontinued methods or one-off protocols so the quick-create menu stays focused on the handful of templates your team actually uses every week.
Search, Tags, and Organization
The ability to find information quickly is what separates an effective ELN from a digital filing cabinet. LabLynx One provides several complementary tools for organizing and retrieving data — each addressing a different discovery need.
6.1 Full-Text Search
The search bar on any index page searches across titles, main text content, metadata field values, and tag labels simultaneously. You can combine search terms with filters (Category, Status, Date Range, Author) to narrow results precisely.
LabLynx One indexes the content of the main text body, not just titles. If you wrote 'unexpected precipitate formed at 37°C' in an experiment three years ago, searching for 'precipitate 37' will find it. This is a significant advantage over folder-based storage where search only matches filenames.
6.2 Tags — Multi-Dimensional Organization
Unlike Categories (an experiment belongs to one), tags are additive. An experiment can have unlimited tags, and each tag provides an independent filter dimension.
Tags represent a graph-based organizational model rather than a tree-based one. A folder hierarchy forces you to choose one location per item. Tags allow any item to belong to any number of groupings simultaneously — reflecting the actual multi-dimensional nature of laboratory data.
6.3 Favorite Tags
Open the left panel (click the arrow on the left edge of the screen) and use the + button to define Favorite Tags. Favorite Tags appear as one-click filter shortcuts. If you activate a Favorite Tag filter before creating a new experiment, the new experiment is automatically tagged with that tag.
6.4 Four Strategies for Grouping Experiments into Projects
| Strategy | How It Works | Best For |
|---|---|---|
| Tags (most flexible) | Apply a consistent project tag to all experiments. Filter by tag to see the project view. | Most labs; especially academic, where project boundaries are fluid. |
| Experiment Categories | Admin-defined broad classifications. Best for workflow type grouping. | Labs with stable experiment type vocabularies. |
| Project Resources | Create a Resource entry (Category: Project). Link all project experiments to it. 'Show Related' shows all linked experiments. | Complex multi-person, multi-year projects needing a navigable overview. |
| Direct Experiment Links | Link experiments to each other for sequential workflows. | Protocol iteration tracking where each experiment builds on the previous. |
Signatures, Timestamps, and Record Integrity
LabLynx One provides a layered system for attesting to the authenticity, approval, and timing of records. Understanding when to use each mechanism — and why they provide different types of assurance — allows laboratories to meet regulatory requirements precisely.
7.1 Three Tools, Three Questions
| Question | Tool | Purpose |
|---|---|---|
| Who attested? | Electronic Signature | Proves a specific named person intentionally approved or attested to a specific record at a specific time. A human attestation of intent. |
| What existed? | RFC 3161 / Blockchain Timestamp | Proves a record's exact content existed at a specific point in time, certified by an independent trusted authority. Protects against backdating. |
| What changed? | Changelog + Revisions | Provides a continuous, immutable record of every modification to every field. Satisfies ALCOA+ 'attributable and contemporaneous' requirements. |
These three tools address different adversarial concerns. A signature proves intent. A timestamp proves timing: this specific content existed before this specific moment and was not fabricated retroactively. A changelog proves completeness: nothing was silently changed. Together they provide the full data integrity framework that FDA 21 CFR Part 11, GMP, and ALCOA+ require — no single tool provides all three assurances alone.
7.2 Electronic Signatures — Three Levels
Level 1: Simple (Implicit) Signature
Any authenticated action by a user constitutes an implicit attestation: locking an experiment, checking a Step, leaving a comment, or responding to a Request Action. All are logged with the user's identity and a system timestamp.
Level 2: Handwritten Signature Block (PDF)
Enable in Settings → General → PDF Configuration → 'Enable signature block in PDF Export'. Exports include a formatted signature block for physical signing. The signed PDF is scanned and attached to the entry. Used during hybrid paper-to-digital transitions or where wet signatures are still institutionally required.
Level 3: Advanced Cryptographic Signature (Ed25519)
The most rigorous option. Uses the Ed25519 public-key signature algorithm. When a user signs, LabLynx One generates a SHA-256 hash of the experiment's content at that moment, signs that hash with the user's private key, and stores the signature. The signature can be independently verified at any future date using the open-source Minisign tool.
Ed25519 signatures provide non-repudiation that no password-based signature system can offer. A password can be shared, guessed, or disclosed. An Ed25519 signature can only be produced by the holder of the specific private key, which never leaves the signer's device. For laboratory notebooks used in patent disputes, FDA submissions, or litigation, this cryptographic guarantee is the highest available standard of signature authenticity.
- Analyst completes experiment, applies their cryptographic signature with meaning 'Author Review'.
- Analyst uses 'Request Action → Sign' to send the entry to their supervisor.
- Supervisor reviews the entry, applies their signature with meaning 'Approval'.
- Experiment is locked. The entry now carries two independent cryptographic signatures — a complete two-person review record satisfying 21 CFR Part 11 requirements.
7.3 RFC 3161 Trusted Timestamping
Clicking the Timestamp button initiates the RFC 3161 trusted timestamping process. LabLynx One generates a cryptographic hash of the experiment's complete content, sends it to a Timestamp Authority (TSA), and stores the returned timestamp token with the experiment record in an immutable, archived ZIP file (visible via "Show Archived" in the Attached Files section).
| TSA Provider | Notes |
|---|---|
| DFN.de | Free academic service — the default TSA |
| Universign | eIDAS qualified, paid service |
| Digicert | Free |
| Sectigo | Free |
| GlobalSign | Free |
| Evidency | eIDAS qualified, requires account |
| Custom | Any RFC 3161-compliant TSA can be configured by the SysAdmin |
A timestamp token can be independently verified at any time with openssl against the exported JSON and token files — you don't need LabLynx One itself to confirm a timestamp's validity, only the public certificate chain of the TSA that issued it.
Why does an external timestamp matter when LabLynx One already records system timestamps on every save? Because an external timestamp is mathematically independent. An RFC 3161 token from a TSA cannot be fabricated without the TSA's private key. A database administrator could theoretically alter internal timestamps in a database. A TSA token cannot be altered after issuance. For IP disputes, regulatory submissions, and court proceedings, independent third-party-certified proof of existence is qualitatively different from internal system timestamps.
A researcher at a neurotechnology startup develops a novel electrode impedance matching algorithm. She documents it in an LabLynx One experiment and immediately applies an RFC 3161 timestamp. Seven months later, when a competitor files a patent on a similar algorithm, her attorney demonstrates that the timestamp token — issued by an independent TSA — proves her client's documentation preceded the competitor's filing date.
7.4 Blockchain Timestamping
LabLynx One supports timestamping via the Bloxberg consortium blockchain — an Ethereum-based research blockchain operated by the Max Planck Society and partner institutions. A hash of the entry is committed to the blockchain ledger, providing decentralized, permanent proof of existence. A PDF certificate is included in the resulting archive.
Blockchain timestamping is particularly appropriate for academic research (data sharing, grant compliance), cross-institution collaborations, and situations where decentralized proof (no single authority) is preferable.
Audit Trail and Data Integrity
LabLynx One is designed around ALCOA+ data integrity principles — Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available. Every component of the audit system exists to satisfy one or more of these principles.
8.1 Changelog — Field-Level History
Every change to every field of an experiment or resource — title, status, category, tags, permissions, metadata values, linked entries, step completions, signature events, timestamps — is captured in the Changelog with the prior value, new value, user identity, and system-generated timestamp. The Changelog is read-only, permanent, and cannot be deleted or modified by any user including administrators.
Access: Ellipsis menu (…) → See Changelog on any entry.
An FDA inspector asks: 'How do you know the status of this experiment was not changed after the data was reviewed?' The analyst opens the Changelog and shows: 'Status changed from Pending Review to Approved at 14:32:07 on 2026-05-15, by Dr. Jessica Martin.' A single, unambiguous, system-generated, immutable record — not a statement by the analyst, but a database entry the system created automatically.
8.2 Revisions — Main Text Version History
Changes to the main body of an experiment are tracked by the Revisions system. Each save creates a new version. The Revisions page (Ellipsis → See Revisions) shows all versions with timestamps and authors, allows side-by-side version comparison, and enables restoring any prior version.
The revision system makes the body text equally trustworthy as the structured fields. Without revision history, a researcher could rewrite their experimental narrative after seeing the results, creating a record that is internally consistent but historically inaccurate. With revision history, the original account of what happened is always recoverable, and every subsequent change to the narrative is documented.
8.3 ELabID — The Permanent Unique Identifier
Every experiment and resource in LabLynx One is assigned an ELabID at creation. The ELabID is system-generated, permanent, and cannot be changed or reassigned. Use the ELabID to cite specific LabLynx One records in external documents, publications, patent applications, or regulatory submissions — providing a permanent cross-reference that links the citation back to the original record.
8.4 Locking, Archiving, and the Deletion Model
| State | What It Means | When to Use It |
|---|---|---|
| Locking | Prevents further editing. Lock event logged. Only owner or Admin can unlock. | After completing and reviewing. Before or after signing. |
| Archiving | Moves entry out of the active index without deleting. Still accessible via State filter. | Project completion, superseded versions, closed cases. |
| Soft Delete | Marks as deleted but preserves in database. Recoverable via State filter. | Accidental or erroneous entries. Never for GxP records without authorization. |
8.5 ALCOA+ Compliance Summary
| ALCOA+ Principle | How LabLynx One Delivers | LabLynx One Feature |
|---|---|---|
| Attributable | Every action linked to authenticated user identity. No shared logins. SSO/MFA integration confirms identity. | Changelog, user attribution on all saves |
| Legible | Rich text editor; PDF exports; full-text search indexing. | Main text, metadata fields, PDF export |
| Contemporaneous | System-generated timestamps. Cannot be backdated by users. | All save timestamps, Step completion timestamps |
| Original | Raw data files attached directly to entries. Revisions preserve all prior versions. | File attachments, Revisions history |
| Accurate | Validated workflows, required fields, dropdown fields preventing free-form errors. | Template metadata fields, locked steps |
| Complete | Templates define required fields. Locked steps enforce complete procedure documentation. | Template configuration, locked steps |
| Consistent | Standardized templates across the team. Agreed tag vocabularies. Category-based classification. | Templates, tag vocabulary, categories |
| Enduring | sciCloud.net® hourly backups, geographically redundant storage, AWS infrastructure, 99.8% SLA. | Hosting architecture, backup policy |
| Available | Web-based access from any device; full-text search; role-based permissions for authorized access. | All access methods, export features, search |
8.6 The System-Level Audit Log (Distinct from the Changelog)
The Changelog (8.1) and Revisions (8.2) track changes to individual experiment/resource records. Separately, LabLynx One maintains a system-level Audit Log that immutably records security- and administration-relevant events across the whole instance. A SysAdmin views it from the Audit Logs tab of the Sysconfig panel.
| Category | Recorded When |
|---|---|
| Login / Logout | Every authentication event, success or failure |
| AccountCreated / AccountValidated / AccountArchived / AccountDeleted / AccountModified | Any change to a user account's lifecycle state |
| PasswordChanged / PasswordResetRequested | Credential changes |
| Users2TeamsModified | A user is added to, removed from, or reassigned between teams |
| ApiKeyCreated / ApiKeyDeleted | API key lifecycle events |
| ConfigModified | Any instance-wide configuration parameter changes |
| Export / Import | Bulk data export or import operations |
| SignatureKeysCreated / SignatureCreated | Cryptographic signature key generation or signature application (Chapter 7) |
| ActionRequested | A "Request Action" notification (Archive/Lock/Review/Sign/Timestamp) is sent to another user |
For a centralized SIEM or log-aggregation setup, the SysAdmin can enable "Emit audit logs with PHP error log" (Audit Logs tab, Sysconfig panel) so every event above is also written as a structured JSON line to the container's standard log stream — see the IT Admin Manual, Chapter 11, for the log-shipping configuration.
Collaboration and Sharing
Science is collaborative. LabLynx One provides structured tools for sharing work within teams, routing records through formal review processes, and enabling access for collaborators outside the immediate team — while maintaining the integrity, attribution, and auditability of every shared interaction.
9.1 Sharing Within the Team
Within a team, sharing is controlled by each experiment's permission setting. Team Admins can view all experiments in their team regardless of individual permission settings — enabling supervisors to review student or staff work without requiring each researcher to manually share every entry.
9.2 Request Action — Structured Review and Approval Workflows
The Request Action feature sends a formal, trackable notification to any LabLynx One user requesting them to perform a specific action on an experiment. It converts the informal 'can you please sign my experiment' email into a system-documented workflow event.
| Action Type | What It Requests |
|---|---|
| Archive | Request the recipient to archive this experiment. |
| Lock | Request the recipient to lock this experiment after their review. |
| Review | Request the recipient to read and provide feedback via comments. |
| Sign | Request the recipient to apply their electronic signature. The most common workflow. |
| Timestamp | Request a QA lead or supervisor to apply a trusted timestamp. |
Email-based review workflows are the silent enemy of data integrity audits. They are irretrievable (deleted emails), unstructured (no guarantee the reviewer saw the final version), external to the record (the review is not attached to what was reviewed), and undatable by anyone not on the email thread. Request Action moves the review and approval conversation inside the LabLynx One record, where it is part of the same audit trail as the record itself.
9.3 Cross-Team and External Collaboration
Experiments set to 'Organization' permission level are visible to all teams on the LabLynx One instance. For collaborators outside the instance entirely, there are three supported approaches:
| Option | How It Works | Best For |
|---|---|---|
| Export and send | Export the entry to PDF or ZIP and send it by email or file transfer. | One-off sharing where the recipient never needs live/updated access. Works everywhere, no configuration required. |
| Anonymous access link | If the SysAdmin has enabled anonymous access instance-wide, any user can generate a read-only link (with an access key embedded in the URL) from an entry's Visibility/Permissions panel. Unchecking the option invalidates all previously shared links for that entry. | External reviewers or collaborators who should see the record evolve over time without needing an account. Requires the instance to be reachable from outside your network. |
| Guest / external-collaborator account | Add the external person as a proper user (often to a dedicated "External Collaborators" team), then grant them access to specific entries via the Permissions panel — add a whole team, a user group, or a single named user. | Ongoing collaborations where the collaborator should log in, comment, and follow multiple entries over time. |
Each option trades off convenience against control. Export-and-send requires no configuration but produces a static snapshot. The anonymous link stays live but is scoped to read-only and can be revoked instantly. A named guest account gives the richest access (including commenting) but requires the SysAdmin or Admin to provision an account. Choosing deliberately among the three — rather than defaulting to email attachments for everything — keeps the audit trail intact even when work crosses institutional boundaries.
9.4 Transferring Ownership
Ownership of an experiment can be transferred from one user to another via the Ellipsis (…) menu. The original owner's identity remains in the audit trail and creation records — it is not erased. The transfer event itself is logged.
In a paper notebook, when a researcher leaves, the notebook often becomes inaccessible. The institution loses both the data and the context needed to interpret it. LabLynx One's ownership transfer model ensures that all experiments remain institutionally owned and accessible, regardless of personnel changes — directly addressing one of the most common causes of irreproducible research.
Import, Export, and the REST API
LabLynx One is designed as an open system: data can be exported in multiple formats, imported in bulk, and accessed programmatically via a comprehensive REST API. This openness is fundamental to LabLynx One's role in the laboratory data ecosystem — it is a record-keeping hub, not a data silo.
10.1 Exporting Experiments — Four Formats
| Format | Description and Use Cases |
|---|---|
| Fully formatted, human-readable document with all experiment fields, body text (including images and tables), metadata, steps, attachments list, and audit summary. For regulatory submissions, external sharing, printing, and archiving. | |
| ZIP Archive | All files associated with the experiment: the PDF, all attachments in original format, and a JSON metadata file. A complete, self-contained archive of everything in the record. For long-term archiving and offline backup. |
| ELN Format (RO-Crate) | A machine-readable archive format based on the Research Object Crate specification, defined by The ELN Consortium. Interoperable with other compliant ELN systems. For cross-institution data sharing and research data repository submission. |
| CSV / JSON (API) | Individual fields and metadata can be exported programmatically via the REST API. Custom export scripts can extract specific data sets for analysis, reporting, or LIMS integration. |
10.2 Importing Data — .eln Archives and CSV
LabLynx One supports two import file types: .eln (an interoperable ELN Consortium archive format) and .csv.
| Import Type | What It Carries | How to Import |
|---|---|---|
| .eln archive | Experiments, experiment templates, resources, and resource categories — from LabLynx One or any ELN Consortium-compliant system. Entry type is detected automatically via the archive's genre attribute, or can be forced manually. | Web: Profile menu → Import tab, select the file. CLI (SysAdmin, for large team migrations): copy the file into the container's /elabftw/exports folder, then run docker exec -it -u nginx:nginx elabftw bin/console import:eln your.eln <TEAM_ID>. |
| .csv file | Resource records from a spreadsheet or external LIMS/inventory system. | Clean the file first (flat structure, header row, no empty rows/duplicate column names), then import via the web interface. |
The CLI import path is the recommended approach for large archives (e.g., a full team's data when migrating between institutions) since it avoids the web request timeouts a large upload could hit. By default, ownership of imported items is matched by comparing email addresses between the source and destination instances — useful for moving a whole team's data intact — but a specific user can also be forced with the --userid option.
10.3 The REST API — Connecting LabLynx One to the Laboratory Ecosystem
LabLynx One exposes a comprehensive REST API that enables programmatic read and write access to experiments, resources, templates, and the user directory. Every action possible in the user interface can be performed via the API. Authentication uses personal API keys generated in Account Settings.
| Integration Pattern | How It Works |
|---|---|
| Instrument data push | An instrument controller creates a new LabLynx One experiment automatically after each run, populates metadata with run parameters, and attaches the raw data file. |
| LIMS synchronization | A LIMS system that manages sample receipt creates a corresponding LabLynx One experiment for each sample, pre-populating the Custom ID with the LIMS accession number. |
| Automated reporting | An overnight script queries LabLynx One for all experiments completed in the past 24 hours and populates a daily QC dashboard. |
| Data analysis pipeline | An R or Python script reads result data from LabLynx One experiments, performs statistical analysis, generates a figure, and posts the figure back as an attachment. |
| ERP / procurement sync | When a purchase order is approved in an ERP system, the API automatically updates the corresponding Resource entry with the new lot number, quantity, and expiry date. |
Compounds, Containers, and Special Features
Beyond the core experiment and resource system, LabLynx One includes specialized modules for chemical compound management, hierarchical physical storage tracking, QR code labels, and a free-form drawing tool.
11.1 Chemical Compounds Database
Accessible from the Tools menu, the Compounds database is a single, instance-wide registry shared by every team — not team-scoped like Experiments or Resources. Compound visibility cannot be restricted: any compound you add, whether imported or manual, is visible to every user on the instance. Each compound entry stores: chemical name, CAS number, a SMILES or InChI representation, and associated GHS safety hazards (including whether it's a controlled substance such as a drug precursor or a nanomaterial).
Compounds can be added two ways:
- Import from PubChem: Click "Import from PubChem" on the Compounds page, search by PubChem CID or CAS number, preview the result, and click Import.
- Add manually: For a novel compound not yet in PubChem, click "Add compound." Only the Name field is required.
From a compound's edit window, click "Create resource from compound" to instantiate a Resource linked to that compound — the Resource carries permissions, inventory, attachments, and links, while the Compound record itself remains the shared, abstract chemical reference. A Resource or Experiment can link to multiple compounds at once, useful for representing a mixture.
Integrating GHS hazard information directly into LabLynx One entries serves two purposes simultaneously: (1) Safety information is always co-located with the experiment where the chemical is used. (2) The experiment record documents that the hazard information was available at the time the work was planned, supporting laboratory safety compliance requirements.
Fingerprinting and Substructure Search
When a compound has a SMILES representation and the instance's fingerprinting service is enabled, LabLynx One stores a molecular fingerprint alongside it, enabling substructure search across the shared compound database. A dedicated chemical structure editor (Tools menu) lets you draw a molecule and search for structurally similar compounds already in the database — click the (?) icon in the editor for built-in usage help.
11.2 Inventory Locations and Containers — Physical Storage Tracking
Physical storage tracking uses two linked concepts, both reachable from the Tools menu's Inventory page:
- Inventory Locations: The physical hierarchy itself — buildings, rooms, freezers, shelves, boxes. You start by adding one or more Root elements (e.g., a building), which cannot directly hold anything stored; add children beneath a root to build out the actual storage tree (room → freezer → shelf → box position).
- Containers: The stored quantity itself, added from within an Experiment or Resource entry's "Containers" section. When adding a container you specify quantity, unit, and optionally a multiplier (e.g., 3 jerrycans of 5L), then choose "Store in…" to place it at a specific Inventory Location.
Building → Room 204 → Freezer F-01 → Shelf 3 → Box B-12, position A-1 holds a container linked to the Resource entry "HEK293 Cell Stock, Passage 12, 2026-04-15." Scanning the QR code on the vial opens that Resource entry directly: full provenance (who prepared it, from which parent stock, passage number, cryoprotectant, and all experiments where cells from this stock were used) is immediately accessible.
Export a CSV of all containers your team can see from the Export button on the Inventory page. A SysAdmin can pull a complete instance-wide inventory report — regardless of read permissions — from "Get inventory report" in the Sysconfig panel, useful for facility-wide chemical/asset audits.
11.3 QR Code Labels
LabLynx One generates QR code labels for any Experiment or Resource entry. Scanning the label with a mobile device opens the entry directly in LabLynx One (when authenticated). Common uses:
- Sample tubes and vials: Scanning opens the sample Resource entry with full provenance.
- Equipment: Scanning opens the instrument Resource entry with calibration status and usage history.
- Storage containers: Scanning opens the container map for that box.
- Chemical bottles: Scanning opens the compound entry with GHS information.
11.4 The Draw Tool
Each Experiment and Resource entry includes a Draw Tool — a free-form drawing canvas for creating plate layouts, apparatus sketches, flow diagrams, or simple annotations directly within the entry. The Draw Tool is particularly useful for plate layout documentation: sketch a 96-well plate, label wells with treatment conditions, and leave a legend.
Configuration Patterns by Laboratory Type
LabLynx One's flexibility means it can be configured very differently for different types of laboratories. The following patterns show how LabLynx One is configured for five specific laboratory environments. Each can be implemented using only the features described in this manual.
12.1 Academic Research Lab
Goals: Reproducibility, collaboration, grant compliance, IP documentation, publication support, student training.
| Configuration Area | Recommended Setup |
|---|---|
| Experiment Categories | One per technique: Western Blot, PCR, FACS, Microscopy, Sequencing, In Vivo, Data Analysis, Meeting Notes, Literature Review. |
| Resource Categories | Cell Lines, Antibodies, Plasmids/Constructs, Chemicals, Equipment, Projects (one per grant), Personnel. |
| Template Design | Each technique template includes: hypothesis field, expected outcome field, controls checklist (locked steps), result fields, conclusion section. |
| Permissions | Team-wide read. Individual write. PI (Admin) can always see all entries. |
| Signature Workflow | Researcher signs when complete. PI signs for publications and grant reports. RFC 3161 timestamp on key result experiments before locking. |
12.2 Pharmaceutical / Biotech QA Lab
Goals: 21 CFR Part 11 compliance, CAPA management, method validation, batch record documentation.
| Configuration Area | Recommended Setup |
|---|---|
| Experiment Categories | Method Validation, HPLC Runs, Batch Record, CAPA, NCR, OOS Investigation, Stability Study, Audit, Change Control. |
| Template Design | All analytical templates require: instrument (Resource Link), analyst, date, lot numbers. CAPA template: root cause, scope, corrective action, effectiveness review date, closure signature. All critical templates have locked steps. |
| Permissions | Analyst: read-write own entries. QA Reviewer: read + comment. QA Manager: sign and lock on critical records. |
| Signature Workflow | Prepared By (analyst) → Reviewed By (QA) → Approved By (QA Manager). RFC 3161 timestamp on all approved records. |
| MFA | Required for all user accounts. Enforced at the team or system level. |
12.3 Forensic / Crime Laboratory
Goals: Chain of custody integrity, evidence traceability, court-ready records.
| Configuration Area | Recommended Setup |
|---|---|
| Experiment Categories | Case Intake, Evidence Examination, QC Run, Peer Review, Court Report, OOS Investigation, Training Record. |
| Custom ID | Case Intake category: auto-incrementing sequential case numbers matching the lab's existing paper system. |
| Template Design | Case Intake: submitting agency, case type, priority, evidence item list (metadata fields). Evidence Examination: evidence item # (Resource Link), examination method, instrument, result, locked QC checklist steps. |
| Signature Workflow | Examiner → Peer Reviewer → Lab Director in sequence before locking. Three-level cryptographic signature chain. |
| Locking Policy | Lock all completed case records immediately after final signature. RFC 3161 timestamp before locking on court-bound records. |
12.4 Neurotechnology / Medical Device R&D Startup
Goals: Multi-team ELN, 21 CFR Part 11 readiness, IP protection, rapid deployment.
| Configuration Area | Recommended Setup |
|---|---|
| Team Structure | Separate LabLynx One Teams: Hardware Engineering, Microfabrication, Chemistry, In Vivo/Clinical, Quality & Regulatory. Cross-team visibility where appropriate. |
| Resource Categories | Implant Devices (by serial number), Animal Subjects, Surgical Instruments, Software Versions, Study Protocols, Personnel. |
| IP Protection Workflow | Novel discovery: RFC 3161 timestamp immediately upon documentation. Ed25519 signature by the inventor. Cited in patent application as prior art evidence. |
| Compliance Trajectory | Start with team-wide access and simple lock workflows. As clinical trials approach, activate cryptographic signatures, RFC 3161 timestamps, and mandatory MFA. LabLynx One grows with the organization. |
12.5 ISO 17025 Quality / Analytical Testing Lab
Goals: Traceable method execution, equipment management, QC documentation, audit readiness.
| Configuration Area | Recommended Setup |
|---|---|
| Experiment Categories | Routine Analysis (per method type), Method Development, Method Verification, QC Check, Equipment Calibration, Proficiency Testing, Corrective Action. |
| Template Structure | One template per accredited method. All steps locked. Method version is a required metadata field. Template reviewed and approved by the quality manager before release. |
| Equipment Management | All instruments are resource records with: calibration due date (Date field), calibration certificate number (Text), last maintenance record (linked experiment), status (In Service/Out of Service/Under Maintenance). |
| QC Integration | QC Run template: acceptance criteria (metadata fields), measured values (Number fields), Pass/Fail (Dropdown), instrument (Resource Link). Failing QC automatically linked to an OOS Investigation experiment. |
| Signature Workflow | Analyst (Prepared By) → Technical Manager (Reviewed By) on all test reports. RFC 3161 timestamp on final test reports before delivery to customer. |
Tips, Best Practices, and Common Pitfalls
Practical habits that make LabLynx One work better every day — and the most common mistakes to avoid.
13.1 Daily Use Habits That Make a Difference
| Habit | Why It Matters |
|---|---|
| Document before you analyze | Create and populate the experiment record before you open your results in a spreadsheet or analysis software. Prevents the unconscious bias of shaping the record around a result you already know. |
| Attach raw data immediately | As soon as an instrument produces output, attach the file to the corresponding experiment. Files not attached immediately get lost, renamed, or forgotten. |
| Use descriptive titles | Spend 30 seconds writing a title that describes the experiment's content: technique, key variable, purpose. This investment compounds over time as your records become self-findable. |
| Check off steps as you go | Check off each step at the moment of completion — not all at once at the end of the procedure. A step checked off at the end of the day loses its timestamp value as evidence. |
| Comment generously | Add comments when you notice something unexpected, make an unplanned deviation, or have a retrospective insight. Comments cost 30 seconds; reconstructing undocumented observations can take days. |
| Link as you work | When you use a reagent, link the experiment to the reagent's resource record. Links are trivially easy to create and enormously valuable to follow later. |
13.2 Common Pitfalls and How to Avoid Them
| Pitfall | Problem It Creates | How to Avoid It |
|---|---|---|
| Vague experiment titles | 'Experiment 7' is unsearchable and meaningless to anyone but the creator. | Write titles that include technique, variable, and purpose. Adopt a team naming convention before rollout. |
| Skipping templates | Inconsistently structured entries cannot be filtered by metadata. | Invest one hour in template design per experiment type before team rollout. |
| Re-typing instead of linking | Writing 'Antibody lot AB-2024-441' in 50 experiments means you cannot filter by lot. Lot details are not structured data. | Create a Resource entry and link to it. Re-typed text is not a structured filter. |
| Ignoring Scope | 'I can't find my experiment' is usually a scope problem. | Check scope is 'Team' or 'Everything' before concluding an entry is missing. |
| Not locking completed records | An unlocked experiment is implicitly 'in progress'. Especially problematic in regulated environments. | Lock records when complete and reviewed. |
| Storing large files directly in LabLynx One | Files over 100 MB slow database queries. | Store large instrument data in LabDrive; link via URL metadata field. |
| Inconsistent tag vocabulary | If two researchers create a 'project1' tag for different projects, filters become meaningless. | Agree on a tag vocabulary as a team and document it. |
13.3 Five Template Design Principles
- Design for the most junior user, not the most experienced one. A template that an experienced researcher considers over-specified gives a new team member everything they need without asking.
- Include all fields you will ever need for analysis, not just the ones you think you will use. Storage costs nothing. Missing data costs everything.
- Lock only what must not vary. If a step ever needs legitimate modification, locking creates unnecessary friction. Lock only steps that have regulatory, compliance, or quality force.
- Version your templates. When a protocol changes, create a new template version. Archive the old one. Old experiments retain their original structure.
- Review templates quarterly. Assign a template owner responsible for reviewing and maintaining each template in the team library.
Support and Resources
LabLynx is committed to the success of every LabLynx One deployment. Support resources are available at multiple levels, from self-service documentation to direct access to the LabLynx technical team.
| Resource | Details |
|---|---|
| LabLynx One Knowledge Base | Searchable self-service documentation covering all features, configuration options, and common workflows. Available at: support.lablynx.com |
| Email Support | Direct access to the LabLynx technical support team: support@lablynx.com |
| Onboarding Consultation | LabLynx provides structured onboarding sessions: system configuration review, template design assistance, user training, and workflow setup. |
| Account Management | Your dedicated LabLynx account manager for strategic discussions, product roadmap questions, and expansion planning. |
| Product Website | www.elabeln.com — Product information, features, pricing, and updates. |
| LabLynx Corporate | www.lablynx.com — Full LabLynx platform: ELab LIMS, LabDrive, LabVia, LabVista, LabGRC, LabCourses. |
| sciCloud.net® | Managed cloud hosting: AWS-based, SOC 2, 99.8% uptime SLA, hourly backups, AES-256 encryption, geographically redundant. |
"LabLynx One is more than software — it is a partnership between your laboratory and LabLynx. We manage the infrastructure, the security, the backups, and the updates so your team can manage the science. If you have a configuration question, a workflow challenge, or a compliance requirement you are not sure how to address in LabLynx One, we are a direct email away."
support@lablynx.com | www.lablynx.com | www.elabeln.com
LabLynx One Administrator Manual
For team and system administrators configuring LabLynx One.
Who This Manual Is For
This manual is written for LabLynx One administrators at two levels. Understanding which level applies to you determines which chapters are your primary reference.
If you are a Team Admin but not a SysAdmin, Chapters 2–8 are your primary reference. If you are a SysAdmin, all chapters are relevant. Many SysAdmins also act as Team Admin for one or more teams.
Each feature in this manual is explained with what it does, why it works that way, and how different organizations use it. Cross-industry examples throughout show how the same configuration tools serve academic, pharmaceutical, forensic, clinical, and quality laboratory environments.
LabLynx One Administration Overview
LabLynx One uses a three-tier model separating User, Team Admin, and SysAdmin responsibilities. This hierarchy ensures that each level of administration has exactly the access it needs — and no more.
1.1 The Three-Tier Administration Model
| Role | Scope and Capabilities | Typical Persons |
|---|---|---|
| User | Creates, edits, and manages their own experiments and resources within team-defined settings. Cannot change any team or system configuration. | Researchers, analysts, students, technicians |
| Team Admin | Manages everything within a single team: users, categories, templates, statuses, tags, user groups, permissions defaults, exports, and batch actions. Can view all team experiments regardless of individual permission settings. | Lab managers, PIs, quality managers, department leads |
| SysAdmin | Manages the entire LabLynx One instance: all teams, all users, authentication settings, security policies, email configuration, and instance-wide defaults. Inherits all Admin capabilities across all teams. | IT administrators, LabLynx support contacts, platform owners |
The three-tier model prevents privilege escalation while enabling local autonomy. A Team Admin can configure everything their team needs without having access to other teams' data or system-level settings. A SysAdmin can manage the infrastructure without needing to know the scientific content of individual experiments. Each tier's capabilities are scoped to its legitimate administrative domain.
1.2 Accessing Admin Panels
Both Admin panels are accessed from the top-right user menu after logging in:
- Team Admin Panel: Click your user avatar (top right) and select Admin Panel. This panel is visible only to users with Admin or SysAdmin role.
- SysAdmin Panel (Sysconfig): Click your user avatar and select Sysconfig. This option appears only for SysAdmin accounts.
If you do not see Admin Panel or Sysconfig in your user menu, you do not have the required role. Contact your SysAdmin to request elevated access.
1.3 sciCloud.net® (Cloud) vs. LabServer (On-Premises)
| Deployment Model | SysAdmin Responsibilities |
|---|---|
| sciCloud.net® (LabLynx-managed) | LabLynx manages infrastructure, server maintenance, SSL certificates, software updates, database backups, and disaster recovery. Your SysAdmin manages users, teams, and application-level configuration. |
| LabServer (on-premises) | Your IT team manages the physical/virtual server, operating system, Docker container orchestration, backups, and SSL. Your SysAdmin manages application configuration in addition to infrastructure. LabLynx provides technical support and guidance. |
1.4 The Instance Coordinator Role (Optional)
Beyond the three-tier User / Team Admin / SysAdmin model, larger deployments can designate an Instance Coordinator — a person (not a separate account permission level) responsible for the human side of running LabLynx One across many teams: onboarding, training, documentation standards, and exit strategies when a user leaves a team.
| Coordinator Responsibility | What It Covers |
|---|---|
| Training & onboarding | Organizing training sessions and maintaining an internal help channel (Slack/Teams/forum) for user questions. |
| Documentation standards | Defining what makes a complete experiment record (clear title, date, description, attachments) and promoting consistent naming/tagging conventions. |
| User exit strategies | Deciding whether a departing user's account should be archived (data preserved, login disabled) or moved to another team, working with the Team Admin or SysAdmin to execute it. |
| Compliance reinforcement | Reminding users of 2FA, access-control, and data-handling policies that apply to their organization — the Coordinator doesn't set these policies but helps ensure they're followed day-to-day. |
A Coordinator does not require special LabLynx One permissions to do this job — the role is organizational, not a distinct account privilege. In practice it's often filled by a Team Admin or the SysAdmin, especially in smaller labs, but larger multi-team instances benefit from having someone dedicated to it.
Team Settings — The Admin Panel Overview
The Admin Panel is the Team Admin's primary workspace. It is organized into tabs, each covering a distinct area of team management. This chapter provides a complete reference to every tab and setting.
2.1 Admin Panel Navigation
Access: User Avatar → Admin Panel. The panel opens showing the following tabs:
| Tab | What It Does |
|---|---|
| Team | General team settings: name, visibility, default behaviors, onboarding messages, and what users can and cannot do. |
| User Groups | Create and manage groups of users for granular permission targeting (e.g., QA Team, Analysts, Supervisors). |
| Users | View, validate, edit, and manage all users associated with your team. |
| Export | Bulk export experiments, resources, or booking data from your team. |
| Tag Manager | Edit, merge, and normalize existing tags across your team. |
| Batch Actions | Execute administrative actions on many entries simultaneously (e.g., change visibility, reassign ownership). |
2.2 The Team Tab — General Settings
Team Name and Visibility
The Team Name is the display name visible to all users when they switch teams or create entries. Choose a name that is clear and unambiguous — particularly important in multi-team instances where users might belong to five or more teams.
Team Visibility controls whether the team is visible to non-members. In most cases this should be set to Private. Setting it to Public makes the team's name discoverable to all authenticated users on the instance — appropriate for shared core facilities or institutional resource pools.
Default Experiment Permissions
- Only Me (Private) — New experiments are private to their creator by default. Recommended for labs with sensitive or unpublished research.
- My Team — New experiments are visible to all team members by default. Recommended for collaborative labs where sharing is the norm.
- Organization — Visible to all teams in the instance. Rarely appropriate as a default; used for shared resource teams.
The default permission setting shapes your team's documentation culture without removing individual control. A default of Private encourages researchers to be intentional about sharing. A default of Team encourages open collaboration and reduces the chance that important work is invisible to colleagues who need it. Neither is universally correct — choose based on your team's research culture and IP sensitivity.
- Academic research lab: Default to Team. Students can see each other's work and learn from it.
- CRO or multi-client lab: Default to Only Me. Each researcher's data is private until explicitly shared within the client project team.
- Pharma QA: Default to Team so supervisors can see all in-progress QA records. Combined with read-only permission defaults, this gives visibility without edit risk.
User Registration and Validation Settings
- Allow users to self-register: When enabled, anyone who navigates to your LabLynx One URL can create an account and request to join your team.
- Require Admin validation of new accounts: When enabled, new accounts appear in a pending state and cannot log in until an Admin validates them.
Manual validation is a security control. In an open academic environment where any university email can register, validation lets the Admin confirm that the new account belongs to a genuine team member before granting access to any team data. In closed environments with SSO-only authentication, validation may not be necessary because identity is already verified by the identity provider.
A new QA analyst joins the pharmaceutical company. HR provisions her in Active Directory. She navigates to the LabLynx One instance and SSO redirects her to log in with her company credentials. Her account is created in LabLynx One but appears in the Admin Panel's pending validation list. The QA Manager (Admin) sees the pending account, verifies it matches the expected new hire, validates it, and assigns her to the correct user groups. The analyst can now log in with full access to the team.
Onboarding Message
The onboarding message is displayed to users the first time they log in, or persistently as a banner at the top of all team pages. Use it to communicate: team naming conventions, required tags, which templates to use for the most common experiment types, and who to contact with questions.
Write the onboarding message as if you are talking to someone who has just joined the team and opened LabLynx One for the first time. Include: (1) your team naming convention, (2) the 3–5 most important tags to apply to every experiment, (3) which templates to use for common experiment types, and (4) who to contact with questions.
User Capabilities — What Team Members Can Do
| Capability Setting | Effect and When to Use It |
|---|---|
| Allow users to create new tags | When enabled, any user can create new tags. When disabled, only Admins can. Use to maintain a controlled tag vocabulary in compliance-sensitive environments. |
| Allow users to lock their own experiments | When disabled, only Admins can lock. Use in environments where locking is a QA or supervisory action rather than a researcher action. |
| Allow users to set experiment permissions | When disabled, the team default permission applies to all entries — users cannot restrict or expand access themselves. |
| Allow users to delete experiments | When disabled, only Admins can delete. Suitable for regulated environments where data retention requires Admin-authorized deletion. |
| Show team experiments in sidebar | When enabled, the left panel shows a summary of recent team experiments for at-a-glance visibility. |
| Force MFA for all team members | When enabled, MFA is required for every login by any member of this team. Users who have not enrolled are forced to enroll before accessing the team. |
- Academic lab: All capabilities enabled. Researchers have full control over their own data, can create tags freely, and can lock their own completed experiments.
- Pharma GMP: Tag creation disabled (controlled vocabulary only). Lock disabled for users (locking is a QA action). Deletion disabled for users.
- Forensic lab: User permissions disabled (all experiments inherit team defaults). Deletion disabled. MFA forced. Supports chain-of-custody and data integrity requirements of accreditation.
Managing Users and User Groups
The Users tab is the primary interface for managing team membership. User Groups enable granular, scalable permission management across experiments and resources.
3.1 The Users Tab — User Account Management
Validating New Accounts
When a new user registers or logs in via SSO for the first time, their account appears in the pending list at the top of the Users tab (if validation is required). To validate:
- Open Admin Panel → Users tab.
- Review the pending account: name, email, and registration date.
- Confirm the account belongs to a legitimate team member.
- Click Validate to activate the account, or click Delete if invalid or the account belongs to another team.
If a valid user appears to belong to the wrong team, contact your SysAdmin to reassign their team association rather than deleting and re-creating the account. Deleting an account removes all entries created by that user unless ownership was previously transferred.
Setting Account Validity Dates
Each user account can have a validity expiry date. After this date the account is automatically deactivated. This is particularly useful for temporary collaborators, visiting researchers, student accounts (expire at end of academic year), auditor accounts (expire after the audit period), and contractor accounts.
Set validity dates for all non-permanent accounts at the time of creation. This eliminates the administrative effort of manually deactivating accounts when users leave, and ensures access is automatically revoked even if HR offboarding does not trigger an IT action.
Adding Users Directly
If the SysAdmin has granted your team this capability, you can add users directly from the Users tab without requiring them to self-register. Enter the user's email address and click Add User. An invitation email is sent to the address.
Promoting Users to Admin
Any user in your team can be promoted to Admin role from the Users tab. Click the user's row, locate the role selector, and change from User to Admin. The promotion takes effect immediately on the user's next page load.
Admin promotion grants significant access: the promoted user can view all team experiments regardless of permission settings, modify all team configuration, validate or delete accounts, and run batch actions on all data. Promote only users who need these capabilities for a genuine administrative reason. In regulated environments, Admin access should be documented and reviewed periodically.
3.2 User Groups — Granular Permission Targeting
User Groups are named collections of users that can be referenced in experiment and resource permissions. Instead of sharing an entry with five named individuals, share it with the 'QA Review Team' group — all five get access, and when group membership changes, the sharing updates automatically.
Creating a User Group
- Open Admin Panel → User Groups tab.
- Click Create Group. Enter a descriptive name (e.g., 'QA Reviewers', 'Analytical Chemistry', 'External Auditors 2026').
- Type each member's name in the search box. Select from the autocomplete list.
- Click Save. The group is immediately available in permission selectors across all experiments and resources.
User Groups can include users from other teams on the same instance. This enables cross-team collaboration: a group called 'Joint Project Alpha' might include researchers from three different teams, all of whom can access experiments shared with the group.
| Group Example | How It Is Used |
|---|---|
| QA Reviewers | All QA staff in one group. Test records are shared with this group with read access, allowing any QA member to review without being individually listed on every record. |
| Instrument Operators — LC-MS | A group of analysts trained on a specific instrument. The LC-MS resource is shared with write access only to this group, preventing untrained staff from modifying calibration records. |
| External Auditors | A group containing auditor accounts. All completed, signed records are shared with this group during the audit window. After the audit, the group is emptied, revoking access from all auditors simultaneously. |
| Project Alpha Core Team | A group for a specific multi-person project. The project summary and all project resources are shared with this group with read-write access. As people join or leave the project, only group membership needs updating. |
User Groups solve the permission maintenance problem at scale. Without groups, a researcher who shares an experiment with 10 named colleagues must update 10 entries every time a colleague leaves or a new one joins the project. With groups, they update one group membership and all entries sharing with that group instantly reflect the change.
Configuring Experiment Categories and Status Values
Categories and Status Values define the vocabulary your team uses to classify and track experiments. Together they transform the experiment index from a flat list into a workflow management tool.
4.1 Experiment Categories
Categories are administrator-defined labels that classify experiment types. Each experiment belongs to exactly one category. Categories are displayed as colored pills in the experiment index, enable one-click filtering, and support independent custom ID numbering sequences.
Creating and Configuring Categories
- In Admin Panel → Team tab → Experiments section, click Add Category.
- Enter the category name (e.g., 'Western Blot', 'HPLC Run', 'Case Intake').
- Select a color for the category pill. Choose distinct colors — color-coding is a key usability benefit.
- Enable Custom ID auto-increment if you want sequential numbering within this category (e.g., WB-001, WB-002…).
- Save. The category is immediately available to all team users.
Limit your initial category set to the 8–12 most common experiment types. Creating 50 categories at setup produces a cluttered filter panel. Add categories as genuine needs emerge rather than trying to anticipate every possible experiment type upfront.
- Category 'Case Intake' → Custom ID enabled → generates 001, 002, 003… (independent sequence)
- Category 'Toxicology Analysis' → Custom ID enabled → generates TOX-001, TOX-002… (independent sequence)
- The Custom ID serves as the lab accession number, matching the case management system. Filtering by category + Custom ID range produces all toxicology analyses within a date range.
Category Planning by Lab Type
| Lab Type | Suggested Categories | Design Rationale |
|---|---|---|
| Academic Research | Protein Biochemistry, Cell Biology, Genomics, Animal Studies, Imaging, Data Analysis, Literature Review, Protocol Design | Technique-based taxonomy. Students intuitively understand the categories. |
| Pharma QA | Release Testing, Stability, Method Validation, In-Process Control, CAPA, NCR, Equipment Qualification, Internal Audit | Compliance-driven taxonomy matching GMP record types. |
| Forensic Lab | Drug Chemistry, DNA/Serology, Toxicology, Trace Evidence, Digital Evidence, Firearms, QC/Proficiency | Discipline-based taxonomy matching lab section structure. |
| ISO 17025 Testing | Routine Analysis, Method Verification, QC Check, Proficiency Testing, Equipment Calibration, Corrective Action | Quality-system driven taxonomy for traceable test records. |
| Neurotechnology R&D | Fabrication, Bench Characterization, In Vitro, In Vivo/Animal, Clinical, Data Analysis, Regulatory Documentation | Project-phase taxonomy across a product development pipeline. |
4.2 Experiment Status Values
Status values track where an experiment is in its lifecycle. LabLynx One ships with default statuses, but you should customize these to match your team's actual workflow states.
Creating and Editing Status Values
- In Admin Panel → Team tab → Experiments section, find the Status management area.
- Click Add Status. Enter a name and select a color.
- Optionally mark one status as the Default (automatically assigned to all new experiments).
- Reorder statuses by dragging to reflect the natural workflow order.
Delete unused default statuses. A status list with 12 options overwhelms users and produces inconsistent use. Aim for 5–8 clearly distinct states that represent meaningful points in your workflow.
- In Progress (green) — default for new experiments
- Pending QA Review (amber) — analyst complete, waiting for QA
- QA Reviewed (blue) — QA has reviewed, awaiting supervisor approval
- Approved (navy) — supervisor has signed and approved
- On Hold (orange) — work paused pending external input
- Rejected — Needs Rework (red) — QA identified issue, returned to analyst
- Closed (grey) — record complete, locked, signed, archived
Custom status values transform the experiment list from a flat archive into a workflow management tool. When a supervisor filters the index by 'Pending QA Review', they see exactly which records need their attention today. The status vocabulary is the bridge between LabLynx One's database and the lab's operational process.
Add a 'Calibration Overdue' or 'Out of Service' status for equipment resources. When an instrument goes out of service, updating its status prevents researchers from creating new experiments linked to that instrument without noticing the problem.
Templates — Admin Configuration and Governance
Templates are the most powerful tool available to Team Admins for driving documentation consistency. This chapter covers template governance — not just how to create templates, but how to maintain them, version them, and ensure they remain trustworthy records of your team's methods.
5.1 The Admin's Role in Template Management
Templates can be created by any user (personal templates, visible only to themselves) or by Admins (team templates, visible to all team members). The Admin's template responsibilities include:
- Creating and maintaining team templates representing the team's documented methods and workflows.
- Reviewing and promoting user-created personal templates to team status when they represent best practices worth standardizing.
- Versioning templates when methods change, and archiving superseded versions.
- Locking critical protocol steps to enforce SOP compliance.
- Designing the metadata field structure for each template type.
5.2 Creating Team Templates
- Navigate to Experiments → Templates. Click Create.
- Enter a descriptive template name including the method name, version, and relevant standard (e.g., 'Western Blot — Standard Protocol v2.1').
- Build the template: add body text structure, required metadata fields, and steps.
- Check 'Make available to team' before saving. This option is available to Admins; regular users can only create personal templates.
- Save and test the template by creating one experiment from it.
Template Design Principles for Admins
- Every template should have a designated owner — a specific person responsible for maintaining it.
- Include a 'Template Version' metadata field in every team template. When you update, increment the version. Experiments created from older versions retain their original version number, making it traceable which version of the method was in use at any given time.
- Document in the template body text which SOP, regulatory standard, or publication the template implements: "This template implements SOP-CHEM-047 Rev. 3".
- Review all team templates annually. Archive unused templates. Revise templates that are producing inconsistent data.
5.3 Locking Steps — Admin Controls
Step locking is configured in the template editor. Locked steps become read-only in all experiments created from the template: users can check them off but cannot edit the wording, reorder them, or delete them.
| Decision | Guidance |
|---|---|
| Lock these steps | Steps derived from validated SOPs or regulatory procedures. Steps with safety, compliance, or quality significance. Steps where deviation must be explicitly documented rather than silently skipped. |
| Do not lock these steps | Steps that serve as reminders but have legitimate adaptations. Steps that vary by sample type, scale, or condition. Steps added for user convenience that do not have compliance force. |
| Lock selectively | In procedures with mixed compliance and flexibility, lock the compliance-critical steps and leave guidance steps unlocked. Users see which steps are non-negotiable and which are flexible. |
- 🔒 LOCKED — Step 1: 'Verify instrument calibration certificate is current (due date > today)' — regulatory requirement
- 🔒 LOCKED — Step 2: 'Prepare primary standard per SOP-REF-012, record lot and expiry date' — GMP requirement
- 🔓 UNLOCKED — Step 3: 'Prepare test samples according to method specifications' — varies by sample matrix
- 🔒 LOCKED — Step 4: 'Document all deviations from the method in the experiment body before analysis' — QA requirement
- 🔓 UNLOCKED — Step 5: 'Run sequence as defined in instrument method file' — instrument-specific, may vary
- 🔒 LOCKED — Step 6: 'Calculate results per SOP-CALC-008 and complete result table below' — calculation procedure
- 🔒 LOCKED — Step 7: 'Request QA review before reporting results' — required workflow step
5.4 Template Versioning Strategy
| Scenario | Recommended Action |
|---|---|
| Method just created, no experiments yet | Edit the existing template directly. No version conflict. |
| Method in use, new version is a minor correction | Create a new template with updated content. Increment the version number in the template name. Archive the old template. Existing experiments retain the old structure. |
| Method in use, major revision or revalidation | Create a new template with a new name reflecting the major version (e.g., 'HPLC Method v1 — Legacy' archived; 'HPLC Method v2 — Validated 2026' created). Communicate the change to all users. |
| SOP retired, method discontinued | Archive the template. Do not delete — existing experiments created from it must remain accessible and their template reference must be preserved. |
Never edit a template in place when experiments already exist from it. If you change a locked step in the active template, all future experiments will reflect the change — but existing experiments already have the previous step wording locked in. The template version history becomes inconsistent, and an auditor will rightly ask why experiments from the same template have different steps. The correct model is: old template → archive; new template → create.
5.5 Resource Templates and Categories
Resource templates work identically to experiment templates but apply to resource records. Define resource templates for each resource category (Equipment, Reagents, Cell Lines, Reference Standards, etc.) to pre-populate the metadata fields relevant to that resource type.
Template name: 'Instrument — Analytical Equipment'
Metadata fields: Instrument Name (Text), Manufacturer (Text), Model (Text), Serial Number (Text), Asset ID (Text), Location (Text), Responsible Analyst (Select), Calibration Frequency (Select: Monthly/Quarterly/Semi-Annual/Annual), Last Calibration Date (Date), Next Calibration Due (Date), Calibration Certificate Number (Text), Current Status (Select: In Service/Out of Service/Under Calibration/Retired)
Steps (locked): Annual qualification checklist: 1) Verify current calibration certificate; 2) Check for any open corrective actions; 3) Confirm user qualification records are current; 4) Update status field.
Tag Management
Tags are user-created labels that enable flexible, multi-dimensional organization. As users create tags freely, inconsistencies accumulate over time. The Tag Manager gives you tools to clean up and normalize the tag vocabulary before it becomes unwieldy.
6.1 The Tag Manager
Access: Admin Panel → Tag Manager tab. The Tag Manager shows all tags in the team, the number of entries each tag is applied to, and the date each tag was last used. From here you can:
- Edit a tag name: Click the tag, change the name, and save. The tag is renamed on all entries — this is a rename, not a new tag.
- Delete a tag: Remove a tag and detach it from all entries. Use for abandoned tags, mistaken tags, or obsolete tags after a project closes.
- Merge tags: Rename Tag A to Tag B's exact name, then delete the now-duplicate. Achieves a merge in two steps.
6.2 Common Tag Normalization Tasks
| Issue | Resolution |
|---|---|
| Spelling variants | 'Western Blot', 'westernblot', 'WB', 'Western-Blot' — Rename all variants to the canonical form ('Western-Blot') using the edit function. |
| Capitalization inconsistencies | 'ProjectAlpha', 'projectalpha', 'Project Alpha' — normalize all to one form: 'ProjectAlpha' (no spaces, consistent capitalization). |
| Abandoned project tags | A project closed 18 months ago. Rename the tag to 'ARCHIVED-ProjectOld' to distinguish it from active project tags. |
| Personally-specific tags | A user created a tag with their own initials. If applied to shared entries, normalize to a team-standard form. |
| Accidental duplicates | A user pressed Enter twice and created an empty tag. Delete it. |
Schedule a Tag Manager review quarterly rather than waiting until the tag list becomes unwieldy. A 30-minute quarterly review prevents the exponential growth of tag variants. Send the normalized tag vocabulary to the team after each review so users know the canonical tags to use.
6.3 Controlling Tag Creation
For compliance or quality requirements demanding a strictly controlled tag vocabulary, disable 'Allow users to create new tags' in the Team tab. With this setting disabled:
- Only Admins can create new tags.
- Users can apply existing tags to their experiments but cannot create new ones.
- The tag vocabulary is fully controlled by the Admin team.
Controlled tag vocabulary is a tradeoff between flexibility and consistency. Unrestricted creation enables researchers to quickly capture labels without friction, but over time produces hundreds of near-duplicate tags. Most labs start with unrestricted creation and switch to restricted after accumulating enough data to know their stable vocabulary.
Bulk Export and Batch Actions
The Export tab and Batch Actions tab are the Admin's primary tools for large-scale data management — assembling audit packages, managing user departures, and maintaining the experiment index at scale.
7.1 Bulk Export
The Export tab allows you to export large sets of experiments or resources in a single operation, filtered by category, status, date range, user/owner, or tag before generating.
| Format | Use Case |
|---|---|
| Experiments (PDF) | Individual PDF files for each experiment. For human-readable archiving and regulatory review packages. |
| Experiments (ELN archive / ZIP) | Each ZIP contains the experiment JSON, PDF, and all attached files. For long-term archiving and cross-system transfer. |
| Resources (CSV) | Resource metadata as a spreadsheet. For inventory audits, equipment register reporting, and importing into external systems. |
| Scheduler (CSV) | All equipment bookings. For equipment utilization reporting and audit evidence of instrument access history. |
An ISO 17025 audit is scheduled for next week. The quality manager opens Admin Panel → Export, filters by Category = 'Routine Analysis', Status = 'Approved', Date range = last 12 months. She selects PDF format and clicks Export. LabLynx One generates a PDF for every approved routine analysis record from the past year — all methods, results, QC data, signatures, and timestamps assembled in minutes rather than days.
7.2 Batch Actions
| Action | When to Use It |
|---|---|
| Change visibility / permissions | Update the permission level of all experiments from a specific user, category, or date range simultaneously. Use after a project closes to make all project experiments read-only to non-owners. |
| Change ownership | Transfer all experiments from one user to another. Primary use case: user departure — move all experiments from the departing user to the PI or a successor before deactivating the account. |
| Change status | Update the status of many experiments simultaneously. Use at year-end to close all completed project experiments. |
| Lock entries | Lock a set of completed experiments simultaneously. Use at project closure or audit preparation. |
| Add tags | Apply a tag to a set of existing entries. Use to retroactively tag a group of experiments with a project tag. |
| Archive | Move a set of experiments to archived state simultaneously. Use at project completion to clear the active index without deleting historical records. |
Batch Actions are irreversible in their immediate effect. There is no 'undo' for batch permission changes, batch ownership transfers, or batch locking. Before running any batch action, filter the preview list carefully to confirm it contains exactly the entries you intend to affect. Run a small test batch on 2–3 entries before executing on hundreds.
- Export all experiments by the departing user (Export tab, filter by owner). Save the export package.
- Transfer ownership of all their experiments to the PI or team lead (Batch Actions → Change Ownership, filter by owner = departing user).
- Deactivate the user account (Users tab → set validity date to today or delete the account).
- Verify the transferred experiments are accessible to the new owner and that no entries were missed.
Result: No data loss. All experimental records are preserved under active ownership. The former user's access is revoked.
7.3 Usage Reporting
From the Admin Panel overview, Admins can generate a CSV usage report showing per user: experiments created, resources created, number of logins, and last login date. Use this to identify inactive accounts (90+ days without login), identify researchers not using LabLynx One, report adoption metrics, and provide evidence of system use for auditors.
Team Admin Best Practices and Workflows
Practical checklists and routines for setting up a new team, maintaining it over time, and documenting your own administrative activity in regulated environments.
8.1 New Team Setup Checklist
Complete the following in order to ensure users have a well-configured environment from day one:
- 1Team tab — GeneralSet team name, default permissions, registration/validation settings, and MFA requirement.
- 2Experiment CategoriesCreate 8–12 categories matching your experiment types. Assign distinct colors. Enable Custom IDs where needed.
- 3Experiment StatusesDefine 5–8 status values matching your workflow. Delete default statuses that do not apply. Set the correct default status.
- 4Resource CategoriesDefine resource categories. Create at least Equipment, Reagents, and Personnel categories.
- 5TemplatesCreate team templates for your 5–10 most common experiment and resource types. Test each template by creating one entry.
- 6User GroupsCreate the user groups you anticipate needing (QA, Supervisors, Project Teams, External Auditors).
- 7Onboarding MessageWrite and publish the onboarding message with naming convention, key tags, and template guidance.
- 8Pilot UsersInvite 2–3 pilot users and run them through a test workflow before full team rollout.
- 9Full RolloutInvite all team members. Validate accounts. Run onboarding session.
- 10First Quarterly ReviewAfter 90 days: review tag vocabulary, update templates based on user feedback, adjust status values.
8.2 Ongoing Admin Routines
| Frequency | Routine Tasks |
|---|---|
| Weekly | Review pending account validations. Check for experiments in long-standing 'Pending Review' status. Monitor the notification feed for system alerts. |
| Monthly | Review usage report: identify inactive users, follow up with non-adopters. Check for resource records with expired calibration dates or stock levels below minimum. |
| Quarterly | Tag Manager review: normalize tag vocabulary, merge duplicates, archive project tags. Template audit: verify all team templates are current with active SOPs. Update template version numbers as needed. |
| Annually | Full user audit: review all accounts, deactivate accounts for anyone who has left the team, verify Admin accounts are still appropriate. Full template governance review. Update team onboarding message for the new year. |
8.3 Compliance Documentation for Admins
In regulated environments, consider maintaining an 'LabLynx One Admin Log' experiment (using a dedicated template) to record:
- Template changes: when a template was updated, why, and what changed.
- Category changes: when a category was added, renamed, or archived.
- User access events: significant access grants, revocations, or role changes.
- Batch actions: what was done, to which entries, by whom, and the business reason.
- System configuration changes: any changes made at the SysAdmin level that affect the team.
The LabLynx One audit trail records what users do with experiments. It does not automatically document why an Admin made a configuration change. A separate Admin Log provides the rationale that auditors need: not just 'the template was changed on this date' but 'the template was changed to implement SOP Rev. 4 following validation completion'. This narrative context transforms audit trail data into a complete compliance record.
SysAdmin Overview — The Sysconfig Panel
The Sysconfig Panel is the SysAdmin's control center for the entire LabLynx One instance. Every setting here affects all teams on the instance.
Access: User Avatar → Sysconfig. Visible only to users with the SysAdmin role.
9.1 Sysconfig Panel Tabs
| Tab | What It Controls |
|---|---|
| Users | View and manage all user accounts across all teams: create, edit, promote, demote, deactivate. The master user registry for the instance. |
| Teams | Create, rename, configure, and delete teams. Set team-level defaults that supplement Admin configurations. |
| Configure the SMTP server for outgoing email: notifications, password resets, onboarding invitations. Required for most operational functions. | |
| Security | Password policy, login attempt limits, MFA enforcement, and session timeout settings. |
| Authentication | SAML/SSO configuration for external identity provider integration (Microsoft Entra ID, Okta, Google Workspace, LDAP). |
| Timestamping | Configure the RFC 3161 Timestamp Authority (TSA) endpoint for all teams. |
| API | Instance-wide API settings: enable/disable API access, configure API rate limits. |
| Notifications | System-wide notification behavior: which events generate notifications, email notification frequency, and digest settings. |
| Logs | Access instance-level audit logs: all user login events, authentication events, SysAdmin configuration changes, and system errors. |
9.2 First-Time SysAdmin Setup Checklist
Complete these SysAdmin tasks in order before inviting users:
- 1Email (SMTP)Configure email before anything else. Without email, users cannot reset passwords, receive notifications, or respond to Request Action events. Test by sending a test email from the panel.
- 2Security PolicySet password complexity, minimum length, and session timeout. Enable MFA if required by your organization or regulatory standards.
- 3AuthenticationIf using SSO, configure SAML settings and test with one pilot user account before enabling for all users.
- 4Create TeamsCreate all teams the organization needs. Assign at least one Admin to each team.
- 5TimestampingConfigure the default RFC 3161 TSA. Use DFN.de for academic deployments. Use a commercial TSA (DigiCert, Sectigo, GlobalSign) for regulated industry deployments.
- 6SysAdmin Backup AccountPromote at least one additional user to SysAdmin. Never have only one SysAdmin account — if that account is locked, the instance becomes unmanageable.
- 7Pilot TestLog in as a regular user and verify: registration, email, SSO (if configured), experiment creation, and email notifications all work correctly.
User Account Management at the System Level
The SysAdmin's Users tab in Sysconfig shows all user accounts across all teams on the instance — the master registry. SysAdmin-level user management capabilities extend beyond what Team Admins can do.
10.1 Creating User Accounts
Users can be created in three ways:
- Self-registration: The user navigates to the LabLynx One URL, creates an account, and is either immediately active or pending validation depending on team settings.
- Admin invitation: A Team Admin adds the user directly from the Admin Panel (if the SysAdmin has enabled this capability).
- SysAdmin creation: The SysAdmin creates the account from Sysconfig → Users. The recommended approach for batch onboarding of large groups.
Batch User Creation
For large deployments (department rollout, academic cohort), the SysAdmin can import users from a CSV file. The CSV must include: First Name, Last Name, Email, Team. The SysAdmin uploads the CSV, previews the import, and confirms. All accounts are created and invitation emails are sent automatically.
When importing users via CSV, prepare the team and Admin accounts first. New users are assigned to teams by name — the team must exist before the import. Test with a 5-row CSV before importing 200 users.
10.2 Team Assignment and Multi-Team Membership
Each user is associated with one primary team at account creation. The SysAdmin can assign a user to additional teams from the Users tab. Multi-team membership is common in:
- Core facility staff: A core facility manager belongs to their own team AND to each research group team that uses the facility, enabling visibility into how groups are using the equipment.
- QA/QC personnel in pharma: QA analysts belong to the QA team AND to each production or analytical team they review, giving them cross-team experiment visibility.
- PIs with multiple groups: A PI who manages two separate research groups belongs to both teams, seeing all experiments across both without needing two accounts.
Multi-team membership eliminates the need for shared accounts or account duplication. A QA manager who needs to review experiments in five production teams does not need five accounts — one account with five team memberships provides the required access. Every action by that manager is attributed to a single, named identity, which is the correct model for both security and audit trail integrity.
10.3 Role Management at the System Level
| Action | How to Perform It |
|---|---|
| Promoting to Team Admin | From Sysconfig → Users, edit the user and change their role in the target team to Admin. The promoted user can now manage team settings, view all team experiments, and perform admin actions in that team. |
| Promoting to SysAdmin | From Sysconfig → Users, edit the user and check the SysAdmin box. Maintain a short list of SysAdmins — typically 2–3 individuals in the IT/operations role. |
| Demoting an Admin | Remove Admin status from the Admin Panel (Team Admin) or Sysconfig (SysAdmin). The user immediately loses elevated access on their next page load. |
| Deactivating an account | Set the account's validity date to today or a past date, or set the account status to Inactive. The user cannot log in but their data is preserved. |
Never delete a user account without first exporting and transferring ownership of their data. A deleted account removes user attribution from some system records and may break links. The correct workflow for user departure is: (1) export their data, (2) transfer ownership to a successor, (3) deactivate the account. Delete only accounts created in error that have no associated experimental data.
10.4 Access Control Audit Practices
Access control is a frequent focus of regulatory audits. Maintain these practices to ensure access control evidence is available:
- Review all Admin and SysAdmin accounts quarterly. Verify each elevated account belongs to a current, active employee with a genuine administrative need.
- Log significant access changes in the Admin Log (see Section 8.3). The system records what changed; the Admin Log records why.
- When an auditor asks 'how do you control who has access?', the answer should be: every account is individually authenticated (SSO or local with MFA), role-based access is configured at team and system level, accounts are deactivated upon departure, and SysAdmin access is limited to 2–3 named IT staff.
- Generate and retain the monthly user CSV report as evidence that access was reviewed.
Authentication Configuration — SSO and LDAP
Authentication configuration determines how every user proves their identity to LabLynx One. LabLynx One supports two authentication models — local and federated — which can be used simultaneously.
11.1 Local Authentication
Local authentication is LabLynx One's default: each user has an email address and password stored within LabLynx One's own user database. Configure the password policy from Sysconfig → Security.
| Setting | Recommendation and Rationale |
|---|---|
| Minimum password length | Enforce a minimum of 12 characters. NIST SP 800-63B recommends length as the primary password strength factor. |
| Password complexity | Require a mix of uppercase, lowercase, numbers, and special characters — or simply enforce a long minimum length (14+ characters) without complexity rules. Both approaches are acceptable under modern security frameworks. |
| Password expiry | Optional. NIST 800-63B advises against mandatory periodic changes (which tend to produce weaker passwords). If your organization's policy requires periodic changes, set the interval here. |
| Failed login lockout | Set a limit of 5–10 consecutive failed attempts before temporary account lockout. Lockout duration: 15–30 minutes (not permanent, to avoid denial-of-service vulnerability). |
| Session timeout | Shorter is more secure (15–30 minutes) but inconvenient for researchers who leave a tab open. A common balance is 60 minutes to 4 hours depending on data sensitivity. |
11.2 SAML / SSO Integration
Single Sign-On (SSO) via SAML 2.0 connects LabLynx One to your organization's identity provider (IdP): Microsoft Entra ID, Okta, Google Workspace, OneLogin, Shibboleth, or any SAML 2.0–compliant IdP.
What SSO Provides
- Single credential — users log in with their organizational account, not a separate LabLynx One password.
- Automatic deprovisioning — when an account is disabled in the IdP (e.g., an employee is terminated), their LabLynx One SSO access is immediately revoked.
- Centralized MFA — if MFA is enforced at the IdP level, all LabLynx One logins automatically benefit from MFA without additional LabLynx One configuration.
- Audit alignment — login events in LabLynx One correspond to authentication events in the IdP audit log, enabling correlated security investigation.
Configuring SAML SSO — Step by Step
- In your Identity Provider, create a new SAML application for LabLynx One. The ACS URL and Entity ID are provided by LabLynx One in Sysconfig → Authentication.
- Configure the IdP to send these SAML attributes: email (required), first name (recommended), last name (recommended), and optionally group memberships for automated team assignment.
- Download or copy the IdP metadata XML from your IdP admin panel.
- In LabLynx One Sysconfig → Authentication, paste the IdP metadata XML (or provide the metadata URL for auto-import). Save.
- Test with a pilot user: navigate to the LabLynx One login page, click the SSO button, and authenticate. Verify the user account is created with the correct name and team assignment.
- After a successful pilot, communicate the SSO login URL to all team members. Optionally disable local password login to enforce SSO-only access.
- Entra ID: Enterprise Applications → New Application → Create your own → Non-gallery. Name: 'LabLynx One', set up SAML SSO.
- Entity ID = your LabLynx One instance URL. ACS URL = your LabLynx One instance URL + '/saml/acs'.
- Attributes: map user.mail → 'email', user.givenname → 'firstname', user.surname → 'lastname'.
- Download Federation Metadata XML from Entra ID.
- In LabLynx One Sysconfig → Authentication, paste the XML. Save.
- Test: open a private browser window, navigate to LabLynx One, click SSO. Authenticate with an Entra ID account. Verify the LabLynx One user profile is created correctly.
LabLynx One can coexist with both SSO and local authentication simultaneously. Some users may have local accounts (legacy accounts or service accounts for API use) while others authenticate via SSO. This hybrid configuration is common during SSO migration.
11.3 LDAP Integration
LDAP integration connects LabLynx One directly to a directory service (Active Directory, OpenLDAP, FreeIPA) for user authentication. Unlike SAML, LDAP authentication occurs directly without redirecting to an IdP. LDAP is appropriate for on-premises LabServer deployments without a cloud IdP.
| Configuration Field | Description and Example |
|---|---|
| LDAP Server URL | The address including protocol and port. Example: ldap://dc01.yourlab.internal:389 or ldaps://dc01.yourlab.internal:636 (secure LDAP — always use in production). |
| Bind DN | The distinguished name of a service account used by LabLynx One to search the directory. Example: cn=elabftw-service,ou=ServiceAccounts,dc=yourlab,dc=internal |
| Bind Password | The password of the bind service account. Stored encrypted in LabLynx One's configuration. |
| Base DN | The starting point in the directory tree for user searches. Example: ou=Researchers,dc=yourlab,dc=internal |
| User filter | LDAP filter to identify valid user accounts. Example: (objectClass=person) or (memberOf=cn=LabLynxOneUsers,...) |
| Attribute mapping | Map LDAP attributes to LabLynx One fields: mail → email, givenName → firstname, sn → lastname. |
Use LDAPS (LDAP over TLS, port 636) rather than plain LDAP (port 389) in all production environments. Plain LDAP transmits credentials in the clear, which is unacceptable in any regulated or security-conscious environment.
11.4 Multi-Factor Authentication — System-Level Enforcement
MFA can be enabled at two levels:
- Team level: The Admin can require MFA for all members of a specific team (Admin Panel → Team tab → Force MFA checkbox).
- Instance level: The SysAdmin can require MFA for all users across all teams from Sysconfig → Security. This is the highest-level enforcement and cannot be overridden by Team Admins.
Enabling instance-level MFA enforcement will immediately lock out any user who does not have an MFA device enrolled. Before enabling, communicate the requirement to all users and provide a 2-week window for enrollment. Verify that all Admin and SysAdmin accounts have MFA enrolled BEFORE enabling instance enforcement, or you risk locking yourself out.
- Academic: MFA optional at the team level. PIs may require it for team members handling sensitive IP or compliance-critical experiments.
- Pharma regulated (21 CFR Part 11): MFA required at the instance level. All accounts must enroll before any electronic signatures are in use. This is a regulatory expectation.
- Forensic / ISO 17025: MFA required at the instance level. Accreditation standards expect strong authentication controls for all analytical record systems.
- Startup pre-clinical: Enable MFA early, before regulatory engagement. Retroactively enabling MFA when clinical trials begin is a significant disruption to users who have become habituated to logging in without it.
Team Configuration at the System Level
While Team Admins configure their teams from within, the SysAdmin can create teams, modify any team's settings, and see all teams in the instance. The team architecture decision — how to structure teams — is often the most consequential LabLynx One decision an organization makes.
12.1 Creating Teams
Navigate to Sysconfig → Teams → Create Team. Provide:
- Team name: the display name users will see in the team switcher.
- Team description: optional but useful in multi-team instances.
- Initial Admin: specify the user who will be the first Admin for this team.
12.2 Team Architecture Decisions
A poor team structure is difficult to reverse — moving experiments between teams requires Admin intervention and data migration planning. Take time to design the team structure before inviting users.
| Model | Structure | Best For |
|---|---|---|
| One team per organization | All users in one team. Simple to manage. All experiments visible to all users (depending on permission defaults). | Small to medium labs (<20 users) with homogeneous work and no IP separation requirements. |
| One team per research group | Each PI's group is a team. Groups work independently with their own templates and categories. | Academic institutions with multiple independent research groups. Each PI is Admin of their own team. |
| One team per department | Each functional department (QA, R&D, Analytical, Manufacturing) is a team. Department leads are Admins. | Pharma, biotech, or industrial labs where departments have different workflows and compliance requirements. |
| One team per project | Projects are the team unit. Team membership changes as people join/leave projects. | CROs with multiple simultaneous clients, or project-matrix organizations. Client data separation is critical. |
| Hybrid: functional + project | Base teams by department, overlay project teams for cross-departmental collaboration. | Large organizations with both stable functional units and dynamic cross-functional projects. |
- Team 1: Analytical Development (8 analysts, 2 scientists, 1 QA) — HPLC, dissolution, content uniformity, method validation categories
- Team 2: Formulation R&D (12 formulation scientists) — synthesis, screening, excipient evaluation categories
- Team 3: Quality Assurance (4 QA staff) — CAPA, NCR, audit, change control categories; read access to all other teams
- Team 4: Clinical Supply (6 manufacturing staff) — batch record, in-process control, environmental monitoring categories
- Team 5: Regulatory Affairs (3 RA staff) — submission documents, risk assessment, regulatory response categories
12.3 Deleting and Archiving Teams
Teams that are no longer active should not be deleted. Instead:
- Deactivate the team: SysAdmin sets the team to inactive, preventing new experiments from being created while preserving all data.
- Archive the team's data: Run a bulk export of all experiments and resources before deactivating. Store the archive per your organization's data retention policy.
- Transfer ongoing work: Any experiments still relevant to active work should be transferred to a successor team before deactivation.
Deleting a team is an irreversible action that permanently removes all experiments, resources, and user data associated with the team. This operation should never be performed on a team that has contained live research data. The only appropriate use of team deletion is removing teams created in error that have no data.
Email, Notifications, and Timestamping Configuration
Email is the nervous system of LabLynx One notifications. Without correctly configured SMTP, password resets, invitations, comment notifications, and Request Action workflows all degrade or fail silently.
13.1 Email (SMTP) Configuration
| Setting | Details |
|---|---|
| SMTP Server | The hostname or IP of your SMTP relay. Examples: smtp.office365.com (Microsoft 365), smtp.gmail.com (Google Workspace), smtp2go.com (third-party relay). |
| SMTP Port | 25 (unsecured, legacy), 587 (STARTTLS, preferred), 465 (SSL/TLS, also acceptable). |
| From address | Use a real monitored address (e.g., lablynxone@yourlab.com) not a no-reply address, so users can reply with questions. |
| Authentication | For Microsoft 365, use an app password or OAuth2. For Google Workspace, use an app password with 2FA enabled on the account. |
| TLS/SSL | Always enable TLS. Sending email without encryption is inappropriate for any environment that handles research data. |
Use a dedicated transactional email service (SMTP2Go, SendGrid, AWS SES, Postmark) rather than a personal or shared mailbox SMTP for production deployments. Transactional services provide delivery reporting, bounce handling, and are not rate-limited like individual user accounts.
After configuring SMTP, use the 'Send test email' button in Sysconfig → Email to verify delivery before inviting users. Common failures: incorrect port, missing TLS, authentication error, or the sending IP being blocked by a spam filter.
13.2 Notification Settings
From Sysconfig → Notifications (or individual user Settings), configure:
- Email notification frequency: immediate (each event sends an email), daily digest (one email per day summarizing all events), or disabled (in-app only).
- System announcements: Compose and send a system-wide message from Sysconfig. Appears as a notification to all users — useful for announcing maintenance windows, major feature releases, or urgent policy changes.
Recommend that all users configure email digest notifications rather than immediate per-event email. Researchers who receive 50 LabLynx One notification emails per day quickly start ignoring them, missing important Request Action events. A daily digest collects all notifications into one readable summary email.
13.3 Timestamping Service Configuration
RFC 3161 timestamping requires a Timestamp Authority (TSA) endpoint. LabLynx One comes pre-configured with DFN.de (a free academic TSA). For regulated industry deployments, a commercial TSA with a service level agreement is recommended.
| TSA | Details | Best For |
|---|---|---|
| DFN.de | Free, academic community TSA. No registration required. | Academic labs, research universities, non-profit institutions |
| DigiCert | Commercial TSA with SLA. Free timestamping tier available. Widely accepted in regulatory and legal contexts. | Pharma, biotech, CRO, any regulated industry |
| Sectigo | Commercial TSA. Free service available. Well-established for legal and regulatory timestamping. | Legal, regulatory, compliance-heavy environments |
| GlobalSign | Commercial TSA with AATL (Adobe Approved Trust List) status. | Documents, compliance, EU regulatory environments |
| Universign | eIDAS-qualified TSA. Required for electronic evidence admissible in EU courts. | European regulatory submissions, EU pharmaceutical submissions |
| Custom TSA | Any RFC 3161–compliant endpoint. Provide the URL and optional authentication credentials. | Organizations with contractual TSA arrangements or private TSA infrastructure |
To configure: Sysconfig → Timestamping. Enter the TSA URL (and credentials if required). Save. All future timestamp requests from any team will use this TSA.
Changing the TSA does not affect existing timestamps. Timestamps already issued by the previous TSA remain valid and verifiable using their original TSA's certificate. You can safely switch TSAs when a service changes or you upgrade from a free to a commercial TSA.
Security, Audit Logs, and Compliance
The SysAdmin's role in maintaining the security posture of the LabLynx One instance and in providing audit evidence to internal and external reviewers.
14.1 Security Settings
| Setting | Recommendation |
|---|---|
| Max login attempts before lockout | Set to 5–10. Too few (≤3) causes frequent legitimate lockouts from typos. Too many (15+) provides inadequate brute-force protection. |
| Lockout duration | 15–30 minutes is standard. Do not use permanent lockout (it requires Admin intervention and becomes a denial-of-service vector). |
| Session timeout (idle) | 1–4 hours is a common balance between security and convenience for laboratory work. |
| Enforce HTTPS only | Always enabled in production deployments. HTTP transmits credentials and data in the clear. |
| Content Security Policy (CSP) | The default CSP is appropriate for most deployments. Modify only if specific third-party integrations require exceptions. |
14.2 System Audit Logs
The system audit log in Sysconfig → Audit Logs records instance-level events:
- Authentication events: every successful login, failed login attempt, SSO authentication, and MFA verification.
- Account management events: account creation, deletion, deactivation, role changes, team assignment changes.
- SysAdmin configuration changes: any change made in the Sysconfig Panel, timestamped and attributed to the SysAdmin who made it.
- Password reset events: when a password reset is initiated and completed.
- Session events: session creation and expiry.
A QA manager reports that an experiment record was modified at 11:45 PM on a date when the responsible analyst claims they were not working. SysAdmin opens Sysconfig → Audit Logs and filters by user and date. The log shows: no successful login by that user on the date in question. The experiment's Changelog shows: the modification was made by a different user who had been granted editor access to that experiment. The SysAdmin's log search establishes that no unauthorized access occurred. The question is resolved with evidence rather than assumption.
14.3 Backup and Recovery
sciCloud.net® Deployments (LabLynx-Managed)
- Hourly database backups retained for 7 days.
- Daily complete backups retained for 30 days.
- Monthly backups retained for 12 months.
- Backups stored in a geographically distant second data center on AWS infrastructure.
- RPO: 1 hour. RTO: 4 hours.
- SysAdmins do not need to configure or manage backups. Contact LabLynx support for point-in-time restores.
LabServer (On-Premises) Deployments
- Database: Automated daily backup using mysqldump or equivalent. Retain 30+ days.
- Uploaded files: Backup the LabLynx One uploads directory. Sync daily to an off-server location.
- Off-site copy: At least one backup copy must be stored at a geographically separate location. Backups stored only on the same physical server provide no disaster recovery capability.
- Recovery testing: Test the full restore procedure at least annually. A backup that has never been tested is an untested assumption, not a guarantee.
14.4 Preparing for External Audits
| Audit Evidence Item | How to Prepare It |
|---|---|
| User access list | Export the current user list from Sysconfig → Users. Show auditors who has access, at what role, with what team membership. Verify all accounts are current employees with legitimate access. |
| Access control policy | Document the organization's process for granting and revoking LabLynx One access. This should match the actual settings: self-registration policy, validation requirements, MFA enforcement. |
| Template inventory | Export the list of all team templates with version numbers and last modification dates. Demonstrate that templates correspond to SOPs and are version-controlled. |
| Audit trail evidence | For any experiment the auditor selects, demonstrate the Changelog (field-level history), the Revisions (body text history), the signature records, and any timestamps. Have a test experiment ready if the auditor wants a live demonstration. |
| System configuration documentation | Prepare a one-page summary of the LabLynx One instance configuration: deployment model, authentication method, MFA status, backup frequency, TSA used, and hosting certifications (SOC 2 for sciCloud.net®). |
| Incident and change log | If your organization maintains an Admin Log (Section 8.3), produce the relevant entries. Show that configuration changes are documented and authorized. |
Brief your LabLynx One Team Admins before the audit on what auditors typically ask to see: how is access controlled, how are records protected from modification, how are signatures authenticated, and how is backup and recovery managed. Admins who can answer these questions fluently demonstrate system maturity to auditors.
Quick Reference — Admin vs. SysAdmin Capabilities
A complete capability matrix showing what Team Admins and SysAdmins can and cannot do.
| Capability | Team Admin | SysAdmin |
|---|---|---|
| Create / manage teams | No | Yes |
| Create user accounts | Limited (if enabled by SysAdmin) | Yes |
| Configure SSO / LDAP | No | Yes |
| Set password policy | No | Yes |
| Enforce instance-wide MFA | No | Yes |
| Configure SMTP email | No | Yes |
| Configure TSA for timestamping | No | Yes |
| View system audit log | No | Yes |
| Manage all teams' users | No | Yes |
| Create / manage experiment categories | Yes (own team) | Yes (all teams) |
| Create / manage status values | Yes (own team) | Yes (all teams) |
| Create / manage team templates | Yes (own team) | Yes (all teams) |
| Manage tags (Tag Manager) | Yes (own team) | Yes (all teams) |
| Create / manage user groups | Yes (own team) | Yes (all teams) |
| Validate new user accounts | Yes (own team) | Yes (all teams) |
| Promote users to Admin | Yes (within own team) | Yes (any team, any role) |
| View all team experiments | Yes (own team) | Yes (all teams via SysAdmin) |
| Run batch actions | Yes (own team) | Yes (all teams) |
| Export team data | Yes (own team) | Yes (all teams) |
| Deactivate user accounts | No | Yes |
| Send system announcements | No | Yes |
Compliance Configuration Checklist by Regulatory Framework
| Framework | Key LabLynx One Configuration Requirements | Applicable Lab Types |
|---|---|---|
| 21 CFR Part 11 | MFA enforced (instance or team), cryptographic signatures for critical records, RFC 3161 timestamps on all approved records, session timeout ≤30 min for regulated systems, all user accounts individual (no shared logins), audit trail export available on demand. | Pharma, biotech, medical device, CRO |
| ISO/IEC 17025 | MFA recommended, controlled tag vocabulary (disable user tag creation), all steps locked in accredited method templates, equipment records with calibration status, user access list maintained and reviewed quarterly, template versioning matches SOP version control. | Testing and calibration laboratories |
| ALCOA+ (general GxP) | All actions attributed to named individual accounts, SSO enforces identity, timestamps system-generated (not user-entered), raw data files attached at moment of creation, required metadata fields defined in templates, records locked after approval. | Any regulated lab: pharma, food, environmental, medical device |
| Forensic accreditation (ASCLD, ISO 17020) | MFA enforced, controlled permissions (users cannot set permissions), no shared accounts, experiment deletion restricted to Admins, complete audit trail for all case records, individual user access reviewed annually. | Forensic laboratories, crime labs, medical examiner offices |
| HIPAA | PHI not stored in experiment titles or body text (use coded identifiers), role-based access restricting PHI to authorized users only, audit log maintained and reviewable, session timeout 15–30 minutes, encryption in transit and at rest (sciCloud.net® provides this). | Clinical laboratories, clinical research, healthcare-adjacent labs |
| GDPR / data protection | Data residency consideration (sciCloud.net® is US-based AWS; EU-specific hosting available on request), user data export capability for subject access requests, account deletion process documented, data retention policy applied. | Organizations serving EU data subjects, European labs |
Troubleshooting Common Admin Issues
| Issue | Likely Cause and Resolution | Who Resolves |
|---|---|---|
| User cannot log in | (1) Account not validated — check Users tab for pending status. (2) Account expired — check validity date. (3) Password locked — reset from Admin Panel. (4) SSO issue — verify IdP configuration with SysAdmin. | Team Admin + SysAdmin |
| User not receiving email notifications | (1) SMTP not configured or broken — SysAdmin tests SMTP. (2) User has email notifications disabled in their Settings. (3) Email going to spam — check SPF/DKIM configuration on sending domain. | SysAdmin |
| Template not visible to users | Template not set to 'team' visibility. As Admin, open the template, enable 'Make available to team', and save. | Team Admin |
| Tags growing out of control | No admin-controlled vocabulary. Consider disabling user tag creation in Team settings, then normalize the existing tags using the Tag Manager. | Team Admin |
| Experiment category missing from new entries | Category may have been deleted. Check the Team tab → Experiment Categories section. Re-create if deleted. | Team Admin |
| User cannot see team experiments | Scope is set to 'Self'. Ask user to change scope to 'Team' or 'Everything'. If problem persists, verify team membership in Users tab. | Team Admin |
| SSO login fails for one user | The user's IdP account attribute (usually email) does not match any LabLynx One user record. Verify the email attribute in the IdP matches the user's LabLynx One account email exactly. | SysAdmin |
| Timestamp fails | (1) TSA endpoint unreachable — check network connectivity. (2) TSA URL changed — update in Sysconfig. (3) TSA rate limit exceeded — use a different TSA or contact LabLynx. | SysAdmin |
| Batch action affected wrong entries | Filter was too broad. Use the Batch Actions preview step carefully before executing. Contact LabLynx support if unintended changes must be rolled back. | Team Admin + SysAdmin |
LabLynx One Developer Manual
For developers integrating with the LabLynx One REST API.
About This Manual
This manual is the complete technical reference for developers building integrations with, custom applications on top of, or BI/analytics pipelines from LabLynx One.
This manual covers:
- The LabLynx One REST API v2 — every major endpoint group with explicit call signatures, request/response examples, and authentication patterns.
- The metadata (custom fields) JSON schema — how structured data is represented in the API and how to read and write it programmatically.
- Integration patterns — instrument data push, LIMS synchronization, ERP connectivity, and event-triggered automation.
- BI and analytics — extracting data for Power BI, Tableau, pandas/R analysis, and custom dashboards.
- Complete, runnable code examples in Python, JavaScript (Node.js/fetch), and cURL for every major operation.
LabLynx One is built on eLabFTW, an open-source ELN platform. The REST API documented here is the eLabFTW v2 API as deployed and hosted by LabLynx. The API reference (OpenAPI/Swagger specification) is available at: https://doc.elabftw.net/api/v2/
All code examples in this manual are production-ready with appropriate error handling. Variables shown in angle brackets (e.g., <YOUR_API_KEY>, <INSTANCE_URL>) must be replaced with your actual values.
Authentication and API Basics
Every API call must be authenticated with a personal API key. This chapter covers key generation, request structure, HTTP verb mapping, response codes, and pagination — the foundations for every integration.
1.1 Generating an API Key
To generate an API key: Log in to LabLynx One → User avatar (top right) → Settings → API Keys tab → Click Create Key. Enter a descriptive name, select Read-Only or Read-Write access, and copy the generated key. It is shown only once — store it in a secrets manager or environment variable, never in source code.
API keys take the form 3-cb2314b00d2845a3f7c2891a52d8b47e... — the leading number is the user ID. Always treat an API key as a password: rotate it periodically, use a separate key per integration, and revoke immediately if compromised.
1.2 Request Structure
The base URL for all API requests is: https://<INSTANCE_URL>/api/v2/<endpoint>
All requests require two headers:
| HTTP Verb | Operation | Notes |
|---|---|---|
| GET | Read data | Returns a JSON object or array. Safe and idempotent. |
| POST | Create a new resource | Returns HTTP 201 with a Location header pointing to the new resource URL. |
| PATCH | Update an existing resource | Partial updates — only fields included in the request body are modified. Returns HTTP 200. |
| DELETE | Delete a resource | Soft-delete in most cases. Returns HTTP 204 No Content on success. |
1.3 Authentication in Code — Three Languages
1.4 Response Format and Status Codes
| Status Code | Meaning |
|---|---|
| 200 OK | Successful GET or PATCH. Response body contains the resource. |
| 201 Created | Successful POST. Location header contains the new resource URL. |
| 204 No Content | Successful DELETE. Empty response body. |
| 400 Bad Request | Malformed JSON or invalid field values. Response body contains error message. |
| 401 Unauthorized | API key missing, invalid, or expired. |
| 403 Forbidden | Key is valid but lacks permission (e.g., read-only key attempting a write). |
| 404 Not Found | Resource ID does not exist or is not accessible. |
| 429 Too Many Requests | Rate limit exceeded. Back off and retry after the Retry-After header period. |
| 500 Internal Server Error | Server-side error. Retry after a brief delay; contact LabLynx support if persistent. |
1.5 Pagination
Endpoints returning lists support pagination through query parameters. Without pagination the API returns 15–25 results by default.
| Parameter | Description |
|---|---|
limit | Maximum results per page. Default varies; maximum is typically 500. |
offset | Records to skip before collecting. Use with limit for cursor-based pagination. |
q | Full-text search query. Searches title, body text, tags, and custom fields. |
cat | Filter by category ID (integer). |
status | Filter by status ID (integer). |
owner | Filter by user ID — returns only entries owned by this user. |
extended | Set to 1 to include full body text and metadata in list responses (omitted by default for performance). |
Experiments — Complete API Reference
Experiments are the core record type in LabLynx One. An experiment includes: id, title, date, body (HTML), status, category, tags, metadata (custom fields), links, and attachments. All experiment operations are under the /experiments path.
2.1 Endpoint Overview
| Method | Endpoint | Description |
|---|---|---|
| GET | /experiments | List experiments (paginated, filterable) |
| POST | /experiments | Create a new empty experiment |
| GET | /experiments/{id} | Get full details of one experiment |
| PATCH | /experiments/{id} | Update experiment fields (partial update) |
| DELETE | /experiments/{id} | Soft-delete an experiment |
| GET | /experiments/{id}/revisions | Body text version history |
| GET | /experiments/{id}/changelog | Field-level change history |
| POST | /experiments/{id}/tags | Add a tag |
| GET | /experiments/{id}/uploads | List file attachments |
| POST | /experiments/{id}/uploads | Upload a file attachment (multipart) |
| POST | /experiments/{id}/links/items | Link to a resource |
| POST | /experiments/{id}/steps | Add a protocol step |
| PATCH | /experiments/{id}/steps/{stepId} | Update / complete a step |
| POST | /experiments/{id}/comments | Add a comment |
| POST | /experiments/{id}/timestamps | Apply RFC 3161 timestamp |
2.2 Creating an Experiment
Creating an experiment is a two-step process: POST to create an empty entry (which returns its ID), then PATCH to populate the content. This is intentional — the ID must be known before content is attached.
2.3 Reading and Filtering Experiments
2.4 Updating Experiments (PATCH)
PATCH requests apply partial updates — only fields included in the request body are changed. All other fields remain as-is, making PATCH safe for targeted updates.
2.5 Managing Tags
2.6 Uploading Files (Attachments)
File uploads use multipart/form-data, not JSON. This is the only endpoint type that does not use JSON content type. When using the Python requests library, do NOT manually set Content-Type when passing files= — requests sets the correct multipart boundary automatically.
2.7 Working with Steps
2.8 Linking Experiments to Resources
2.9 Adding Comments
2.10 Applying a Trusted Timestamp
Resources (Items) — Complete API Reference
Resources (called items in the API) represent the laboratory inventory: reagents, instruments, cell lines, equipment, and any other entity tracked in the resource catalog. The resource API mirrors the experiment API structure exactly.
3.1 Resource Endpoint Overview
| Method | Endpoint | Description |
|---|---|---|
| GET | /items | List resources (paginated, filterable) |
| POST | /items | Create a new empty resource |
| GET | /items/{id} | Get full resource detail |
| PATCH | /items/{id} | Update resource fields |
| DELETE | /items/{id} | Delete a resource |
| GET | /items_types | List all resource category types |
| POST | /items/{id}/uploads | Upload a file to a resource |
| POST | /items/{id}/tags | Add a tag |
| POST | /items/{id}/links/items | Link to another resource |
| POST | /items/{id}/links/experiments | Link to an experiment |
| POST | /items/{id}/steps | Add a step (checklist item) |
3.2 Creating and Populating a Resource
3.3 Bulk Resource Import from CSV
3.4 Listing Resource Categories
Users, Teams, Tags, and Scheduler
Supporting endpoints for user management (SysAdmin), team configuration, tag operations, status lookups, and equipment booking.
4.1 User Endpoints
| Method | Endpoint | Description |
|---|---|---|
| GET | /users | List all users (SysAdmin only) |
| GET | /users/{id} | Get a specific user's profile. Use me for the authenticated user. |
| POST | /users | Create a new user (SysAdmin only) |
| PATCH | /users/{id} | Update user fields (SysAdmin or self for limited fields) |
4.2 Team Endpoints
4.3 Tags and Status Endpoints
4.4 Scheduler / Booking Endpoints
The Metadata (Custom Fields) JSON Schema
Custom metadata fields are stored as a JSON string in the metadata field of every experiment and resource. Understanding this schema is critical for reading structured data from the API and writing it back correctly.
5.1 Schema Overview
The metadata value returned by the API is a JSON-encoded string. You must parse it before reading field values and re-serialize it before writing.
5.2 All Field Types — Complete Schema Reference
| type | Key Properties | Notes |
|---|---|---|
text | "value": "string" | Short free text. Default type if omitted. |
number | "value": "42.5", "units": ["mg","g"], "unit": "mg" | Numeric input. Value is always stored as a string. |
date | "value": "2026-06-01" | ISO 8601 date (YYYY-MM-DD). Must be in this format. |
datetime-local | "value": "2026-06-01T14:30" | Date and time. Format: YYYY-MM-DDTHH:MM. |
select | "value": "Option A", "options": ["Option A","Option B"] | Dropdown. Value must be one of options. |
radio | "value": "Yes", "options": ["Yes","No"] | Radio group. Same structure as select but all options visible. |
checkbox | "value": "on" or "" | Checked = "on", unchecked = empty string. |
url | "value": "https://example.com" | URL input. Rendered as hyperlink in view mode. |
email | "value": "user@lab.com" | Email address input. |
5.3 Reading Metadata Fields in Python
5.4 Writing Metadata Fields — The Read-Modify-Write Pattern
Always use the read-modify-write pattern when updating metadata. Fetching before writing prevents accidentally erasing fields you did not intend to modify.
Integration Patterns
The most common integration architectures for LabLynx One — from instrument automation to LIMS synchronization to batch processing — each with a complete, runnable example.
🔬 Instrument Data Push
Post-run scripts or file watchers that auto-create experiments when instruments finish. Zero manual transcription.
🔄 LIMS Synchronization
Bidirectional sync between LabLynx One and a LIMS — samples flow in, results flow out.
📊 Results Write-Back
Extract approved experiment results and POST them back to a LIMS or ERP to close sample workflows.
⚡ Batch Processing
Rate-limited bulk updates across many experiments — status changes, tag application, archiving.
6.1 Instrument Data Push — HPLC File Watcher
6.2 LIMS Synchronization
6.3 Writing Back Results to LIMS
6.4 Batch Processing
BI, Analytics, and Reporting
LabLynx One's API makes it straightforward to extract structured data for business intelligence dashboards, automated reporting, and statistical analysis. This chapter covers pandas, Power BI, Tableau, and a complete Python QA report generator.
7.1 Extracting Data to pandas DataFrames
7.2 Power BI Integration — Power Query M Script
Power BI can connect directly to the LabLynx One API using the Power Query Web connector with custom authentication headers.
In Power BI Service (cloud), you need a Data Gateway to connect to on-premises LabLynx One instances. For sciCloud.net® deployments, the API is directly accessible from Power BI Service without a gateway.
7.3 Automated QA Dashboard Report (PDF)
7.4 Tableau Web Data Connector
The elabapi-python Library
The official Python client library provides a generated, typed interface to all API endpoints. It is the recommended approach for complex Python integrations because it handles authentication, request construction, and response parsing automatically.
8.1 Installation and Setup
8.2 Common Operations Using the Library
8.3 Error Handling with the Library
Webhooks and Event-Driven Integration
LabLynx One does not provide built-in webhook delivery. Event-driven integration is achieved through polling the API for recent changes, or through LabVia (Node-RED) which supports event-triggered workflows.
9.1 Polling for Recent Changes
9.2 LabVia Integration — Node-RED Based Automation
LabVia is LabLynx's integration and automation platform built on Node-RED. It provides a visual flow-based programming interface and pre-built LabLynx One nodes. LabVia is the recommended approach for production integrations requiring:
- Event-driven instrument data capture (triggered by file creation, serial port events, MQTT, etc.)
- Visual workflow design without Python/JS coding
- Pre-built connectors for laboratory instruments (HPLC, balances, plate readers, etc.)
- Data transformation nodes (parsing instrument output formats into LabLynx One metadata)
For LabVia integration development, contact LabLynx at support@lablynx.com to request the LabVia node documentation and example flows specific to your instrument types. LabLynx also provides professional services for custom integration development.
JavaScript SDK and Browser Applications
A reusable LabLynx One JavaScript client module for Node.js backend services, browser-based dashboards, and React/Vue/Angular frontends.
10.1 LabLynx One JavaScript Client Module
10.2 Complete Node.js Integration Example — Plate Reader
Complete API Endpoint Reference
Consolidated reference of all major API endpoints. For the full OpenAPI specification with request/response schemas, see: https://doc.elabftw.net/api/v2/
11.1 Experiments
| Method | Endpoint | Description and Body/Params |
|---|---|---|
| GET | /experiments | List. Query: limit, offset, q, cat, status, owner, extended |
| POST | /experiments | Create empty. Returns 201 + Location header. |
| GET | /experiments/{id} | Full detail including metadata, tags, uploads, links, steps. |
| PATCH | /experiments/{id} | Partial update. Only sent fields change. |
| DELETE | /experiments/{id} | Soft-delete. Returns 204. |
| GET | /experiments/{id}/revisions | Body text version history. Returns [{id, created_at, body}]. |
| GET | /experiments/{id}/changelog | Field change history. Returns [{field, previous, next, userid, created_at}]. |
| POST | /experiments/{id}/tags | Body: {"tag": "TagName"}. Returns 201. |
| DELETE | /experiments/{id}/tags/{tagId} | Remove tag. Returns 204. |
| GET | /experiments/{id}/uploads | List attachments. |
| POST | /experiments/{id}/uploads | Upload file. multipart/form-data: file (required), comment (optional). |
| DELETE | /experiments/{id}/uploads/{uploadId} | Delete attachment. |
| GET | /experiments/{id}/links | Returns {experiments_links:[], items_links:[]} |
| POST | /experiments/{id}/links/items | Body: {"link": itemId} |
| POST | /experiments/{id}/links/experiments | Body: {"link": expId} |
| POST | /experiments/{id}/steps | Body: {"body": "Step text", "ordering": 1} |
| PATCH | /experiments/{id}/steps/{stepId} | Body: {"body", "ordering", "finished": true/false} |
| POST | /experiments/{id}/comments | Body: {"comment": "text"} |
| POST | /experiments/{id}/timestamps | Apply RFC 3161 timestamp. No request body needed. |
11.2 Resources (Items)
| Method | Endpoint | Description |
|---|---|---|
| GET | /items | List items. Same query params as /experiments. |
| POST | /items | Create empty item. |
| GET | /items/{id} | Full item detail. |
| PATCH | /items/{id} | Update item. |
| DELETE | /items/{id} | Delete item. |
| GET | /items_types | List all resource category types. |
| POST | /items/{id}/uploads | Upload file (multipart). |
| POST | /items/{id}/tags | Add tag. |
| GET | /items/{id}/links | Get all links. |
| POST | /items/{id}/links/items | Link to another resource. |
| POST | /items/{id}/links/experiments | Link to an experiment. |
| POST | /items/{id}/steps | Add step. |
| PATCH | /items/{id}/steps/{stepId} | Update/complete step. |
11.3 Users, Teams, and System
| Method | Endpoint | Description |
|---|---|---|
| GET | /users | List all users (SysAdmin). |
| GET | /users/{id} | Get user profile. Use me for authenticated user. |
| POST | /users | Create user (SysAdmin). Body: {firstname, lastname, email, team, usergroup}. |
| PATCH | /users/{id} | Update user (SysAdmin or self for limited fields). |
| GET | /teams | List teams. |
| GET | /teams/{id} | Get team details. |
| PATCH | /teams/{id} | Update team (Admin/SysAdmin). |
| GET | /status | List experiment status values for current team. |
| GET | /tags | List all tags in current team. |
| PATCH | /tags/{id} | Rename a tag (Admin). |
| DELETE | /tags/{id} | Delete a tag (Admin). |
| GET | /events | List bookings. Params: start, end, item (resource ID). |
| POST | /events | Create booking. Body: {item, start, end, title}. |
| PATCH | /events/{id} | Update booking. |
| DELETE | /events/{id} | Cancel booking. |
| GET | /info | Get instance info (version, etc.). No auth required. |
Security, Rate Limits, and Best Practices
Production integration patterns for API key security, rate limit handling, safe concurrent writes, and integration testing.
12.1 API Key Security
| Practice | Details |
|---|---|
| Never hardcode keys | Always load from environment variables, secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), or secure config files outside the codebase. |
| One key per integration | Create a separate key for each script or service. If one key is compromised, revoke only that key without disrupting other integrations. |
| Read-only keys when possible | If an integration only reads data (reporting, BI), generate a read-only key. A compromised read-only key cannot modify or delete data. |
| Rotate keys periodically | Revoke and regenerate keys at least annually, or immediately after any suspected exposure (developer departure, key committed to version control). |
| Monitor access patterns | Review API access in the LabLynx One audit log. Unusual patterns (off-hours, unexpected IPs, large extractions) may indicate a compromised key. |
12.2 Rate Limiting
LabLynx One enforces rate limits to protect system stability. Key practices:
- Add
time.sleep(0.1–0.2)between requests in batch loops. - Use large page sizes (
limit=200–500) to reduce total request count. - Cache responses when data is not time-critical.
- Handle
429responses with exponential backoff.
12.3 Handling the Read-Modify-Write Pattern Safely
When updating metadata or other fields, always fetch the current state first to avoid race conditions. Two integrations simultaneously writing to the same experiment can produce lost updates. For high-frequency concurrent writes, serialize updates through a queue rather than parallel writes.
12.4 Testing Your Integration
- Test against a staging or development instance with synthetic data. LabLynx can provision a test instance for development use.
- Write integration tests that create, verify, and clean up test experiments. A test that leaves 500 test records in production is not a test — it is a mess.
- Use descriptive titles for test records:
'INTEGRATION_TEST — Auto-Delete — {timestamp}'. - Test all error paths: what happens when an experiment doesn't exist? When the key is invalid?
Environment Setup Reference
Python Environment
Node.js Environment
Required API Key Permissions by Use Case
| Use Case | Required Key Type |
|---|---|
| Read experiments and resources (BI/analytics) | Read-only API key |
| Create experiments from instruments | Read-write API key for the integration user's account |
| Create and manage resources (inventory sync) | Read-write API key |
| Manage users and teams (admin automation) | Read-write API key on a SysAdmin account |
| All operations (full integration) | Read-write API key on an account with appropriate team membership |
Metadata JSON Schema Quick Reference
LabLynx One IT Admin Manual
Licensing, architecture, and installation reference.
LabLynx One Commercial License (LabLynx, Inc.)
LabLynx One is delivered by LabLynx under a commercial subscription license. This chapter describes the terms of that license and its relationship to the open-source platform on which LabLynx One is built.
1.1 License Summary
LabLynx One is a commercial software product delivered by LabLynx, Inc. under a subscription license agreement. The commercial license governs the use of LabLynx branding, customization, documentation, managed hosting infrastructure (sciCloud.net®), and proprietary integrations and connectors.
| Licensor | LabLynx, Inc., Pensacola, Florida, USA |
| License Type | Commercial Subscription License |
| Grant | Non-exclusive, non-transferable right to use LabLynx One as delivered by LabLynx for the subscriber's internal laboratory operations during the subscription term. |
| Users | Unlimited users per instance. No per-seat licensing. |
| Restrictions | Licensee may not redistribute, sublicense, sell, or host LabLynx One as a service for third parties. Reverse engineering of LabLynx proprietary components is prohibited. |
| Support | Included per subscription tier. See www.lablynx.com for current tier details. |
| Contact | sales@lablynx.com | support@lablynx.com |
1.2 Open-Source Foundation
LabLynx One is built on eLabFTW, an open-source Electronic Laboratory Notebook developed by Deltablot SAS. LabLynx applies branding, configuration, enterprise features, and managed hosting to the eLabFTW platform. The underlying eLabFTW codebase is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).
- Project: eLabFTW
- Developer: Deltablot SAS
- License: GNU Affero General Public License v3.0 (AGPL-3.0)
- Source Code:
https://github.com/elabftw/elabftw - AGPL-3.0 Summary: Permissions: commercial use, distribution, modification, patent use, private use. Conditions: disclose source, same license, state changes, network use is distribution. Limitations: no liability, no warranty.
- Full License Text:
https://www.gnu.org/licenses/agpl-3.0.html
1.3 License Compatibility Statement
LabLynx's commercial subscription does not alter the open-source licensing terms of eLabFTW or any of its open-source dependencies. Customers who deploy LabLynx One using the LabServer (on-premises) model receive the complete source code of eLabFTW as part of the container images, in accordance with AGPL-3.0 requirements.
Customers who deploy on-premises and modify eLabFTW source code must make those modifications available under AGPL-3.0 if those modifications are used to provide network services. LabLynx proprietary components (branding, configuration files, integration scripts) that do not constitute derived works of eLabFTW are not subject to AGPL-3.0.
The complete text of all open-source licenses is available in the /licenses directory of the eLabFTW source repository and in the /usr/share/doc directory of the deployed Docker container.
Open-Source Component Licenses
The LabLynx One software stack incorporates numerous open-source components. This chapter documents every component with its version, applicable license, and source — covering the Docker image, PHP runtime, Composer packages, JavaScript libraries, database, and host OS.
2.1 License Type Summary
| License | Type | Description |
|---|---|---|
| AGPL-3.0 | Strong copyleft | Source must be made available when software is run over a network. Applies to eLabFTW core and Ghostscript. |
| GPL-2.0 / GPL-3.0 | Strong copyleft | Used by Linux kernel, MySQL, GnuPG, and several host OS components. |
| LGPL-2.1 / LGPL-3.0 | Weak copyleft | Permits linking from non-GPL software. Used by systemd and several libraries. |
| MIT | Permissive | Very widely used. Full use, copy, modify, redistribute permitted with attribution. |
| BSD 2-Clause / 3-Clause | Permissive | Similar to MIT with attribution requirements. Used by nginx, Docker, and several libraries. |
| Apache 2.0 | Permissive + patent | Permissive with explicit patent grant. Used by Docker Engine, OpenSSL 3.x. |
| PHP License v3.01 | Permissive | PHP-specific permissive license used for PHP core and most bundled extensions. |
| ISC | Permissive | Functionally equivalent to MIT. Used by s6-overlay and several Node.js packages. |
| MPL-2.0 | Weak copyleft | File-level weak copyleft. Used by some cryptographic components and ca-certificates. |
2.2 Core Application Stack — Primary Docker Image (elabftw/elabimg)
The primary LabLynx One Docker image (elabftw/elabimg:stable) is built on Alpine Linux and bundles the following components:
| Component | Version | License | Source |
|---|---|---|---|
| eLabFTW | 5.3.x (stable) | AGPL-3.0 | github.com/elabftw/elabftw |
| Alpine Linux | 3.20.x | MIT (kernel: GPL-2.0) | alpinelinux.org |
| nginx | 1.26.x | BSD 2-Clause | nginx.org |
| PHP | 8.3.x | PHP License v3.01 | php.net |
| PHP-FPM | 8.3.x | PHP License v3.01 | php.net |
| s6-overlay | 3.x | ISC | github.com/just-containers/s6-overlay |
| skalibs | 2.x | ISC | skarnet.org/software/skalibs |
| execline | 2.x | ISC | skarnet.org/software/execline |
| s6 | 2.x | ISC | skarnet.org/software/s6 |
| OpenSSL | 3.3.x | Apache 2.0 | openssl.org |
| zlib | 1.3.x | MIT-like | zlib.net |
| libc (musl) | 1.2.x | MIT | musl.libc.org |
| libcurl | 8.x | MIT (curl) | curl.se |
| GnuPG (gpg) | 2.4.x | GPL-3.0 | gnupg.org |
| Ghostscript | 10.x | AGPL-3.0 | ghostscript.com |
| ImageMagick | 7.x | MIT-variant | imagemagick.org |
| FreeType | 2.x | FTL (BSD-like) | freetype.org |
| libpng | 1.6.x | libpng License | libpng.org |
| libjpeg-turbo | 3.x | IJG / BSD 3-Clause | libjpeg-turbo.org |
| libzip | 1.x | BSD 3-Clause | libzip.org |
| libxml2 | 2.12.x | MIT | gitlab.gnome.org/GNOME/libxml2 |
| libxslt | 1.1.x | MIT | gitlab.gnome.org/GNOME/libxslt |
| ICU | 74.x | Unicode License | icu.unicode.org |
| brotli | 1.1.x | MIT | github.com/google/brotli |
| borgbackup (optional) | 1.4.x | BSD 3-Clause | borgbackup.readthedocs.io |
2.3 PHP Extensions (Bundled in Container)
| Extension | License | Role in LabLynx One |
|---|---|---|
php8-bcmath | PHP / MIT | Arbitrary-precision arithmetic. Required for cryptographic operations. |
php8-ctype | PHP | Character type checking. Required for input validation. |
php8-curl | PHP / MIT | cURL HTTP client. Required for API calls and timestamping. |
php8-dom | PHP | XML Document Object Model. Required for HTML/XML processing. |
php8-exif | PHP | EXIF image metadata. Required for image handling. |
php8-fileinfo | PHP | File type detection. Required for file upload validation. |
php8-gd | PHP / MIT | Image processing (GD library). Required for image manipulation, PDF generation. |
php8-gettext | PHP | Internationalization/localization. Multi-language support. |
php8-iconv | PHP | Character encoding conversion. Required for encoding handling. |
php8-intl | PHP / Unicode | ICU internationalization. Required for locale-aware operations. |
php8-json | PHP | JSON encoding/decoding. Required for API and data serialization. |
php8-ldap | PHP / OpenLDAP | LDAP authentication. Required for LDAP/AD integration. |
php8-mbstring | PHP | Multibyte string handling. Required for Unicode text processing. |
php8-opcache | PHP | PHP opcode caching. Performance optimization. |
php8-openssl | PHP / Apache 2.0 | OpenSSL cryptographic functions. Required for TLS, encryption, e-signatures. |
php8-pdo | PHP | PHP Data Objects. Required for database connectivity. |
php8-pdo_mysql | PHP | MySQL PDO driver. Required for MySQL database access. |
php8-session | PHP | Session management. Required for user sessions. |
php8-simplexml | PHP | SimpleXML parser. Required for XML processing. |
php8-sodium | PHP / ISC | libsodium binding. Required for Ed25519 signing, encrypted storage. |
php8-tokenizer | PHP | PHP tokenizer. Required internally. |
php8-xml | PHP | XML processing. Required for XML output. |
php8-xmlwriter | PHP | XML writer. Required for XML generation. |
php8-zip | PHP / BSD 3-Clause | ZIP archive handling. Required for ZIP export/import. |
2.4 PHP Composer Packages
| Package | Version | License | Role |
|---|---|---|---|
mpdf/mpdf | v8.2.x | GPL-2.0 | PDF generation from HTML. Experiment PDF exports. |
monolog/monolog | v3.x | MIT | Application logging framework. |
symfony/console | v6/v7 | MIT | CLI commands (db init, maintenance tools). |
symfony/cache | v6/v7 | MIT | Caching abstraction layer. |
symfony/http-foundation | v6/v7 | MIT | HTTP request/response abstraction. |
symfony/mailer | v6/v7 | MIT | Email sending (SMTP notifications, invitations). |
symfony/mime | v6/v7 | MIT | MIME type handling. |
symfony/translation | v6/v7 | MIT | Internationalization and translation. |
symfony/yaml | v6/v7 | MIT | YAML parsing. |
twig/twig | v3.x | BSD 3-Clause | HTML template rendering engine. |
league/commonmark | v2.x | BSD 3-Clause | Markdown to HTML conversion. |
league/html-to-markdown | v5.x | MIT | HTML to Markdown for exports. |
intervention/image | v2/v3 | MIT | Image manipulation and processing. |
ramsey/uuid | v4.x | MIT | UUID generation for ELabIDs. |
paragonie/constant_time_encoding | v2.x | MIT | Constant-time string encoding for security. |
paragonie/random_compat | v9.x | MIT | Cryptographically secure random numbers. |
psr/log | v3.x | MIT | PSR-3 logging interface standard. |
psr/cache | v3.x | MIT | PSR-6 cache interface standard. |
psr/container | v2.x | MIT | PSR-11 container interface standard. |
psr/http-message | v2.x | MIT | PSR-7 HTTP message interface. |
php-http/httplug | v2.x | MIT | HTTP client abstraction. |
guzzlehttp/guzzle | v7.x | MIT | HTTP client for TSA, PubChem API calls. |
guzzlehttp/psr7 | v2.x | MIT | PSR-7 HTTP message implementation. |
php-di/php-di | v7.x | MIT | Dependency injection container. |
defuse/php-encryption | v2.x | MIT | AES-256 encryption for stored credentials. |
minisign-php | v1.x | MIT | Ed25519 cryptographic signature verification. |
2.5 JavaScript / Frontend Libraries
| Library | Version | License | Role |
|---|---|---|---|
| TinyMCE | v6/v7 | MIT (Community) | Rich text WYSIWYG editor. Primary experiment body editor. |
| ChemDoodle Web | v9.x | GPL-3.0 | 3D molecular viewer for CIF/PDB/MOL files. |
| Ketcher (EPAM) | v2.x | Apache 2.0 | 2D chemical structure drawing editor. |
| 3Dmol.js | v2.x | BSD 3-Clause | 3D molecular visualization. |
| mermaid.js | v10.x | MIT | Diagram rendering from text markup. |
| SnapGene Viewer | N/A | Proprietary free | DNA sequence visualization (.gb, .ape, .dna files). |
| Chart.js | v4.x | MIT | Canvas-based charting library. |
| SheetJS (XLSX.js) | v0.18.x | Apache 2.0 (Community) | Excel file parsing and export. |
| Bootstrap | v5.x | MIT | CSS framework for responsive UI components. |
| jQuery | v3.x | MIT | JavaScript utility library (legacy components). |
| Font Awesome | v6.x | MIT (icons) CC BY 4.0 (fonts) | Icon library used throughout the UI. |
| MathJax | v3.x | Apache 2.0 | LaTeX mathematical equation rendering. |
| CodeMirror | v6.x | MIT | Code block editor with syntax highlighting. |
| DOMPurify | v3.x | Apache 2.0 / MIT | HTML sanitization to prevent XSS attacks. |
| sortablejs | v1.x | MIT | Drag-and-drop sortable lists. |
| interact.js | v1.x | MIT | Drag-and-resize interactions. |
| pako | v2.x | MIT | zlib/deflate compression in JavaScript. |
| lodash | v4.x | MIT | JavaScript utility library. |
| marked | v9.x | MIT | Markdown parser for preview mode. |
2.6 Database Container (MySQL 8.4)
| Component | Version | License |
|---|---|---|
| MySQL Community Server | 8.4.x | GPL-2.0 |
| mysql:8.4 Docker Image | 8.4.x | GPL-2.0 + various OS licenses |
| MySQL Connector/C | 8.4.x | GPL-2.0 with FOSS Exception |
| OpenSSL (in MySQL image) | 3.x | Apache 2.0 |
MySQL 8.4 is the Long Term Support (LTS) release series. LabLynx recommends pinning to 8.4.x for production deployments. MySQL 8.0.x reached End of Life in April 2026. MySQL 9.x (Innovation series) is not yet recommended for production LabLynx One deployments.
2.7 Docker and Container Infrastructure
| Component | Version | License | Role |
|---|---|---|---|
| Docker Engine | 27.x | Apache 2.0 | Container runtime. Core of the deployment platform. |
| Docker Compose Plugin | 2.x | Apache 2.0 | Multi-container orchestration. Manages web + mysql containers. |
| containerd | 1.7.x | Apache 2.0 | Container runtime used by Docker Engine. |
| runc | 1.1.x | Apache 2.0 | OCI runtime specification implementation. |
| libnetwork | 0.8.x | Apache 2.0 | Docker networking layer. |
| Moby (Docker source) | 27.x | Apache 2.0 | Open-source Docker Engine codebase. |
| BuildKit | 0.13.x | Apache 2.0 | Advanced Docker image build engine. |
| CNI plugins | 1.4.x | Apache 2.0 | Container Network Interface plugins. |
| iptables | 1.8.x | GPL-2.0 | Linux firewall/NAT rules for Docker networking. |
| Docker Hub Registry | N/A | Service terms / Apache 2.0 (client) | Container image registry hosting elabftw/elabimg and mysql images. |
2.8 Ubuntu Host OS Components
| Component | Version | License | Role |
|---|---|---|---|
| Ubuntu Server | 24.04 LTS | GPL (kernel), MIT/BSD/Apache (userspace) | Host OS. LTS until April 2029. |
| Linux Kernel | 6.8.x | GPL-2.0 | OS kernel. Container namespaces, cgroups. |
| systemd | 255.x | LGPL-2.1+ | Service manager. Manages Docker daemon. |
| OpenSSH Server | 9.6.x | BSD-style | Remote administration access. |
| ufw | 0.36.x | GPL-3.0 | Host-level firewall configuration utility. |
| AppArmor | 4.0.x | GPL-2.0 | Mandatory Access Control for container security. |
| curl | 8.5.x | MIT (curl) | Used by elabctl installer. |
| openssl | 3.0.x | Apache 2.0 | Host TLS utilities and certificate management. |
| apt | 2.7.x | GPL-2.0 | Ubuntu package manager. |
| gpg / gnupg2 | 2.4.x | GPL-3.0 | GPG key verification for Docker repository. |
| ca-certificates | 20240203 | MPL-2.0 / Various | Trusted root certificate bundle. |
| borgbackup | 2.0.x | BSD 3-Clause | Optional backup tool. |
| dialog | 1.3.x | LGPL-2.0+ | TUI dialog boxes used by elabctl. |
| cron | 3.0pl1 | ISC | Scheduled task execution for backups. |
| logrotate | 3.21.x | GPL-2.0 | Log file rotation. |
| fail2ban | 1.0.x | GPL-2.0 | Intrusion prevention — blocks IPs after repeated failed auth. |
2.9 Optional Add-On Components
| Component | Version | License | Role |
|---|---|---|---|
| Redis | 7.2.x | BSD 3-Clause | Optional session storage. Required for HA/multi-container deployments. |
| Indigo Chemistry Plugin | latest | Apache 2.0 | Chemical structure editor (Ketcher) and substructure search. |
| OpenCloning Plugin | latest | MIT | DNA cloning workflow integration. |
| Let's Encrypt / Certbot | 2.x | Apache 2.0 | Free TLS certificate issuance and auto-renewal. |
| Nginx (reverse proxy) | 1.26.x | BSD 2-Clause | Optional external reverse proxy with TLS termination. |
| Traefik | 3.x | MIT | Alternative reverse proxy with built-in Let's Encrypt support. |
2.10 Compliance Note on AGPL-3.0
LabLynx One includes eLabFTW software licensed under AGPL-3.0. The key obligations are:
- If you run a modified version of eLabFTW over a network, you must make the modified source code available to users of that service.
- LabLynx distributes an unmodified (branded) version of eLabFTW and satisfies this requirement through the public GitHub repository.
- LabLynx proprietary components (branding, configuration files, integration scripts) that do not constitute derived works of eLabFTW are not subject to AGPL-3.0.
- On-premises customers who modify eLabFTW source and use those modifications to provide network services must make the modifications available under AGPL-3.0.
System Architecture
LabLynx One is a three-tier web application deployed using Docker containerization. Understanding the architecture is essential for infrastructure planning, security configuration, and troubleshooting.
3.1 Application Architecture Overview
All three tiers are orchestrated by Docker Compose (or an equivalent OCI-compatible engine) on a single Linux host for standard deployments. The web/application tier runs in one container (elabftw/elabimg); the database tier runs in a separate container (mysql, MySQL only — MariaDB is not supported). Both containers communicate over an isolated internal Docker bridge network (elabftw-net).
eLabFTW (the platform underlying LabLynx One) is supported only on 64-bit GNU/Linux, and only in containers. Docker Compose is the most common runtime and the one this manual documents in detail, but Podman is recommended on RHEL-family hosts and Kubernetes is recommended for large or managed deployments. LabLynx's own elabctl-based deployment path (Chapter 7) uses Docker Compose under the hood.
Request Flow
- User browser sends HTTPS request to server IP/domain on port 443.
- Nginx receives the request. Static files (CSS, JS, images) are served directly. PHP requests are forwarded to PHP-FPM over a Unix socket.
- PHP-FPM runs the eLabFTW PHP code, queries MySQL as needed, and generates an HTML response.
- The response passes back through PHP-FPM to nginx, which returns it to the browser with appropriate headers.
- All database reads/writes occur over the
elabftw-netDocker bridge between the web container and the mysql container.
| Layer | Image | External Port | Notes |
|---|---|---|---|
| Web + App | elabftw/elabimg:stable | 443 (HTTPS) | TLS terminates here |
| Database | mysql:8.4 | None (unexposed) | Internal only via elabftw-net |
| Session Store | redis:7-alpine | None | Optional — required for HA |
| Chemistry Plugin | elabftw/chem-plugin | None | Optional chemical substructure search |
3.2 Internal Container Services (s6-overlay)
The elabftw/elabimg container runs four concurrent services managed by s6-overlay, the container process supervisor:
| Service | Description |
|---|---|
| nginx | Web server. Handles TLS, static file serving, and PHP-FPM proxying. Config: /etc/nginx/ |
| php-fpm | PHP FastCGI Process Manager. Executes the LabLynx One PHP application. Manages a pool of PHP worker processes. Config: /etc/php83/php-fpm.d/ |
| cron (fcron) | Runs scheduled tasks: session garbage collection, temporary file cleanup, and configured automation. |
| php-fpm status | Exposes /php-status endpoint (password-protected) for PHP-FPM pool metrics monitoring. Enable via STATUS_PASSWORD environment variable. |
3.3 Data Persistence Model
Two Docker bind mounts provide persistent storage outside the containers. Both must exist on the host before starting containers and must be included in all backup procedures.
| Host Path | Container Path | Content |
|---|---|---|
/var/elabftw/web | /elabftw/uploads | All user-uploaded files, attachment exports, and generated ZIPs. Must survive container updates. |
/var/elabftw/mysql | /var/lib/mysql | Complete MySQL database. Primary data directory. Must be backed up regularly. |
Data stored only inside containers is lost when containers are removed or recreated. Both bind mount directories must exist on the host before starting containers and must be included in every backup procedure.
3.4 Networking Architecture
| Network Component | Description |
|---|---|
| elabftw-net | Internal Docker bridge network. Carries all web ↔ mysql traffic. Not accessible from outside the host. MySQL does NOT expose port 3306 externally. |
| Host port 443 | The web container exposes port 443 (HTTPS) to the Docker host. In security-hardened deployments, restrict to a specific interface: 127.0.0.1:443:443. |
| Reverse Proxy (optional) | Set DISABLE_HTTPS=true to let a front-end reverse proxy (nginx, Traefik, HAProxy) handle TLS. Configure CORS variables if the API is accessed cross-domain. |
Hardware and Software Requirements
Minimum and recommended hardware specifications, software prerequisites, network port requirements, and TLS certificate options for all LabLynx One deployment models.
4.1 Minimum Hardware Requirements
| Component | Minimum | Recommended (Production) |
|---|---|---|
| CPU Architecture | 64-bit x86_64 (AMD64) | x86_64 — ARM64 supported but not primary tested |
| CPU Cores | 2 cores | 4+ cores — PHP-FPM and MySQL both benefit |
| RAM | 2 GB | 4 GB (≤50 users) · 8 GB+ (large deployments) |
| Disk — OS + Docker | 20 GB | 40+ GB |
| Disk — Application Data | Varies | ~1 GB per 100 experiments. Plan 100 GB–1 TB for active labs with instrument data. |
| Network | 100 Mbps LAN | Gigabit Ethernet + static public IP or DNS FQDN |
PHP_MAX_CHILDREN and MAX_PHP_MEMORY are the primary performance tuning parameters. On a 4 GB RAM server, start with PHP_MAX_CHILDREN=20 and MAX_PHP_MEMORY=512M. Monitor /php-status for pool utilization under load.
4.2 Recommended Production Configurations
Small Lab (1–10 users)
4 CPU · 4 GB RAM · 100 GB SSDPHP_MAX_CHILDREN=20MAX_PHP_MEMORY=512M
Medium Lab (10–50 users)
8 CPU · 8 GB RAM · 500 GB SSDPHP_MAX_CHILDREN=50MAX_PHP_MEMORY=1G
Large Lab (50–200+ users)
16+ CPU · 16+ GB RAM · 1+ TB NFS/SANPHP_MAX_CHILDREN=100MAX_PHP_MEMORY=2GUSE_REDIS=true
High Availability
2+ app servers + load balancer
Shared NFS for uploads
External MySQL (Group Replication)USE_REDIS=true
4.3 Software Prerequisites (Host OS)
| Requirement | Specification |
|---|---|
| Operating System | Any 64-bit GNU/Linux distribution. Ubuntu Server LTS and Rocky Linux/RHEL are the most common choices; Rocky/RHEL is recommended if using Podman instead of Docker. Fully patched. |
| Container Runtime | Docker (recommended for most setups) or Podman (recommended on RHEL-family hosts) or Kubernetes (recommended for large/managed deployments). This manual documents the Docker Compose path via elabctl, which is the fastest route to a working install. |
| Docker Engine | Latest stable Docker CE — from Docker's official apt/yum repository. NOT the snap package (known to cause issues on Ubuntu). |
| Docker Compose Plugin | Docker Compose V2 (plugin) — required by elabctl. Do not use the legacy standalone docker-compose tool. |
| curl | 8.5.x or later — for downloading configuration files and the elabctl installer. |
| dialog | 1.3.x or later — for the interactive elabctl installation wizard. |
| bash | 5.2.x or later — for running elabctl and installation scripts. |
| borgbackup (optional) | 2.x or later — required if using elabctl backup. |
| openssl | 3.0.x or later — for TLS certificate management and key generation. |
| Domain Name | A fully qualified domain name (FQDN) resolving to the server's public IP. Required for HTTPS and Let's Encrypt. |
| Outbound Internet | Required for: Docker Hub image pulls, Let's Encrypt validation, RFC 3161 TSA requests, PubChem compound lookup, software updates. |
4.4 Network Ports and Firewall Requirements
| Port | Protocol | Direction | Purpose |
|---|---|---|---|
| 443 (TCP) | HTTPS | Inbound | Required. All user browser traffic. LabLynx One web interface and REST API. |
| 80 (TCP) | HTTP | Inbound | Optional. Required only for Let's Encrypt HTTP-01 challenge. Redirect to 443. |
| 22 (TCP) | SSH | Inbound | Recommended. Server administration. Restrict to admin IPs only. |
| 3306 (TCP) | MySQL | Internal only | Must NOT be exposed externally. Only elabftw-net container traffic. |
| 6379 (TCP) | Redis | Internal only | Must NOT be exposed externally. Only if Redis is deployed. |
| Outbound 443 | HTTPS | Outbound | Required. Docker Hub, Let's Encrypt, TSA (RFC 3161), PubChem API. |
| Outbound 25/587 | SMTP | Outbound | Required for email notifications if using external SMTP relay. |
4.5 TLS / SSL Certificate Options
| Option | Configuration | Requirements |
|---|---|---|
| Let's Encrypt (recommended) | ENABLE_LETSENCRYPT=true | Public domain name, outbound port 443, port 80 for HTTP-01 challenge. Certificates auto-renew before expiry. |
| Custom Certificate | Mount /etc/letsencrypt:/ssl in docker-compose.yml | Place fullchain.pem and privkey.pem at /etc/letsencrypt/live/<SERVER_NAME>/. Supports any CA (DigiCert, Sectigo, GlobalSign, internal CA). |
| Reverse Proxy Terminates TLS | DISABLE_HTTPS=true | External nginx, Traefik, or HAProxy handles TLS and forwards plain HTTP to the container. Use for enterprise environments with centralized certificate management. |
Pre-Installation: Host Preparation (Ubuntu Reference Path)
Before installing Docker or LabLynx One, prepare the Linux host: update the OS, configure the hostname, set up the firewall, and create the required data directories. This chapter documents the Ubuntu Server + Docker path, which is LabLynx's standard reference deployment; see the note below for RHEL/Rocky + Podman or Kubernetes alternatives.
LabLynx One's underlying platform supports any 64-bit GNU/Linux host with Docker, Podman, or Kubernetes. Podman is recommended on RHEL/Rocky Linux hosts (substitute firewalld commands for ufw below, and podman/podman-compose for the Docker commands in Chapter 6). Kubernetes deployments are recommended for large or managed environments and follow a different manifest-based setup outside the scope of this reference path — contact LabLynx support for a Kubernetes deployment guide.
- A 64-bit Ubuntu Server 24.04 LTS system with root (sudo) access.
- A fully qualified domain name (FQDN) pointing to your server's public IP.
- Outbound internet connectivity on port 443 (HTTPS).
- At least 4 GB RAM, 4 CPU cores, and 100 GB available disk space.
5.1 Update the Operating System
5.2 Configure the Hostname and DNS
5.3 Configure the Firewall (ufw)
Docker manages its own iptables rules and bypasses ufw. Docker-exposed ports are accessible even if ufw would block them. Fix this by restricting Docker port bindings to 127.0.0.1 and using a reverse proxy, or install the ufw-docker package. See Section 10.3.
5.4 Create the LabLynx One Data Directories
If your uploads directory is on an NFS mount with enforced UIDs, adjust ELABFTW_USERID and ELABFTW_GROUPID environment variables in docker-compose.yml to match the NFS-imposed ownership.
Installing Docker Engine and Docker Compose
Install Docker Engine and the Docker Compose plugin from Docker's official apt repository. Never use the snap-packaged version.
Do NOT install Docker via sudo snap install docker. The snap-packaged Docker causes permission and volume mounting issues with LabLynx One. Always install from the official Docker apt repository as described below.
6.1 Remove Conflicting Packages
6.2 Add the Docker Official APT Repository
6.3 Install Docker Engine and Compose Plugin
6.4 Configure Docker to Start on Boot
6.5 (Optional) Allow Non-Root Docker Access
Adding a user to the docker group is effectively equivalent to giving them root access to the host system. Only add trusted administrators in production environments.
6.6 Install elabctl (Preview)
elabctl is the command-line tool that manages the full LabLynx One lifecycle: initial configuration, starting/stopping, backups, and updates. Chapter 7 covers it in full; the quick install is:
LabLynx One Installation
Install and configure LabLynx One using elabctl (the recommended path), pull container images, initialize the database, and verify the installation. A manual, elabctl-free alternative is included at the end of this chapter for environments that prefer to manage docker-compose.yml directly.
7.1 Install elabctl
elabctl is the command-line tool that manages the full lifecycle of an LabLynx One install: initial configuration, starting/stopping services, database initialization, backups, and updates. It is a plain bash script — not strictly required, but strongly recommended.
7.2 Run the Configuration Wizard
The elabctl install wizard walks you through the initial configuration and writes the result to /etc/elabftw.yml by default (a single Docker Compose file that also contains LabLynx One's environment configuration).
After the wizard completes, open the generated file and review it — it is heavily commented to help with further configuration (persistent storage paths, TLS certificates, ports, reverse proxy settings, etc.):
| Variable | Service | Set To |
|---|---|---|
DB_PASSWORD | web | A strong random password (the wizard generates one by default) |
SITE_URL | web | https://elab.yourlab.com |
PHP_TIMEZONE / TZ | web | Your local timezone (e.g., America/Chicago) |
SERVER_NAME | web | elab.yourlab.com (without https://) |
ENABLE_LETSENCRYPT | web | true (recommended for public servers) |
MYSQL_ROOT_PASSWORD | mysql | A different strong random password |
MYSQL_PASSWORD | mysql | Must exactly match DB_PASSWORD above |
The DB_PASSWORD value in the web service environment must exactly match the MYSQL_PASSWORD value in the mysql service environment. If these differ, the web container cannot connect to the database and LabLynx One will not start.
7.3 Launch Services
7.4 Initialize the Database
After the first start, install the database structure:
7.5 Verify Installation
7.6 First Login and SysAdmin Setup
- Navigate to
https://elab.yourlab.comin a browser. Accept the certificate warning if Let's Encrypt has not yet issued the certificate. - On the registration page, create your first account. The first account registered is automatically granted SysAdmin privileges.
- After logging in as SysAdmin, navigate to User Avatar → Sysconfig to configure email (SMTP settings) — this is required before users can reset passwords or receive notifications — create your first team, and configure the timestamping service (TSA).
- Create your first Team Admin: Admin Panel → Users → promote the first researcher to Admin.
- Invite additional users via Admin Panel → Users → Add User.
7.7 Manual Alternative (Without elabctl)
If you prefer not to install elabctl, you can obtain a pre-populated Docker Compose configuration file directly and manage it with plain docker compose commands:
The complete annotated configuration below reflects the same variables the wizard would generate, for reference or for environments that manage configuration via tools like Ansible:
Whichever path you use, the underlying container image (elabftw/elabimg) and database (MySQL, not MariaDB) are identical. elabctl only changes how you manage the lifecycle around them — it does not change the application itself.
Post-Installation Configuration
Configure automatic startup on boot, set up automated backups, and configure log rotation.
8.1 Configure Automatic Container Restart on Boot
Because the compose file sets restart: always on both services, Docker will already restart the containers automatically whenever the Docker daemon starts — which is why Chapter 6.4 enables docker and containerd at boot. The systemd unit below is optional and mainly useful if you want an explicit, named systemd service to start/stop/monitor alongside other host services.
8.2 Set Up Automated Backups
Store backup copies on a separate physical or network location. A backup stored on the same disk as the application provides no protection against disk failure. Use offsite storage: S3, Azure Blob, Google Cloud Storage, NFS, or a separate physical backup appliance.
Option A: elabctl Backup (uses mysqldump + borgbackup)
The MySQL database is dumped via mysqldump (bundled in the mysql container); uploaded files are backed up via borgbackup, which must be installed and configured first. Note that your configuration file (/etc/elabftw.yml) is deliberately not included in elabctl backup — back it up separately (e.g., with Ansible or your configuration-management tool of choice) since it contains secrets like SECRET_KEY.
Even with automated backups, keep multiple layers: a full VM/host snapshot, the mysqldump, the borg archive, and periodic filesystem snapshots. Test restores regularly — a backup that has never been restored is not a verified backup.
Option B: Manual mysqldump + rsync
8.3 Configure Log Rotation
8.4 Authentication Options
LabLynx One supports four authentication mechanisms, configured from the Sysconfig Panel. It's recommended to enable only one and hide the others so users aren't confused about which to use.
| Method | Description |
|---|---|
| Local | Email + password stored in the LabLynx One database. Enabled by default. |
| SAML | Federate authentication to one or more Identity Providers (IdP). |
| LDAP | Verify credentials against an LDAP directory service. |
| External | Trust request headers set by upstream middleware (e.g., Apache's auth_mellon). |
If you disable Local authentication and later get locked out because SAML/LDAP fails, connect to the MySQL container and run: update config set conf_value = '1' where conf_name = 'local_auth_enabled'; — this re-enables the local login form so you can get back in.
8.5 Optional: S3-Compatible Upload Storage
By default, uploaded files are stored on the /var/elabftw/web bind mount. As an alternative, LabLynx One can store uploads in any S3-compatible bucket (AWS S3, Scaleway, MinIO, etc.).
8.6 Monitoring Endpoints
The container exposes several unauthenticated and Basic-Auth-protected endpoints useful for uptime monitoring and metrics collection:
| Endpoint | Auth | Purpose |
|---|---|---|
/healthcheck | None | 204 if nginx is up |
/php-ping | None | 200 if php-fpm is up |
/healthcheck.php | None | 200 + "ok" if nginx, php-fpm, and MySQL are all reachable |
/php-status | Basic (user elabftw, password = STATUS_PASSWORD) | PHP-FPM pool metrics |
/nginx-status | Basic | Nginx status module metrics |
/metrics | Basic | OpenMetrics 1.0 endpoint (experiment/upload counts, etc.) for Prometheus-style collectors |
If STATUS_PASSWORD is not set, a random unknown password is generated and these protected endpoints are effectively disabled. None of these endpoints produce access-log entries.
Updating LabLynx One
LabLynx One updates are distributed as new Docker image versions. Always read the release notes and back up before updating.
9.1 Standard Update Procedure (with elabctl)
- Check your current version — shown in the bottom right of every page — and read the release notes for the target version:
https://github.com/elabftw/elabftw/releases/latest - Backup first:
sudo elabctl backup— verify completion before proceeding. - Update:
sudo elabctl update— this pulls the new image, recreates the container, and is the single recommended command if elabctl is installed. - Run the database migration:
sudo docker exec -it elabftw bin/console db:update
If you free up disk space is a concern after several updates, docker system prune -a removes old, unused images.
9.2 Standard Update Procedure (without elabctl)
- Backup first using your chosen mysqldump/rsync procedure (Chapter 8.2, Option B) — verify completion.
- Pull the latest stable image:
sudo docker compose -f /etc/elabftw.yml pull - Recreate containers:
sudo docker compose -f /etc/elabftw.yml downthensudo docker compose -f /etc/elabftw.yml up -d - Run database migration:
sudo docker exec -it elabftw bin/console db:update
If you have pinned a specific version tag (e.g., elabftw/elabimg:5.6.0), update the tag in /etc/elabftw.yml before pulling. LabLynx recommends using stable (or latest) for automatic minor updates, and pinning a specific version for strictly change-controlled environments.
9.3 Pinning a Specific Version
9.4 Very Old Installations
If you are updating an installation that predates the current schema conventions, the db:update command chain has special-case commands for very old versions:
| If you are on | Run this once, before continuing normal updates |
|---|---|
| < 2.0.7 (Dec 2018) | Update as soon as possible; very old and no longer directly supported |
| < 3.0.0 (Apr 2019) | bin/console db:updateto3 |
| < 3.4.0 (Mar 2020) | bin/console db:updateTo34 |
db:revert XYZ can be used to revert the changes made by a specific migration schema, and --force ignores errors during migration — only use --force if you understand exactly why the error occurred.
9.5 Rollback Procedure
Security Hardening
Recommended hardening steps for all production deployments — essential for regulated environments where data integrity and access control are compliance requirements.
10.1 SSH Security
10.2 Install fail2ban
10.3 Docker and ufw Integration
10.4 File System Security
10.5 Enable Automatic Security Updates
10.6 TLS Security Configuration Reference
| Parameter | Configuration |
|---|---|
| TLS Protocols | TLSv1.2 and TLSv1.3 only. TLS 1.0 and 1.1 are disabled. |
| Cipher Suites | Modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Prioritizes forward secrecy. |
| HSTS | HTTP Strict Transport Security header enforces HTTPS on subsequent browser visits. |
| OCSP Stapling | Certificate revocation status cached by nginx for faster TLS handshakes. |
| Session Cache | TLS session resumption cache enabled for performance. |
| Security Headers | X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, X-XSS-Protection, Content-Security-Policy. |
Monitoring and Health Checks
Commands and techniques for monitoring container health, PHP-FPM performance, database size, and disk utilization.
11.1 Container Health Monitoring
11.2 PHP-FPM and Nginx Status Endpoints
Enable the /php-status, /nginx-status, and /metrics endpoints by setting STATUS_PASSWORD in /etc/elabftw.yml under the web service (see also Chapter 8.6 for the unauthenticated /healthcheck family of endpoints):
None of the monitoring endpoints (/healthcheck, /php-ping, /healthcheck.php, /php-status, /nginx-status, /metrics) produce access-log entries, so polling them frequently won't clutter your logs.
11.3 Database Monitoring
11.4 Disk Space Monitoring
Troubleshooting
Solutions for the most common installation and operational issues.
| Issue | Symptom | Resolution |
|---|---|---|
| Containers fail to start | docker compose logs shows connection error | Verify DB_PASSWORD matches MYSQL_PASSWORD. Wait 30 seconds for MySQL healthcheck. Check docker compose ps for healthy status on mysql container. |
| Cannot access HTTPS | curl: (7) Failed to connect | Verify port 443 is open: sudo ufw status. Check Docker port binding: sudo docker ps shows 0.0.0.0:443. Check nginx: sudo docker logs elabftw | grep nginx. |
| Certificate error in browser | SSL_ERROR_RX_RECORD_TOO_LONG | DISABLE_HTTPS=true but accessing via HTTPS. If using a reverse proxy, ensure it handles TLS and forwards plain HTTP to the container. |
| Let's Encrypt certificate fails | Certbot log shows challenge failed | Port 80 must be open and accessible from the internet for HTTP-01 validation. SERVER_NAME must exactly match your DNS FQDN. |
| 500 Internal Server Error | Browser 500, nginx logs show PHP-FPM error | Check PHP-FPM logs: sudo docker exec elabftw cat /var/log/php-fpm.log. Common causes: insufficient MAX_PHP_MEMORY, failed DB connection, bad file permissions on /var/elabftw/web. |
| Database initialization fails | bin/init db:install returns error | Verify MySQL is running and healthy: sudo docker ps. Check credentials in docker-compose.yml. Test connection: sudo docker exec -it mysql mysql -u elabftw -p elabftw. |
| Uploads permission denied | PHP writes fail, attachments don't save | Run: sudo chown -R 101:101 /var/elabftw/web. The nginx user (UID 101) must own the uploads directory. |
| Container keeps restarting | docker ps shows restarting status | Check logs immediately: sudo docker logs elabftw --tail 20. Common cause: environment variable misconfiguration or missing SECRET_KEY. |
| High memory usage | docker stats shows >90% memory | Reduce PHP_MAX_CHILDREN or MAX_PHP_MEMORY. Add physical RAM. Check for memory leaks via consistent growth over hours in docker stats. |
| MySQL slow to start | Web container shows 'waiting for mysql' | The healthcheck retries 42 times × 5s = 3.5 minutes total. If MySQL still doesn't start, check: sudo docker logs mysql. Verify /var/elabftw/mysql has correct permissions and sufficient disk space. |
12.1 Useful Diagnostic Commands
LabLynx One Security & Compliance Guide
For IT reviewers, security officers, and compliance teams evaluating LabLynx One.
How to Use This Guide
This guide is written for the people who must answer a hard question before LabLynx One can be deployed: is this system trustworthy enough to hold our laboratory's records? It is intended for IT reviewers, information security officers, compliance managers, and procurement teams conducting a vendor security assessment.
For regulated laboratories, a software vendor's security posture and compliance certifications are not background information — they are vendor qualification criteria. A laboratory cannot deploy a system to generate regulated records if the vendor operating that system cannot demonstrate adequate security controls, independent verification of those controls, and alignment with the regulatory frameworks the laboratory itself must satisfy.
LabLynx maintains a formal, documented information security program that is independently audited annually and aligned with US federal government security standards. The chapters that follow describe each component of that program in the detail required for a vendor qualification review, security questionnaire response, or regulatory audit.
This guide covers LabLynx One, the sciCloud.net hosting platform that supports it, and the organizational security controls LabLynx maintains as the operating company. Pricing is intentionally excluded — current pricing is available at elabeln.com/pricing.
Security Architecture & Shared Responsibility
LabLynx One's security architecture rests on Amazon Web Services (AWS) infrastructure, LabLynx's own operational controls, and a clearly defined division of responsibility between the two.
Infrastructure Security — AWS Foundation
LabLynx's sciCloud.net platform is built on AWS US East/West infrastructure. AWS itself carries SSAE 18 SOC 1, SOC 2, and SOC 3 certifications covering physical data centers, hardware, hypervisor virtualization, network backbone, and managed services infrastructure. AWS's SOC 3 report — covering Security, Availability, Confidentiality, and Privacy Trust Services Criteria for the period April 1, 2024 through March 31, 2025 and spanning 185 in-scope services — provides publicly available, independently audited evidence of the physical and infrastructure security controls underpinning every LabLynx One deployment.
The Shared Responsibility Model
AWS secures the cloud infrastructure itself — physical data centers, hypervisors, and managed service infrastructure. LabLynx is responsible for everything built and operated on top of that infrastructure. This is not a gap; it is how cloud security is designed to work, and LabLynx explicitly addresses every layer AWS does not cover.
SOC 3 certified physical access controls, environmental controls, and hardware disposal. LabLynx One clients inherit this certification.
SOC 3 certified hypervisor isolation, patching, and virtual machine separation between client environments.
DDoS protection (AWS Shield), Web Application Firewall (WAF), and GuardDuty threat detection at the network layer.
Least-privilege IAM policies; MFA on all privileged accounts; semi-annual access reviews enforcing ongoing least-privilege.
Scheduled maintenance with weekly vulnerability reviews via AlienVault USM; emergency patching for critical vulnerabilities.
Secure SDLC practices; OWASP Top 10 controls; annual penetration testing performed as part of the Trustnet NIST 800-53 audit.
Role-based access control enforced at the application level; semi-annual access reviews; least-privilege enforcement per user, group, and project.
AES-256 encryption at rest via AWS KMS; TLS 1.2 or higher for all data in transit. LabLynx configures and manages encryption policy; AWS KMS provides the key management infrastructure.
Automated backups with tested RTO/RPO objectives; documented contingency plan reviewed annually; geographically distributed secondary storage.
Mandatory security training at onboarding and at every policy update; randomized phishing simulations; training records retained.
Deployment Options
Every LabLynx One deployment uses exactly one of two hosting models. There is no third "client-hosted cloud" option.
LabLynx's managed, AWS-based hosting environment. Standard for all client deployments unless a laboratory specifically requires self-hosting.
- AES-256 encryption at rest; TLS 1.2+ in transit
- Managed backups with tested restore
- Dedicated GxP-validated tenancy option available
Deployment on the client's own infrastructure, including on-premises or air-gapped environments, for organizations with full data sovereignty requirements.
- Air-gapped deployment supported
- Client-managed network and data center
- Same application security controls as sciCloud.net
Identity, Access & Authentication
Access to LabLynx One is governed by role-based access control, single sign-on integration, and a formal review cycle that keeps access privileges aligned to actual need.
Role-Based Access Control
LabLynx One implements role-based access control (RBAC) at every level: SysAdmin, Admin, User, and Read-Only, with further refinement at the team and project level. Administrative privileges are reduced and controlled on all assets, and separation of duties is enforced. Every access event — login, logout, failed login attempt, and permission change — is logged in the audit trail described in Chapter 3.
Single Sign-On & Identity Access Management
LabLynx One includes LabLynx OpenSocial, a SAML-based single sign-on (SSO) and identity access management (IAM) platform that integrates with institutional identity providers including Microsoft Active Directory, Okta, OneLogin, and Azure AD. For each organization using OpenSocial-based SSO, a dedicated instance is created and is manageable by the client's own administrator.
| Control | Implementation |
|---|---|
| Multi-Factor Authentication | Enforced on all privileged accounts; available for standard user accounts via SSO provider policy |
| Password Policy | Configurable complexity, history, and lockout controls; client-configurable session length and login banners |
| Access Reviews | Semi-annual review of access privileges across all information assets to confirm continued need |
| Offboarding | Access privileges revoked promptly upon employee or contractor separation, per documented offboarding procedures |
| Least Privilege | Granular permission assignment at user, group, project, and site levels; no default administrative access |
LabLynx One is configurable by clients to meet their own access control requirements, including password complexity, password history, session length, login banners, and user account change auditing — allowing institutions to align the system with their own internal security policy rather than a fixed vendor default.
Audit Trail & Data Integrity
Every action taken on an LabLynx One record is captured in an audit trail that cannot be modified or deleted by any user — including system administrators.
LabLynx One's audit trail operates at three levels:
- Field-level changelog: Every structured metadata field change captures the original value, the new value, the timestamp, and the authenticated user who made it.
- Body text revision history: Every save of a rich-text entry creates a versioned snapshot. Any two versions can be compared with a full diff view.
- Access event logging: Login events, failed authentication attempts, permission changes, and administrative actions are all logged with user identity and timestamp.
ALCOA+ Data Integrity Principles
LabLynx One's design supports the ALCOA+ data integrity principles that regulators expect of electronic records: data must be Attributable, Legible, Contemporaneous, Original, and Accurate, plus Complete, Consistent, Enduring, and Available. Every entry is attributed to an authenticated individual, time-stamped at the moment of creation, and preserved in its original form alongside a complete revision history.
| Part 11 Requirement | LabLynx One Control |
|---|---|
| §11.10(e) — Audit trail | System-generated, time-stamped at the server, records every create/modify/delete action, retained as a permanent part of the record |
| §11.10(d) — Limited access | Role-based access control at user, group, project, and site levels |
| §11.10(g) — Authority checks | Signing requires credential re-entry at the moment of signature; a user can only sign with their own credentials |
| §11.100 — Unique identification | Each user account is unique to one individual; no shared credentials |
The audit trail is available for review, export, and regulatory inspection in both human-readable (PDF) and machine-readable formats — including formatted PDF exports of a complete experiment with metadata, body text, protocol steps, attachment lists, and signature blocks, and ZIP exports for machine-readable submission.
Electronic Signatures & 21 CFR Part 11
LabLynx One offers three distinct attestation tools, each suited to a different level of legal and regulatory weight.
21 CFR Part 11-compliant e-signature requiring credential re-entry at the moment of signing. Displays the printed name of the signer, the date and time, and a mandatory, non-optional meaning of the signature per §11.50.
Trusted third-party timestamp authority stamping, providing independently verifiable proof that a record existed in a given state at a given time.
Ed25519 public-key signatures over a SHA-256 content hash, signed with the user's private key — independently verifiable non-repudiation distinct from credential re-entry alone.
Signature Workflow & Enforcement
A configurable multi-level signature workflow supports analyst, reviewer, and approver steps. The system enforces identity at the point of signature, not only at login: there is no mechanism for one user to sign with another user's credentials, and the active session alone is insufficient — credential re-entry is required every time.
| Requirement | Status |
|---|---|
| 21 CFR Part 11-compliant e-signatures | ✓ Native across LabLynx One |
| Multi-level signature workflow | ✓ Configurable analyst/reviewer/approver |
| Immutable audit trail | ✓ Full audit logging |
| Revision history with reason-for-change | ✓ Full revision history retained |
| Tamper-evident, time-stamped, non-repudiable records | ✓ RFC 3161 timestamping available |
NIST SP 800-53 & Virginia SEC530
LabLynx's primary security standard is NIST Special Publication 800-53 Revision 5, implemented through the Commonwealth of Virginia's ITRM Standard SEC530, and independently audited every year.
| Framework Element | Description |
|---|---|
| Base Standard | NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations |
| State Implementation | Virginia ITRM Standard SEC530-01.2 (effective June 17, 2025) — Commonwealth-specific implementation with COV enhancements |
| Audit Standard | Virginia ITRM Standard SEC502 — IT Security Audit Standard |
| NIST Foundation | NIST Cybersecurity Framework (CSF) 2.0 — Identify, Protect, Detect, Respond, Recover |
| Auditor | Trustnet, Inc. — independent, qualified IT security auditor; maintains full auditor independence per SEC502 |
| Audit Frequency | Annual — SEC530 mandates at least annual audit for sensitive IT systems |
Control Family Coverage
The annual Trustnet assessment covers all 20 NIST SP 800-53 control families. A representative sample:
Because SEC530 is a Virginia-specific implementation of NIST 800-53, LabLynx's annual audit covers Commonwealth-of-Virginia control enhancements that a generic NIST 800-53 audit alone would not require — meaning LabLynx's evidence base already exceeds what most vendor security questionnaires ask for.
Incident Response & Vulnerability Management
LabLynx maintains a formal Incident Response Plan and a layered, continuous monitoring program spanning both the application layer and the AWS infrastructure layer.
Incident Response Program
| Element | Detail |
|---|---|
| Incident Types Covered | Virus infections, hacker attempts, break-ins, unauthorized disclosure, service interruptions, breaches of personal information, and other security events |
| Threat Intelligence | The Incident Response Team subscribes to security industry alert services to monitor threats, vulnerabilities, and incidents in real time |
| Breach Response | DevOps serves as the central point of contact; a Priority Incident Request is opened and tracked through resolution upon verification |
| Client Notification | Clients receive help desk accounts with full ticket visibility via email; direct phone or email contact is used when urgency warrants |
| Annual Review | The IR plan is reviewed and tested annually, or after any material incident |
Continuous Monitoring & Vulnerability Management
| Control | Frequency |
|---|---|
| AlienVault USM vulnerability scanning — all systems | At least weekly |
| Asset inventory review | Every 30 days |
| AWS CloudTrail audit log review | Continuous / automated alerting |
| AWS GuardDuty threat detection | Continuous / automated alerting |
| Access privilege review | Semi-annually |
| Randomized phishing simulations | Periodic / randomized |
| Trustnet independent security audit | Annually |
Corrective Action Plan (CAP) Process
All Trustnet audit findings are tracked through a formal Corrective Action Plan process until complete remediation, with quarterly reporting to VDOA and CSRM per SEC530 requirements.
Data Retention, Privacy & PII/PHI
LabLynx maintains formal data governance policies covering retention, classification, and the handling of regulated personal data.
Data Retention
- LabLynx retains all client electronic data and records for a minimum of six years unless directed otherwise by the client.
- Clients may request adherence to their own internal data retention policies; LabLynx implements client-specified policies upon agreement.
- Non-production environments containing PII must never leave the hosted, protected network — developers may not copy databases or application files containing PII to local devices.
HIPAA & Protected Health Information
LabLynx is a Business Associate, not a Covered Entity, under HIPAA, and executes Business Associate Agreements with covered entities accordingly. PHI data hosted on behalf of LabLynx clients is managed under those BAA obligations, with appropriate security and privacy controls maintained on the client's behalf.
GDPR Alignment
LabLynx maintains data handling, encryption, and access control practices aligned with the EU General Data Protection Regulation for organizations processing the personal data of EU residents. A formal privacy policy governing data processing practices is maintained and available upon request.
LabLynx maintains 18 formal security policies — including Access Control, Data Management, Incident Response, Password Control, Log Management, and Disaster Recovery — reviewed and updated annually as part of the security program review cycle.
Validation Support — IQ/OQ/PQ
Laboratories operating under GxP requirements do not need to write their own validation documentation from scratch.
LabLynx One includes a complete IQ, OQ, and PQ validation documentation package — written, ready to execute, and available to every customer. Organizations operating in a GxP environment can deploy the LabLynx One GxP Validated Cloud, a dedicated tenancy with controlled release cycles, aligned to GAMP 5 guidance. Your team reviews, executes, and signs the pre-written documentation rather than authoring it independently.
| Capability | Status |
|---|---|
| IQ/OQ/PQ validation documentation package | ✓ Dedicated manual provided to every customer |
| Validation support for SaaS/cloud deployment | ✓ sciCloud.net GxP Validated Cloud |
| GAMP 5 risk-based validation alignment | ◐ Validation manual aligned to GxP practice |
| Controlled release cycle for validated tenancies | ✓ Dedicated GxP tenancy with managed releases |
The full IQ/OQ/PQ Validation Manual, including complete installation and operational qualification protocols, follows this guide as the next manual in this documentation library.
Accessibility Compliance
LabLynx One publishes a formal Voluntary Product Accessibility Template (VPAT) documenting conformance to WCAG 2.1 AA and Section 508.
| Criterion | Status |
|---|---|
| Published VPAT / Accessibility Conformance Report | ✓ VPAT 2.5 ACR published |
| WCAG 2.1 AA conformance | ◐ Partially Supports across most criteria |
| Section 508 conformance | ◐ Partially Supports |
| Keyboard-only navigation | ◐ Partially Supports; some drag-and-drop lacks keyboard equivalents |
| Screen reader compatibility | ◐ Partially Supports (NVDA/VoiceOver spot-tested) |
| 200% zoom / reflow support | ✓ Supports |
| Accessibility remediation roadmap | ✓ Prioritized roadmap published in the VPAT |
The complete LabLynx One VPAT 2.5 Accessibility Conformance Report, including the full criterion-by-criterion evaluation and remediation roadmap, is available on request from LabLynx sales for institutions with formal accessibility procurement requirements.
Vendor Risk Assessment — HECVAT
LabLynx supports the standard vendor security questionnaires used by academic institutions, healthcare systems, and enterprise procurement teams.
LabLynx has completed the Higher Education Community Vendor Assessment Toolkit (HECVAT) workbook — the industry-standard security questionnaire used by academic institutions to assess vendor security posture. A current, pre-filled HECVAT 4.1.5 response is maintained and available from LabLynx sales.
Laboratories and institutions requiring a completed HECVAT, SIG Lite, or custom security questionnaire as part of their vendor qualification process should contact LabLynx at sales@lablynx.com to request the current documentation.
| Assessment Type | LabLynx Support |
|---|---|
| HECVAT Full / HECVAT Lite | ✓ Pre-filled workbook maintained and available on request |
| SIG Lite | ✓ Available on request |
| Custom institutional security questionnaires | ✓ Supported via direct engagement with LabLynx security contact |
| NDA-protected audit evidence (Trustnet report) | ✓ Available to clients under NDA |
Certifications, Attestations & Roadmap
LabLynx treats security as an ongoing program rather than a point-in-time certification, with an active roadmap toward additional independent attestations.
| Certification / Standard | Current Status | Notes |
|---|---|---|
| NIST SP 800-53 / Virginia SEC530 | Active — Annual | Annual Trustnet audit; all 20 control families; results reported to VITA/CSRM |
| AWS SSAE 18 SOC 2 (infrastructure) | Active — AWS | Applies to AWS data center infrastructure; inherited by all sciCloud.net deployments |
| AWS SOC 3 (public attestation) | Active — AWS | Publicly available; covers Security, Availability, Confidentiality, and Privacy Trust Services Criteria |
| HIPAA Business Associate | Active | BAA executed with covered entities; PHI handling per LabLynx Business Associate policies |
| SOC 2 Type 2 | In Progress | Engagement with Saltmarsh CPAs (Pensacola, FL) is in process |
| ISO/IEC 27001:2022 | Roadmap | Targeted as a follow-on to SOC 2 Type 2 completion; supports international expansion requirements |
| FedRAMP | Future Roadmap | Aligned with government customer pipeline development; LabLynx hosts on FedRAMP-eligible AWS infrastructure |
For clients completing vendor security assessments, LabLynx's annual Trustnet audit against all 20 NIST SP 800-53 control families provides independent third-party evidence of the controls in place — the highest standard of independent verification LabLynx has achieved to date, conducted annually rather than as a one-time certification.
Our team supports vendor risk assessments, security questionnaires, NDA documentation requests, and security review calls. Contact sales@lablynx.com or support@lablynx.com, or call 866-522-5969 (866-LabLynx).
LabLynx One IQ/OQ/PQ Validation Manual
21 CFR Part 11 / GAMP 5 computer system validation protocols.
About This Manual
This manual provides the Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) protocols for LabLynx One, structured for 21 CFR Part 11 and GAMP 5 (Category 4) computer system validation.
Approval Signatures
| Role | Name / Title | Signature / Date |
|---|---|---|
| Validation Owner | [Name / Title] | [Signature / Date] |
| Quality Assurance | [Name / Title] | [Signature / Date] |
| System Owner / IT | [Name / Title] | [Signature / Date] |
| Department Head | [Name / Title] | [Signature / Date] |
| Regulatory Affairs (if applicable) | [Name / Title] | [Signature / Date] |
Revision History
| Version | Description | Author / Date |
|---|---|---|
| 1.0 | Initial release — Version-agnostic baseline protocol. | [Author] |
| [___] | [Description of change] | [Author] |
Distribution List
| Recipient | Copy Type |
|---|---|
| QA / Regulatory Affairs | Controlled Copy |
| Validation Owner | Controlled Copy |
| System Owner / IT | Controlled Copy |
| Department Head | Controlled Copy |
| Training Records Archive | Uncontrolled Reference Copy |
Validation Overview
Establishes the purpose, scope, regulatory basis, and risk-based testing rationale for validating LabLynx One as a GAMP 5 Category 4 configurable software system.
1.1 Purpose
This document establishes the Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) protocols for LabLynx One, an Electronic Laboratory Notebook (ELN) system delivered by LabLynx, Inc. The purpose of this validation is to provide documented evidence that LabLynx One has been correctly installed, operates as intended within its specified functional requirements, and performs reliably in the actual user environment — in full compliance with 21 CFR Part 11 requirements for electronic records and electronic signatures.
1.2 Scope
This validation covers LabLynx One as deployed in the following configurations:
- LabServer Deployment: On-premises installation on Ubuntu Server 24.04 LTS using Docker Engine and Docker Compose, as documented in the LabLynx One License, Technical Specifications & Installation Manual.
- sciCloud.net® Cloud Deployment: LabLynx-managed hosted deployment on the sciCloud.net® platform (AWS-based), where LabLynx is responsible for infrastructure qualification.
The validation covers all features and functions of LabLynx One that support electronic records and electronic signatures subject to 21 CFR Part 11, including: user authentication, access control, audit trail, electronic signatures, trusted timestamping, experiment management, template enforcement, resource management, and the administrative configuration required to maintain system integrity.
1.3 Regulatory Basis
| Regulation / Guidance | Relevance and Application |
|---|---|
| 21 CFR Part 11 | FDA regulation governing electronic records and electronic signatures. This is the primary regulatory driver for this validation. All critical controls tested in the OQ are mapped to specific Part 11 subsections. |
| GAMP 5 (2nd Edition) | Risk-based approach to computer system validation. LabLynx One is classified as GAMP 5 Category 4 (Configurable Software). This classification establishes the validation strategy: full IQ, OQ, and PQ with risk-proportionate test depth. |
| FDA Guidance — Part 11, ERR, ES (2003) | FDA's guidance document on the scope and application of 21 CFR Part 11. This document confirms that predicate rule records documented in LabLynx One must meet all Part 11 requirements. |
| FDA Guidance — Computerized Systems in Clinical Investigations (1999) | Applicable to any clinical investigation records maintained in LabLynx One. |
| ICH Q9 — Quality Risk Management | Provides the framework for the risk assessment used to prioritize OQ test depth. |
| ISO/IEC 62304 | Referenced for software lifecycle documentation (applicable if LabLynx One is used in a medical device quality system context). |
1.4 GAMP 5 Software Category Classification
LabLynx One is classified as GAMP 5 Category 4 — Configurable Software. Category 4 software is commercially available software that is configured by the customer (via templates, settings, user groups, workflows) but not custom-programmed. The implications for validation scope are:
- IQ: Verify the software is installed as specified, with the correct version and configuration.
- OQ: Verify all configured functions operate according to their specifications (full test coverage required per the instructions for this document).
- PQ: Verify the configured system performs correctly in actual use under representative real-world conditions.
- Supplier Audits: LabLynx is the supplier. The GAMP 5 framework recommends supplier assessment, which LabLynx supports through its SOC 2 compliance documentation, security policies, and technical support.
1.5 System Description
| Attribute | Value |
|---|---|
| System Name | LabLynx One Electronic Laboratory Notebook |
| Supplier | LabLynx, Inc., Pensacola, Florida, USA |
| Supplier Contact | support@lablynx.com │ www.lablynx.com |
| Underlying Platform | eLabFTW (open-source ELN, Deltablot SAS, AGPL-3.0) |
| System Version | [Record installed version: _____________________ ] |
| Deployment Model | LabServer (on-premises) and/or sciCloud.net® (cloud-managed) |
| Operating System (LabServer) | Ubuntu Server 24.04 LTS (64-bit x86_64) |
| Container Runtime (LabServer) | Docker Engine 27.x with Docker Compose plugin v2.x |
| Database | MySQL 8.4.x (containerized via Docker) |
| Web Server (inside container) | nginx 1.26.x + PHP-FPM 8.3.x |
| Primary URL | https://[your-lablynxone-domain.com] |
| Intended Use | Electronic laboratory notebook for creation, management, and electronic signing of scientific records subject to 21 CFR Part 11 controls. |
| GxP Impact | High — Records maintained in LabLynx One may directly support regulatory submissions, clinical investigations, GMP batch records, or GLP study records. |
1.6 Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Validation Owner | Responsible for the overall validation effort: planning, coordination, final sign-off, and maintenance. Typically a QA or Regulatory Affairs manager. |
| Test Executor(s) | Personnel who perform the IQ, OQ, and PQ test steps and record actual results. Must be trained on LabLynx One. Must sign and date each test record at execution. |
| QA Reviewer | Reviews and approves all test protocols and completed test records. Confirms pass/fail determinations are appropriate. Signs off on the Validation Summary Report. |
| System Owner / IT (LabServer) | Responsible for infrastructure qualification (server, OS, Docker). Executes and signs off on hardware/OS/infrastructure IQ steps. |
| LabLynx Support | Provides product specifications, release notes, and technical clarifications. Does not execute validation tests on behalf of the customer but may provide advisory support. |
| End Users | Participate in PQ scenario execution under the supervision of the Validation Owner and QA Reviewer. Represent real-world operating conditions. |
1.7 Risk Assessment and Test Depth Rationale
Per GAMP 5 and ICH Q9, the depth of testing is proportional to the risk of incorrect system function. The following risk classification drives test protocol depth in this document:
| Risk Level | Function Categories | Testing Approach |
|---|---|---|
| CRITICAL | Electronic signatures, audit trail, session authentication, access control, record integrity (lock/immutability), trusted timestamping. | Full step-by-step test scripts. Testing must confirm both the positive case (function works) and the negative case (attempt to circumvent fails). |
| HIGH | Experiment creation/management, template enforcement, metadata fields, file attachments, export functions, user/team management, notifications. | Full step-by-step test scripts. Positive-case testing required. |
| MEDIUM | Resource management, scheduler, tag management, search functions, batch actions, API authentication. | Full step-by-step test scripts. Representative test cases for each function type. |
| LOW | UI display preferences, non-compliance-affecting cosmetic settings, developer tools. | Not explicitly tested in OQ. Verified as part of PQ scenarios if encountered. |
1.8 Acceptance Criteria
The overall validation is considered successful when:
- All IQ test cases receive a Pass result, or all failures have documented deviations with approved CAPAs.
- All OQ test cases at CRITICAL or HIGH risk receive a Pass result, or all failures have documented deviations with approved CAPAs.
- All OQ test cases at MEDIUM risk receive a Pass result, or all failures have documented deviations.
- All PQ scenarios receive a Pass result, or all failures have documented deviations with approved CAPAs.
- The Validation Summary Report (Section 7) is reviewed by QA and signed by all required approvers.
1.9 Deviation Handling
If any test step produces an Actual Result that does not match the Expected Result, the following procedure applies:
- Record the actual result observed in the Actual Result column. Do not alter the Expected Result.
- Mark the test step as FAIL in the P/F column.
- Open a Deviation Record (Appendix D template) immediately. Assign a deviation number.
- Classify the deviation: Critical (prevents system use for GxP records), Major (affects primary function but has a workaround), or Minor (cosmetic, does not affect GxP record integrity).
- Initiate a CAPA if the deviation is Critical or Major. The CAPA must be approved by QA before retesting.
- After CAPA implementation, retest the failed step(s). Document the retest result on the Deviation Record.
- Include all deviations and their resolutions in the Validation Summary Report (Section 7).
System Configuration Baseline
Captures the approved hardware, software, and configuration baseline against which the installed system is qualified. Any subsequent change requires formal change control and revalidation assessment.
Complete this section at the time of validation execution. The values recorded here become the approved configuration baseline. Any subsequent change to these values requires a formal change control and re-validation assessment.
2.1 Hardware Baseline (LabServer Deployments)
| Hardware Component | Recorded Value |
|---|---|
| Server Make / Model | [ ] |
| CPU Architecture | x86_64 (64-bit) — Cores: [ ] Threads: [ ] |
| Total RAM Installed | [ ] GB |
| Operating System | Ubuntu Server 24.04 LTS (Noble Numbat) |
| OS Kernel Version | [Record: uname -r output: ________________________________ ] |
| Primary Data Disk Size | [ ] GB — Mount: /var/elabftw |
| Network Interface | IP Address: [ ] Hostname: [ ] |
| Server Location / Data Center | [ ] |
2.2 Software Baseline
| Software Component | Recorded Version |
|---|---|
| Docker Engine Version | [Record: docker version output: __________________________ ] |
| Docker Compose Plugin Version | [Record: docker compose version output: _________________ ] |
| LabLynx One Image Tag | [Record: docker inspect elabftw --format '{{.Config.Image}}': ______ ] |
| LabLynx One Image Digest (SHA256) | [Record: docker inspect elabftw --format '{{.Image}}': ________ ] |
| MySQL Image Tag | [Record: docker inspect mysql --format '{{.Config.Image}}': _______ ] |
| MySQL Image Digest (SHA256) | [Record: docker inspect mysql --format '{{.Image}}': ____________ ] |
| LabLynx One Application Version | [Record: curl -k https://localhost/api/v2/info | grep -i version: __ ] |
| PHP Version | [Record: docker exec elabftw php -r 'echo PHP_VERSION;': _________ ] |
| nginx Version | [Record: docker exec elabftw nginx -v: ___________________________ ] |
| MySQL Server Version | [Record: docker exec mysql mysql -u elabftw -p -e 'SELECT VERSION();': __ ] |
2.3 Configuration Parameter Baseline
| Configuration Parameter | Recorded Value |
|---|---|
| SITE_URL (docker-compose.yml) | [Record value: __________________________________________ ] |
| SERVER_NAME | [Record value: __________________________________________ ] |
| PHP_TIMEZONE / TZ | [Record value: __________________________________________ ] |
| ENABLE_LETSENCRYPT | true / false (circle one) |
| DISABLE_HTTPS | true / false (circle one) |
| PHP_MAX_CHILDREN | [Record value: _________ ] |
| MAX_PHP_MEMORY | [Record value: _________ ] |
| MAX_UPLOAD_SIZE | [Record value: _________ ] |
| USE_REDIS | true / false (circle one) |
| AUTO_DB_INIT | true / false (circle one) |
| AUTO_DB_UPDATE | true / false (circle one) |
| MFA Enforcement (Admin Panel) | Enabled / Disabled (circle one) |
| SSO / LDAP Configured | Yes / No (circle one) — Provider: [_________________ ] |
| RFC 3161 TSA Configured | Provider: [_______________] URL: [______________________ ] |
2.4 Interfaces Baseline
| Interface | Configuration Record |
|---|---|
| SMTP Email Server | Host: [_____________] Port: [____] TLS: Yes/No Auth: Yes/No |
| SSO / SAML Identity Provider | [Provider name / URL or N/A: __________________________ ] |
| LDAP Directory Server | [Host / Base DN or N/A: _________________________________ ] |
| RFC 3161 Timestamp Authority | [Provider / URL: _______________________________________ ] |
| ELab LIMS Integration | Yes / No — API endpoint: [__________________________ ] |
| REST API External Clients | [List active API integrations or 'None': _________________ ] |
Installation Qualification (IQ)
Verifies that LabLynx One has been correctly installed in the target environment and that all components match their approved specifications before Operational Qualification begins.
The Installation Qualification verifies that LabLynx One has been correctly installed in the target environment, that all components match their approved specifications, and that the system is ready for Operational Qualification testing. The IQ must be completed and approved before any OQ testing begins.
IQ-001 Host Operating System Verification
21 CFR Part 11 Reference: 21 CFR 11.10(a) — System controls to ensure record authenticity and integrity begin at the OS level.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Must be performed by IT/System Owner. Requires SSH or console access to the Ubuntu server. For sciCloud.net®, mark N/A and attach LabLynx IQ evidence. | ||||||
| 1 | Log in to the Ubuntu server via SSH or local console. | Successful login as authorized user. | ||||
| 2 | Execute: lsb_release -a | Output shows: Ubuntu 24.04.x LTS Noble Numbat 64-bit. | ||||
| 3 | Execute: uname -m | Output shows: x86_64 | ||||
| 4 | Execute: uname -r | Record the kernel version in Section 2.1. Version is 6.x.x or later. | ||||
| 5 | Execute: df -h /var/elabftw | Mount point /var/elabftw (or equivalent data volume) exists with sufficient free space (minimum 20 GB available). | ||||
| 6 | Execute: sudo systemctl status docker | Docker service status is 'active (running)'. Docker is enabled for boot: sudo systemctl is-enabled docker returns 'enabled'. |
IQ-002 Docker Engine Version Verification
21 CFR Part 11 Reference: 21 CFR 11.10(b) — Software must meet all applicable requirements to generate records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Confirm Docker was installed from the official Docker CE repository, not via snap. | ||||||
| 1 | Execute: docker version | Output shows Docker Engine version 27.x.x or later for both Client and Server. No error messages. | ||||
| 2 | Execute: docker compose version | Output shows Docker Compose version v2.x.x or later. | ||||
| 3 | Execute: docker info │ grep 'Storage Driver' | Output shows overlay2 as the storage driver (not vfs). | ||||
| 4 | Execute: which docker | Output shows /usr/bin/docker (not /snap/bin/docker). If snap path appears, Docker must be reinstalled from official repository. | ||||
| 5 | Execute: docker run --rm hello-world | Output includes 'Hello from Docker!' confirming container runtime is functional. |
IQ-003 Container Image Version Verification
21 CFR Part 11 Reference: 21 CFR 11.10(b) — All applicable software requirements must be met.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Both containers (elabftw and mysql) must be running before this test. Execute 'sudo docker compose -f /etc/elabftw.yml up -d' if not already running. | ||||||
| 1 | Execute: docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' | Output lists both 'elabftw' and 'mysql' containers as 'Up' with healthy status. | ||||
| 2 | Execute: docker inspect elabftw --format '{{.Config.Image}}' | Output shows the approved image tag (e.g., elabftw/elabimg:stable or pinned version). Record value in Section 2.2. | ||||
| 3 | Execute: docker inspect elabftw --format '{{.Image}}' | Output shows a SHA256 image digest. Record this value in Section 2.2 as the immutable image fingerprint. | ||||
| 4 | Execute: docker inspect mysql --format '{{.Config.Image}}' | Output shows mysql:8.4 or approved pinned version. Record in Section 2.2. | ||||
| 5 | Execute: docker inspect mysql --format '{{.Image}}' | Output shows a SHA256 digest. Record in Section 2.2. | ||||
| 6 | Execute: curl -k https://localhost/api/v2/info | Returns a JSON response including the LabLynx One application version. Record in Section 2.2. |
IQ-004 Data Persistence Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(c) — Computer-generated audit trails must be protected from modification or deletion.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: The /var/elabftw/web and /var/elabftw/mysql directories must exist on the host before running this test. | ||||||
| 1 | Execute: docker inspect elabftw --format '{{json .Mounts}}' │ python3 -m json.tool | Output shows two volume mounts: (1) host /var/elabftw/web mapped to container /elabftw/uploads; (2) host /var/elabftw/mysql mapped to container /var/lib/mysql. | ||||
| 2 | Execute: ls -la /var/elabftw/web | Directory exists and is owned by UID 101 (nginx user). Permissions are 750 or 755. | ||||
| 3 | Execute: ls -la /var/elabftw/mysql | Directory exists and contains MySQL data files. Not empty (indicating MySQL has initialized). | ||||
| 4 | Execute: docker exec elabftw stat /elabftw/uploads | Command returns file system information confirming the uploads directory is accessible inside the container. | ||||
| 5 | Execute: docker exec mysql ls /var/lib/mysql | Directory is accessible and contains MySQL database files. |
IQ-005 Network Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(d) — System access must be limited to authorized individuals.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Verify that the MySQL container is not exposed externally and that only port 443 (HTTPS) is exposed to the host network. | ||||||
| 1 | Execute: docker network ls | Output includes elabftw_elabftw-net (the internal bridge network). Record network name. | ||||
| 2 | Execute: docker network inspect elabftw_elabftw-net --format '{{range .Containers}}{{.Name}}{{end}}' | Output lists both 'elabftw' and 'mysql' as members of the internal network. | ||||
| 3 | Execute: docker ps --format '{{.Names}}\t{{.Ports}}' | 'elabftw' shows 0.0.0.0:443->443/tcp (or 127.0.0.1:443). 'mysql' shows NO external port mapping (only internal 3306/tcp exposed). | ||||
| 4 | From an external client (not the server), attempt: curl -k https://[SERVER_IP]/api/v2/info | Returns HTTP 200 with JSON content. The LabLynx One application is accessible over HTTPS. | ||||
| 5 | From an external client (not the server), attempt TCP connection to port 3306: nc -zv [SERVER_IP] 3306 | Connection is refused or times out. MySQL port is NOT accessible from outside the server. |
IQ-006 TLS Certificate Verification
21 CFR Part 11 Reference: 21 CFR 11.10(d) — Access controls; 21 CFR 11.30 — Open networks require encryption.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: TLS (HTTPS) must be operational before any electronic records are created. This test verifies the certificate is valid, not expired, and matches the configured server name. | ||||||
| 1 | Execute: echo │ openssl s_client -connect [SERVER_NAME]:443 -servername [SERVER_NAME] 2>/dev/null │ openssl x509 -noout -subject -dates | Output shows: subject with CN=[SERVER_NAME]; notBefore and notAfter dates. notAfter must be a future date (at least 30 days from now). | ||||
| 2 | Navigate to https://[SERVER_NAME] in a browser (Chrome or Firefox). | Browser shows a secure padlock icon. No certificate warning is displayed. The address bar shows https:// protocol. | ||||
| 3 | Execute: curl -I https://[SERVER_NAME]/ | Response headers include: HTTP/2 200, Strict-Transport-Security header present. | ||||
| 4 | Attempt to navigate to http://[SERVER_NAME]/ (HTTP, not HTTPS). | Browser is redirected to HTTPS, or connection is refused. Plain HTTP access to application data is not permitted. | ||||
| 5 | Execute: echo │ openssl s_client -connect [SERVER_NAME]:443 2>/dev/null │ grep 'Protocol' | Protocol shows TLSv1.2 or TLSv1.3 only. Protocols TLSv1.0 and TLSv1.1 must NOT appear. |
IQ-007 Database Initialization and Schema Verification
21 CFR Part 11 Reference: 21 CFR 11.10(a) — Validation to ensure accuracy, reliability, consistent intended performance.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: The database must have been initialized via 'docker exec elabftw bin/init db:install' before this test. | ||||||
| 1 | Execute: docker exec mysql mysql --user=elabftw --password=[DB_PASSWORD] elabftw --execute='SHOW TABLES;' | Output lists LabLynx One database tables (experiments, items, users, audit_logs, etc.). No empty result. Record number of tables displayed: [____] | ||||
| 2 | Execute: docker exec mysql mysql --user=elabftw --password=[DB_PASSWORD] elabftw --execute='SELECT COUNT(*) FROM config;' | Returns a count greater than 0, confirming the configuration table is populated. | ||||
| 3 | Execute: docker exec elabftw bin/console db:update | Command completes without error. Output confirms the database schema is current for the installed version, or reports the migrations it applied. | ||||
| 4 | Execute: curl -k https://localhost/healthcheck.php | Returns HTTP 200 with body 'ok', confirming nginx, php-fpm, and the MySQL connection are all healthy. |
IQ-008 Application Accessibility Verification
21 CFR Part 11 Reference: 21 CFR 11.10(b) — Software must generate accurate and complete records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Open a supported browser (Chrome 120+ or Firefox 120+). Navigate to the LabLynx One instance URL. | ||||||
| 1 | Navigate to https://[SERVER_NAME]/ | The LabLynx One login page loads completely. The LabLynx One branding is visible. No error messages or broken elements. | ||||
| 2 | Navigate to https://[SERVER_NAME]/api/v2/info | Returns a JSON response containing the LabLynx One version string and other system information. HTTP status code 200. | ||||
| 3 | Attempt to navigate to https://[SERVER_NAME]/api/v2/experiments without an API key. | Returns HTTP status 401 (Unauthorized). The API does not grant access without authentication. | ||||
| 4 | Navigate to https://[SERVER_NAME]/app/logout.php | Redirects to the login page without error. Session termination is handled gracefully. |
IQ-009 Email Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(b) — Supporting features (notifications) must function as specified.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: SysAdmin account required. Log in to LabLynx One as SysAdmin before running this test. | ||||||
| 1 | Log in as SysAdmin. Navigate to User Avatar → Sysconfig → Email tab. | The Email configuration page loads. SMTP settings (host, port, from address, authentication) are populated with the approved values from Section 2.4. | ||||
| 2 | Click the 'Send test email' button. Provide a valid recipient email address. | A test email is received at the specified address within 5 minutes. Subject line contains 'LabLynx One' or similar identifier. | ||||
| 3 | Verify email content. | The test email body confirms the sender is the configured from-address. No SMTP authentication errors appear in the system logs. |
IQ-010 Backup System Verification
21 CFR Part 11 Reference: 21 CFR 11.10(c) — Protection of records to enable accurate and ready retrieval throughout records retention period.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A backup procedure must have been configured per the Installation Manual before this test. For sciCloud.net®, LabLynx performs backup verification; attach LabLynx backup attestation and mark this test N/A. | ||||||
| 1 | Execute the configured backup command (e.g., sudo elabctl backup (or sudo /usr/local/bin/elab-backup.sh if using the manual script from Chapter 8.2)). | Backup completes without error. Backup output or log confirms: (a) database dump was created; (b) uploads directory was copied. | ||||
| 2 | Navigate to the backup destination directory. Verify the following files exist: database dump file (.sql.gz or equivalent); uploads backup (directory or archive); a separately-stored copy of /etc/elabftw.yml (not included in elabctl backup by design — see Chapter 8.2). | All three backup elements are present, timestamped with today's date, and non-zero in size. | ||||
| 3 | Verify the scheduled backup task (cron job or systemd timer) is active. | Execute: crontab -l or cat /etc/cron.d/elab* shows an active scheduled backup task. Backup is scheduled to run at a defined interval (minimum daily). |
IQ-011 Log Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(e) — Audit trails must be generated and retained.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Verify that container logs are configured with appropriate retention and that LabLynx One application logs are accessible. | ||||||
| 1 | Execute: cat /etc/docker/daemon.json | File contains log-driver: json-file with max-size and max-file settings. Log rotation is configured. | ||||
| 2 | Execute: sudo docker logs elabftw --tail 20 | Returns the most recent nginx and PHP-FPM log entries without error. | ||||
| 3 | Execute: sudo docker logs mysql --tail 20 | Returns the most recent MySQL log entries without error. No critical error messages visible. | ||||
| 4 | Verify logrotate is configured: cat /etc/logrotate.d/docker-elabftw | Logrotate configuration file exists with rotate, daily, and compress settings. |
IQ-012 Security Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(d) — Limiting system access to authorized individuals; 21 CFR 11.300 — Controls for identification codes/passwords.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Verify host-level security hardening has been applied per the Installation Manual (Security Hardening chapter). | ||||||
| 1 | Execute: sudo ufw status verbose | ufw is active. Rules show: port 22 (SSH), 443 (HTTPS), and optionally 80 (HTTP) are allowed. No unnecessary ports are open. | ||||
| 2 | Execute: sudo systemctl status fail2ban | fail2ban service is 'active (running)'. Execute: sudo fail2ban-client status. Shows active jails including sshd. | ||||
| 3 | Execute: sudo systemctl status unattended-upgrades | Service is active (running) or enabled. Automatic security updates are configured. | ||||
| 4 | Execute: ls -la /etc/elabftw.yml | File permissions are 600 (owner read/write only). File is owned by root. | ||||
| 5 | Verify SSH key authentication is required: cat /etc/ssh/sshd_config │ grep PasswordAuthentication | PasswordAuthentication is set to 'no'. PermitRootLogin is 'no'. |
IQ-013 SysAdmin Account and Initial Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(d) — System access limited to authorized individuals; 21 CFR 11.300 — Identification codes/passwords.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Log in to LabLynx One as SysAdmin. The first account created on a fresh installation automatically receives SysAdmin privileges. | ||||||
| 1 | Navigate to https://[SERVER_NAME]/. Attempt to access the login page. | Login page is displayed. No error messages. | ||||
| 2 | Log in with SysAdmin credentials (email + password). | Login is successful. User is redirected to the LabLynx One dashboard. The username/email is displayed in the top-right corner. | ||||
| 3 | Navigate to User Avatar → Sysconfig. | The Sysconfig panel opens successfully. All configuration tabs (Users, Teams, Email, Security, Authentication, Timestamping, API) are visible. | ||||
| 4 | Navigate to Sysconfig → Security. Verify the password policy settings match the organization's approved policy. | Password minimum length and complexity settings reflect the organization's approved security policy. | ||||
| 5 | Navigate to Sysconfig → Users. Confirm that only authorized accounts exist (no unexpected accounts). | User list contains only expected, authorized accounts. |
IQ-014 IQ Summary and Release for OQ
21 CFR Part 11 Reference:
| IQ Summary Item | Recorded Value |
|---|---|
| Total IQ Tests | 14 |
| Tests Passed | [Record: _____ ] |
| Tests Failed | [Record: _____ ] |
| Tests Not Applicable (N/A) | [Record: _____ ] — (List N/A IDs: ___________________ ) |
| Open Deviations | [Record: _____ ] — (List Deviation IDs: __________________ ) |
| IQ Overall Result | PASS / FAIL / CONDITIONAL PASS (circle one) |
| Conditional Pass Conditions | [Describe any conditions required before OQ commencement: ______________ ] |
| Role | Name | IQ Approval Signature / Date |
|---|---|---|
| Validation Owner | [Name / Title] | [Signature / Date] |
| QA Reviewer | [Name / Title] | [Signature / Date] |
Operational Qualification (OQ)
Verifies that every configured function of LabLynx One operates according to its specification, with test depth proportional to GAMP 5 risk classification.
The Operational Qualification verifies that LabLynx One operates according to its functional specifications across all system functions. Each test protocol below documents exact procedural steps, expected results, and record fields for actual results, pass/fail determination, tester initials, and execution date.
OQ Prerequisites: (1) IQ is complete and approved. (2) At least two test user accounts exist with different roles (regular User and Admin). (3) At least one team is configured. (4) Test browsers are supported versions (Chrome 120+ or Firefox 120+). (5) A test experiment template with at least 3 metadata fields and 3 steps (including 1 locked step) has been created by the Admin.
4.4 Authentication and Access Control [CRITICAL — 21 CFR 11.10(d), 11.300]
OQ-AC-001 Local Authentication — Valid Credentials
21 CFR Part 11 Reference: 21 CFR 11.10(d): Limit system access to authorized individuals; 21 CFR 11.300(a): Unique identifiers.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use a test account with a known valid password. Ensure the account is active and validated. | ||||||
| 1 | Navigate to https://[SERVER_NAME]/. Observe the login page. | The login page displays fields for Email and Password. A company/LabLynx logo is visible. No authenticated content is visible without login. | ||||
| 2 | Enter the valid test user email and correct password. Click Sign In. | Login succeeds. User is redirected to their LabLynx One dashboard. The user's name appears in the top-right navigation. No error messages are displayed. | ||||
| 3 | Observe the browser URL bar after successful login. | URL contains /experiments or similar authenticated path. No session token is visible in the URL (tokens are handled via HTTP cookies, not URL parameters). | ||||
| 4 | Log out by clicking User Avatar → Sign Out. | User is redirected to the login page. The session is terminated. | ||||
| 5 | Attempt to navigate directly to https://[SERVER_NAME]/app/experiments.php (a protected page) after logout. | User is redirected back to the login page. Unauthenticated access to protected pages is not permitted. |
OQ-AC-002 Authentication — Invalid Credentials and Account Lockout
21 CFR Part 11 Reference: 21 CFR 11.300(c): Use of appropriate controls (e.g., password or token systems) to limit unauthorized access.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use a test account. Note: this test will lock the account temporarily. Have the SysAdmin password available to unlock if needed. | ||||||
| 1 | Navigate to the login page. Enter the test user email with an incorrect password. Click Sign In. | Login fails. An error message is displayed (e.g., 'Invalid credentials'). No information about whether the account exists is leaked. | ||||
| 2 | Repeat the incorrect password entry 5 consecutive times (or the configured lockout threshold from Section 2.3). | After the configured number of failures, the account is temporarily locked. A message or behavior change confirms the lockout. | ||||
| 3 | Wait the configured lockout duration (e.g., 15 minutes as configured in fail2ban). Attempt login with the correct password. | Login succeeds after the lockout period expires, confirming lockout is temporary rather than permanent. | ||||
| 4 | As SysAdmin, verify login attempt events are recorded. Navigate to Sysconfig → Audit Logs and filter for authentication events. | Failed login attempts appear in the system audit log with timestamp and IP address. Successful login after unlock also appears. |
OQ-AC-003 Multi-Factor Authentication (MFA) Enforcement
21 CFR Part 11 Reference: 21 CFR 11.300(b),(d): Operational checks to ensure valid users; two-factor controls.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: MFA must be configured for the test account before running this test. Admin Panel → Team tab → Force MFA must be enabled, or the test user must have voluntarily enrolled. Use an authenticator app (Google Authenticator, Authy, Aegis, or equivalent). | ||||||
| 1 | Navigate to the login page. Enter the MFA-enrolled test user email and correct password. Click Sign In. | After password validation, the system presents a second challenge: a prompt for the 6-digit MFA code. | ||||
| 2 | Enter an incorrect 6-digit code (e.g., 000000). Click Verify. | Authentication fails. Error message indicates the code is invalid. The user remains on the MFA challenge page. | ||||
| 3 | Open the authenticator app. Retrieve the current 6-digit TOTP code for the enrolled account. Enter it in the MFA challenge prompt. | Authentication succeeds. User is redirected to their dashboard. | ||||
| 4 | Verify the MFA event appears in the system audit log. As SysAdmin, navigate to Sysconfig → Audit Logs. | Successful MFA authentication event is recorded with timestamp, user identity, and IP address. |
OQ-AC-004 Session Timeout Enforcement
21 CFR Part 11 Reference: 21 CFR 11.10(d): Time-limited access; session controls.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Configure a short session timeout (e.g., 5 minutes) temporarily in the SysAdmin panel for testing purposes. Restore the production value after the test. | ||||||
| 1 | Log in as a test user. Note the login time. | Successful login. Record start time: [ ] | ||||
| 2 | Leave the browser idle (do not perform any actions) for the duration of the configured session timeout period. | [Wait configured timeout + 2 minutes] | ||||
| 3 | After the timeout period has elapsed, attempt to perform an action (e.g., click Experiments in the navigation bar). | User is redirected to the login page. The session has expired. A message may indicate the session timed out. | ||||
| 4 | Verify that no data entered before the timeout is accessible without re-authentication. | Login page is presented. No LabLynx One content is accessible without fresh authentication. |
OQ-AC-005 Role-Based Access Control — User Cannot Access Admin Panel
21 CFR Part 11 Reference: 21 CFR 11.10(d): System access limited to authorized individuals only.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Log in as a standard User (not Admin, not SysAdmin) for this test. | ||||||
| 1 | Log in as a standard User. Click the User Avatar (top right). | The dropdown menu does NOT display 'Admin Panel' or 'Sysconfig' options. Only personal settings options are visible. | ||||
| 2 | Attempt to navigate directly to the Admin Panel URL: https://[SERVER_NAME]/app/admin.php | Access is denied. User receives an error page or is redirected. The Admin Panel content is NOT displayed. | ||||
| 3 | Attempt to navigate directly to the SysAdmin URL: https://[SERVER_NAME]/app/sysconfig.php | Access is denied. User receives an error page or is redirected. The SysAdmin content is NOT displayed. | ||||
| 4 | As the User, attempt to create a new experiment category (a function reserved for Admins). | The option to create a new category is not available in the User's interface. No unauthorized category creation is possible. |
OQ-AC-006 Permission Model — Private Experiment Not Visible to Other Users
21 CFR Part 11 Reference: 21 CFR 11.10(d): Access controls to protect records from unauthorized access.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Two test user accounts (User A and User B) in the same team are required. Both must be logged in on separate browser sessions. | ||||||
| 1 | Log in as User A. Create a new experiment titled 'AC-006 Private Test — Do Not Share'. Set visibility to 'Only Me (Private)'. Save. | ‘Only Me’ visibility setting is accepted. Experiment is saved and visible to User A. | ||||
| 2 | As User A, note the experiment's ELabID and URL from the browser address bar. | Record ELabID: [____________________] URL: [_________________________] | ||||
| 3 | In a separate browser (or incognito window), log in as User B. Navigate to Experiments index. Search for the experiment title 'AC-006 Private Test — Do Not Share'. | ‘Only Me’ experiment does NOT appear in User B's search results. | ||||
| 4 | As User B, attempt to navigate directly to the experiment URL noted in Step 2. | Access is denied. User B receives a 403 Forbidden error or is redirected to the experiments index. The experiment content is NOT displayed. | ||||
| 5 | As User A, change the experiment's visibility to 'My Team'. As User B, refresh the experiments index and search again. | The experiment is now visible to User B in the index. |
OQ-AC-007 Account Deactivation — Immediate Access Revocation
21 CFR Part 11 Reference: 21 CFR 11.10(d): Limit access to currently authorized individuals; deactivation controls.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A test account to be deactivated and an active SysAdmin account are required. Ensure the test account data has been backed up or ownership transferred before deactivation. | ||||||
| 1 | Log in as the SysAdmin. Navigate to Sysconfig → Users. Locate the test account. Set the account's validity expiry date to yesterday's date (or set the account to Inactive). Save. | Account is marked as expired/inactive in the Users list. | ||||
| 2 | In a separate browser, attempt to log in with the deactivated test account credentials. | Login fails immediately. An error message indicates the account is not active or access is denied. The user is NOT granted any access. | ||||
| 3 | Confirm any active session from the deactivated account (if one existed before deactivation) is also terminated. Refresh the browser for the deactivated user if a session was open. | Existing session shows an authentication error or the user is redirected to the login page. | ||||
| 4 | As SysAdmin, verify the deactivation event is recorded in the audit log. | Sysconfig → Audit Logs shows the account modification event with timestamp and SysAdmin identity. |
4.5 Experiment Management [HIGH]
OQ-EX-001 Experiment Creation — From Template
21 CFR Part 11 Reference: 21 CFR 11.10(b): Software meets all applicable requirements for generating records accurately and completely.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A test template with at least 3 metadata fields and 3 steps (one locked) must exist. Log in as a regular User. | ||||||
| 1 | Navigate to Experiments → Create. Select the test template from the template dropdown. Click Create. | New experiment is created. The experiment opens in edit mode. The body text, metadata fields, and steps from the template are pre-populated. | ||||
| 2 | Observe the metadata fields. | All metadata fields from the template are present: correct names, correct field types (text, number, date, select, etc.), and any default values. | ||||
| 3 | Observe the Steps checklist. | All steps from the template are present in the correct order. The locked step has a lock icon and is not editable. | ||||
| 4 | Attempt to edit the locked step's description text (click on it and try to type). | The locked step text is read-only. No modification is accepted. | ||||
| 5 | Enter a title: 'OQ-EX-001 Template Test'. Fill in at least one metadata field. Click Save. | Experiment is saved. No error messages. The experiment appears in the Experiments index. |
OQ-EX-002 Experiment Category and Status Assignment
21 CFR Part 11 Reference: 21 CFR 11.10(b): Records must reflect correct classification information.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Open experiment OQ-EX-001 from the previous test, or create a new blank experiment. | ||||||
| 1 | In edit mode, locate the Category field. Select a category from the dropdown. | Category is assigned. The category label appears with its configured color in the experiment header. | ||||
| 2 | Locate the Status field. Change the status from the default ('Running' or configured default) to a different status. | Status is updated. The new status label appears with its configured color. | ||||
| 3 | Save the experiment. Navigate back to the Experiments index. | The experiment appears in the index with the correct category color badge and status label. | ||||
| 4 | In the index, filter by the category assigned in Step 1. | Only experiments of that category are shown. The test experiment is visible in the filtered list. | ||||
| 5 | Filter by the status assigned in Step 2. | Only experiments with that status are shown. The test experiment is visible. |
OQ-EX-003 Custom Metadata Fields — All Field Types
21 CFR Part 11 Reference: 21 CFR 11.10(b): Records must accurately capture all required data elements.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Create a new blank experiment. Use the Admin-configured test template that has at least one field of each type: text, number, date, select/dropdown, checkbox. | ||||||
| 1 | In the metadata section, locate the Text field. Type: 'Test Analyst JR'. Click Save. | Text field value 'Test Analyst JR' is saved and displayed correctly on the next page load. | ||||
| 2 | Locate the Number field (with units). Enter: 99.3. Select unit 'mg/mL'. Click Save. | Number value 99.3 and unit mg/mL are saved and displayed correctly. | ||||
| 3 | Locate the Date field. Use the date picker to select today's date. Click Save. | Today's date is saved and displayed in YYYY-MM-DD format. | ||||
| 4 | Locate the Select (dropdown) field. Select an option (e.g., 'Pass'). Click Save. | The selected option is saved and displayed correctly. | ||||
| 5 | Locate the Checkbox field. Click it to check it. Click Save. | Checkbox is shown as checked/enabled after save. | ||||
| 6 | Switch to View mode. Verify all field values are displayed correctly. | All metadata field values entered in steps 1–5 are visible in view mode with correct labels and values. | ||||
| 7 | Clear the Number field entirely and click Save. | Empty numeric field is accepted without causing an application error. |
OQ-EX-004 Experiment Steps — Completion with Timestamp Attribution
21 CFR Part 11 Reference: 21 CFR 11.10(e): Audit trails must include date/time stamps and user identification for all steps.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Open the experiment created in OQ-EX-001. The experiment must have at least one unlocked step. | ||||||
| 1 | In edit mode, locate the Steps checklist. Note the current state of an unlocked step (unchecked). | Unchecked step is visible with a checkbox on the left. | ||||
| 2 | Click the checkbox on an unlocked step. | The step is immediately marked as complete. A timestamp and the current user's name/initials appear next to the step completion. The next incomplete step advances. | ||||
| 3 | Switch to View mode. Observe the completed step. | Completed step shows a check mark, the user's name (or initials), and the exact date and time of completion. | ||||
| 4 | Navigate to the Experiments index. Observe the experiment row. | The experiment row shows the next incomplete step (if any remain) as a reminder in the Next Step column. | ||||
| 5 | Navigate to the To-Do List (top-left navigation icon). | The To-Do list shows remaining incomplete steps for this experiment and all other open experiments owned by the current user. |
OQ-EX-005 File Attachment Upload and Retrieval
21 CFR Part 11 Reference: 21 CFR 11.10(b): Records must include all required supporting data; original data retention.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Prepare a test file for upload (e.g., a small PDF or text file named 'OQ-EX-005-testfile.pdf'). | ||||||
| 1 | Open a test experiment in edit mode. Locate the Attachments section. Drag the test file onto the upload area (or click Browse and select it). | File upload progress is displayed. After completion, the file appears in the Attachments panel with its name, size, upload timestamp, and uploader identity. | ||||
| 2 | Switch to View mode. Observe the attachment entry. | File is listed in the Attachments panel with: filename, file size, upload date and time, and the name of the user who uploaded it. | ||||
| 3 | Click on the attachment to download it. | File downloads correctly. The downloaded file is identical to the original uploaded file (not corrupted, not renamed). | ||||
| 4 | Attempt to upload a second file with the same name. | System either renames the new file to avoid collision, or appends a version indicator. Original file is preserved. | ||||
| 5 | Attempt to delete an attachment on an unlocked experiment. Click the delete icon on the attachment. | Attachment is removed from the entry. A confirmation prompt may appear before deletion. After deletion, the file no longer appears. |
OQ-EX-006 Experiment-to-Resource Linking — Bidirectionality
21 CFR Part 11 Reference: 21 CFR 11.10(b): Records must accurately identify all related materials used.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A Resource record (e.g., a reagent or instrument entry) must exist in the system before this test. Note its ID and title. | ||||||
| 1 | Open a test experiment in edit mode. In the body editor, type # followed by the first 3 characters of the resource name. | An autocomplete dropdown appears showing matching resource entries. | ||||
| 2 | Select the resource from the autocomplete list. | The resource is added to the Linked Resources panel on the left/bottom of the experiment. A hyperlink to the resource is inserted in the body text. | ||||
| 3 | Save the experiment. Switch to View mode. Click the link to the resource in the body text. | Browser navigates to the Resource record. | ||||
| 4 | On the Resource record page, navigate to the 'Linked Experiments' or 'Related' section. | The experiment that was linked in Step 2 appears in the Resource's linked entries list. The link is bidirectional. | ||||
| 5 | From the Resource's linked entry panel, click the link back to the experiment. | Browser navigates back to the experiment. Round-trip bidirectional navigation is confirmed. |
OQ-EX-007 Experiment Locking — Prevents Further Modification
21 CFR Part 11 Reference: 21 CFR 11.10(c): After the fact alteration of records must be prevented.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use a test experiment that is ready for locking (all metadata filled, steps completed). Log in as the experiment owner. | ||||||
| 1 | Open the test experiment. Click the Lock icon in the toolbar. Confirm the lock action when prompted. | Experiment is locked. A lock icon appears in the experiment header and in the index list view. The lock event is recorded in the Changelog. | ||||
| 2 | Attempt to edit the experiment: click Edit mode and try to modify the title. | Edit mode is not accessible. The experiment is read-only. No modification options are available. | ||||
| 3 | Attempt to add an attachment to the locked experiment. | File upload is rejected. No new attachments can be added to a locked experiment. | ||||
| 4 | Attempt to add a new tag to the locked experiment. | Tag addition is rejected. No new tags can be applied to a locked experiment. | ||||
| 5 | As an Admin (a different user than the owner), navigate to the locked experiment. Attempt to unlock it via the Unlock button in the toolbar. | Admin can unlock the experiment. After unlocking, edit mode becomes accessible again. The unlock event is recorded in the Changelog. | ||||
| 6 | Re-lock the experiment as the Admin. | Experiment is locked again. Lock event recorded in Changelog. |
OQ-EX-008 Experiment Soft Delete and Recovery
21 CFR Part 11 Reference: 21 CFR 11.10(c): Records must be protected from accidental or unauthorized destruction.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Create a dedicated test experiment titled 'OQ-EX-008 Soft Delete Test' for this test. | ||||||
| 1 | Open the test experiment. Navigate to the Ellipsis (…) menu. Click Delete. Confirm the deletion when prompted. | The experiment is removed from the default Experiments index view. It is no longer visible in the normal list. | ||||
| 2 | In the Experiments index, use the State filter to select 'Deleted' or 'Archived' state. | The deleted experiment reappears in the filtered view with 'Deleted' status. The experiment content is fully intact. | ||||
| 3 | Click on the deleted experiment. Verify all content (title, body, metadata, attachments) is intact. | All original content is preserved. The experiment is accessible and readable. | ||||
| 4 | Click Restore (or equivalent) on the deleted experiment. | Experiment is restored to the active index. It is visible again in the default view with its original status. | ||||
| 5 | As SysAdmin, verify that true permanent deletion requires SysAdmin action and cannot be performed by regular users. | Regular User does not see a 'Permanently Delete' option. Only SysAdmin-level actions can perform true permanent deletion (if configured). |
OQ-EX-009 Full-Text Search Functionality
21 CFR Part 11 Reference: 21 CFR 11.10(e): Records must be available for ready retrieval throughout the retention period.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Create a test experiment with a unique term in both the body text and a metadata field. Use a term unlikely to appear in other records (e.g., 'XQZTEST2026UNIQUE'). | ||||||
| 1 | Create an experiment. In the body, type: 'XQZTEST2026UNIQUE is documented here.' In a Text metadata field, enter: 'XQZTEST2026META'. Save. | ‘Experiment is created with the unique terms in both body and metadata. | ||||
| 2 | In the search bar, type: XQZTEST2026UNIQUE and press Enter. | Search results include the test experiment, found by its body text content. | ||||
| 3 | In the search bar, type: XQZTEST2026META and press Enter. | Search results include the test experiment, found by its metadata field content. | ||||
| 4 | Search for a non-existent term: ZZZNORESULT99999. | Search returns zero results. No error message. The empty result state is displayed clearly. |
OQ-EX-010 Experiment PDF Export — Content Completeness
21 CFR Part 11 Reference: 21 CFR 11.10(b): Records must be complete and accurate.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use a fully populated test experiment (title, date, status, tags, at least 2 metadata fields, body text, 1 completed step, 1 comment, 1 attachment). Note the ELabID of this experiment. | ||||||
| 1 | Open the test experiment in view mode. Click the Export button in the toolbar. Select PDF format. Click Export. | ‘PDF download begins. The file is downloaded to the local machine. | ||||
| 2 | Open the downloaded PDF. Verify the PDF contains the experiment title. | Experiment title is present at the top of the PDF. | ||||
| 3 | Verify the PDF contains the date, status, category, and tags. | All classification fields are present and correct. | ||||
| 4 | Verify the PDF contains all metadata fields and their values. | All metadata field names and values entered in the experiment are present in the PDF. | ||||
| 5 | Verify the PDF contains the body text (main narrative). | Body text content is rendered in the PDF, including any headings, tables, and images that were in the body. | ||||
| 6 | Verify the PDF contains the completed step with its timestamp and tester identity. | Completed step is listed with the correct completion timestamp and tester name. | ||||
| 7 | Verify the ELabID appears in the PDF (typically in the footer). | ELabID is present in the PDF footer or header for cross-referencing. |
4.6 Electronic Signatures [CRITICAL — 21 CFR Part 11 Subpart C: §11.50, §11.70, §11.100, §11.200, §11.300]
OQ-SIG-001 Simple Electronic Signature — Authenticated Signing Event
21 CFR Part 11 Reference: 21 CFR 11.50(a), 11.70, 11.200(a)(1) — Non-biometric e-signatures require user ID and password.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use a fully written test experiment in an unlocked state. Log in as the experiment owner (User A). | ||||||
| 1 | Open the test experiment in view mode. Click the Signature button in the toolbar. The signature dialog opens. | Signature dialog is displayed. Options are presented for signature type and meaning. | ||||
| 2 | Observe: the dialog requires credential re-entry before signing. Enter User A's password when prompted. | Signing cannot proceed without credential re-entry. The system requires active re-authentication at the point of signing. | ||||
| 3 | Enter the correct password. Select signature meaning (e.g., 'I certify this record is accurate and complete'). Click Sign. | Signature is recorded. A signature block appears in the experiment record showing: (a) the signer's full name, (b) the date and time of signing, (c) the meaning of the signature. | ||||
| 4 | Verify the signature block is appended to the experiment record and visible in view mode. | Signature block is visible with all three required 21 CFR 11.50(a) elements: name, date/time, meaning. | ||||
| 5 | Attempt to remove the signature block by editing the experiment body. | The signature block cannot be deleted from the body by editing. It is rendered as a protected, immutable element. | ||||
| 6 | As a different user (User B), attempt to sign the experiment as if they were User A (use User B's session, enter User B's credentials). | The signature records User B's identity, not User A's. The system does not allow one user to sign as another. |
OQ-SIG-002 Electronic Signature — Linking to Record (Cannot Be Detached or Falsified)
21 CFR Part 11 Reference: 21 CFR 11.70: Electronic signatures must be linked to their respective electronic records so as to preclude the transfer or falsification of the signature.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use the experiment that was signed in OQ-SIG-001. | ||||||
| 1 | Open the signed experiment. Observe the signature block. Note the exact text of the signature (name, date/time, meaning). | Signature block is present and displays all required fields. | ||||
| 2 | Unlock the experiment (as Admin). Edit the body text of the experiment. Add additional text after the signature block. Save and re-lock. | Body edit is saved. However, the signature block from OQ-SIG-001 remains and is clearly attributed to the original signing event. The Changelog records the body edit as a new revision, distinct from the signature event. | ||||
| 3 | Navigate to Ellipsis (…) → See Revisions. Compare the pre-edit and post-edit versions. | Revision history shows the original version (as it was when signed) and the post-edit version as distinct entries. The audit trail clearly shows the record was modified after signing. | ||||
| 4 | Export the experiment as a ZIP archive. Inspect the archive contents. | ZIP archive contains: the experiment PDF, a JSON data export, and (if Ed25519 signing was used) the signature archive files. The signature files include the exact content hash at signing time. | ||||
| 5 | Verify that the original signature is still valid against the signing-time snapshot (applicable if Ed25519 cryptographic signing was used; see OQ-SIG-005 for details). | The signature archive preserves the content snapshot at signing time, independent of any subsequent edits to the live record. |
OQ-SIG-003 Request Action — Two-Person Review and Countersignature Workflow
21 CFR Part 11 Reference: 21 CFR 11.50(a): Signatures must be associated with specific individuals; 21 CFR 11.70: Signatures linked to records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Two user accounts required: User A (experiment owner/analyst) and User B (reviewer/supervisor). Both must be active members of the same team. | ||||||
| 1 | As User A, open a completed, unsigned experiment. Click the Request Action button. Select 'Sign'. In the recipient field, select User B. Add a note: 'Please review and sign as supervisor.' Click Send. | Request Action notification is sent. A confirmation message appears for User A. | ||||
| 2 | As User B, open the notification (Bell icon → notification center). Click the notification for the signature request. | User B is navigated to the experiment awaiting their signature. | ||||
| 3 | As User B, review the experiment content. Click the Signature button in the toolbar. Re-enter User B's password. Select meaning 'Supervisor Review and Approval'. Click Sign. | User B's signature is applied to the experiment. Signature block shows User B's name, date/time, and 'Supervisor Review and Approval' meaning. | ||||
| 4 | Return to User A's session. Navigate to the signed experiment. Observe the signature block. | Both signatures are visible: (1) User A's signature with their details; (2) User B's countersignature with their details. Both are distinct, attributed, and timestamped. | ||||
| 5 | Navigate to the Changelog for this experiment. Verify both signature events are recorded. | Changelog entries show two signature events: one attributed to User A, one to User B. Each has a unique timestamp and cannot be altered. |
OQ-SIG-004 Electronic Signature — Uniqueness and Non-Repudiation
21 CFR Part 11 Reference: 21 CFR 11.100(a): Each electronic signature shall be unique to one individual and shall not be reused by or reassigned to another individual.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Two user accounts (User A and User B) are required. This test verifies that electronic signatures can only be applied using the account holder's credentials. | ||||||
| 1 | Log in as User A. Open an unsigned experiment. Click Signature. In the credential re-entry dialog, enter User B's password instead of User A's. | Authentication fails. The signature is not applied. An error message indicates invalid credentials. | ||||
| 2 | Enter User A's correct password. Sign with meaning 'Author Certification'. | Signature is applied. The signature block shows User A's name. | ||||
| 3 | Log out as User A. Log in as User B. Navigate to the experiment signed by User A. Observe the signature. | The signature block shows User A's name, not User B's. User B cannot delete, modify, or claim ownership of User A's signature. | ||||
| 4 | As User B, attempt to add a second signature to the same experiment claiming to be User A (enter User A's credentials in User B's browser session). | The system rejects the attempt: the credentials are checked against the current authenticated session. The signature would be attributed to User B, not User A. |
OQ-SIG-005 Ed25519 Cryptographic Signature — Signing and Archive Creation
21 CFR Part 11 Reference: 21 CFR 11.70: Electronic signatures must be linked to records to preclude falsification. Ed25519 provides cryptographic non-repudiation.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: This test applies only if Ed25519 cryptographic signing is enabled. User must have generated an Ed25519 key pair in Settings → Account → Cryptographic Key. Skip this test and mark N/A if only simple signatures are used. | ||||||
| 1 | In Settings → Account, verify the Ed25519 public key is generated and displayed. Note the key fingerprint. | Public key fingerprint is displayed. No errors. | ||||
| 2 | Open a test experiment. Click Signature → Ed25519 (cryptographic signature) option. Enter the passphrase protecting the private key. Select meaning 'Cryptographic Author Certification'. Click Sign. | Signature process executes. A 'Signature created' confirmation appears. An immutable ZIP archive (the signature archive) is attached to the experiment in an archived/hidden attachment state. | ||||
| 3 | Navigate to Ellipsis (…) → Show Archived Attachments (or equivalent). Locate the signature archive ZIP. | The signature archive is present. Its filename includes the signature date/time and user identifier. | ||||
| 4 | Download the signature archive ZIP. Extract it. Verify it contains: (a) data.json (the experiment snapshot at signing time); (b) a .minisig signature file; (c) a public key file; (d) a verify.sh or README verification script. | All four components are present in the archive. | ||||
| 5 | Execute the verification script or manually verify using Minisign: minisign -Vm data.json -p publickey.pub -x signature.minisig | Verification output: 'Signature and comment signature verified.' The data.json content matches the experiment state at the time of signing. | ||||
| 6 | Modify data.json (add one character). Re-run verification. | Verification fails: 'Signature verification failed.' This demonstrates that any alteration of the signed content is detectable. |
4.7 Trusted Timestamping [CRITICAL — 21 CFR 11.10(c), 11.70]
OQ-TS-001 RFC 3161 Timestamp — Application and Token Storage
21 CFR Part 11 Reference: 21 CFR 11.10(c): Records must be retrievable in accurate form; timestamps establish temporal integrity.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: The TSA endpoint must be configured in Sysconfig → Timestamping. Internet access to the TSA is required. A test experiment in an unlocked state is required. | ||||||
| 1 | Open the test experiment in view mode. Click the Timestamp button (clock/seal icon) in the toolbar. Observe the process. | A timestamp request is initiated. A progress indicator or confirmation message appears. No error messages. | ||||
| 2 | After the timestamp completes, navigate to Ellipsis (…) → Show Archived Attachments. | A timestamp archive file (.zip or similar) appears in the archived attachments list. Its creation timestamp is the current date and time. | ||||
| 3 | Download the timestamp archive. Inspect its contents. | Archive contains: (a) the experiment JSON snapshot at timestamp time; (b) a .tsr (timestamp response) token file from the TSA; (c) a README or metadata file identifying the TSA used. | ||||
| 4 | Verify the TSA token is from the configured TSA provider (e.g., DFN.de, DigiCert, Sectigo). Inspect the .tsr file using: openssl ts -reply -in timestamp.tsr -text | TSA name, policy, hash algorithm (SHA-256), and timestamp are displayed. The timestamp matches the date/time of the timestamp application. |
OQ-TS-002 Timestamp Hash Integrity — Pre- and Post-Timestamp Content Verification
21 CFR Part 11 Reference: 21 CFR 11.10(c): Records must be protected from alteration or falsification.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use the timestamped experiment from OQ-TS-001. This test verifies that: (1) the content hash in the token matches the actual content at timestamp time; (2) subsequent modifications are detectable. | ||||||
| 1 | From the timestamp archive (OQ-TS-001, Step 3), extract the experiment JSON file (data.json or equivalent). Compute its SHA-256 hash: sha256sum data.json | Record the computed SHA-256 hash: [_________________________________________________] | ||||
| 2 | Extract the .tsr token file. Verify the hash embedded in the token: openssl ts -reply -in timestamp.tsr -text │ grep 'Message imprint' | The hash shown in the TSA token exactly matches the SHA-256 hash computed in Step 1. This confirms the token was issued for this specific content. | ||||
| 3 | Unlock the experiment. Add additional text to the body. Save and re-lock. Re-export the experiment to JSON or ZIP. | New export/JSON is created. Its content is different from the pre-modification snapshot. | ||||
| 4 | Compute the SHA-256 hash of the new export. Compare to the hash in the original timestamp token. | The new hash is DIFFERENT from the hash in the original timestamp token. This demonstrates that the timestamp token is specific to the pre-modification content. The modification is detectable. |
4.8 Audit Trail [CRITICAL — 21 CFR 11.10(e)]
OQ-AT-001 Changelog — Field Change Attribution and Timestamp
21 CFR Part 11 Reference: 21 CFR 11.10(e): Audit trails must record date/time, user identity, and what was changed.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Log in as User A. Create or open a test experiment. Record its current title before making changes. | ||||||
| 1 | Open a test experiment in edit mode. Note the current title. Change the title to a new value (e.g., add ' — MODIFIED' at the end). Save. | Title is changed successfully. | ||||
| 2 | Navigate to Ellipsis (…) → See Changelog. | Changelog page opens and displays a list of change events. | ||||
| 3 | Locate the most recent entry. Verify it shows: (a) the field that changed ('title'); (b) the previous value (original title); (c) the new value (modified title); (d) the identity of the user who made the change (User A); (e) the date and time of the change. | All five data elements are present and accurate for the title change. | ||||
| 4 | Change the experiment's Status. Save. Return to the Changelog. | A new changelog entry appears for the status change, also including all five data elements. | ||||
| 5 | Attempt to delete or modify a Changelog entry. Look for any edit, delete, or modify option on the Changelog. | No option exists to edit or delete any Changelog entry. The Changelog is read-only and immutable. | ||||
| 6 | Add a metadata field value. Change a tag. Return to the Changelog. | Both the metadata field change and the tag change appear as distinct entries in the Changelog. |
OQ-AT-002 Revisions — Main Text Body Version History
21 CFR Part 11 Reference: 21 CFR 11.10(e): Audit trail must capture all modifications to electronic records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Create a new test experiment with initial body text. Then make at least two subsequent edits to create a multi-version history. | ||||||
| 1 | Create an experiment with body text: 'Version 1 content — original text.' Save. | Experiment is saved. | ||||
| 2 | Edit the body text: change 'Version 1 content' to 'Version 2 content — first edit.' Save. | Change is saved. | ||||
| 3 | Edit the body text again: add a new paragraph 'Version 3 addition.' Save. | Change is saved. | ||||
| 4 | Navigate to Ellipsis (…) → See Revisions. | Revisions page opens. A list of at least 3 revisions (initial + 2 edits) is displayed, each with a timestamp and the user identity of the editor. | ||||
| 5 | Click on Version 1 (the earliest revision). | The body text content for Version 1 is displayed exactly as it was when first saved: 'Version 1 content — original text.' | ||||
| 6 | View the diff between Version 1 and Version 2 (if diff view is available). | Added and removed text is highlighted. Changes are clearly visible between versions. | ||||
| 7 | Attempt to delete any revision entry. | No option exists to delete revision history. Revisions are immutable. |
OQ-AT-003 ELabID — Uniqueness and Immutability
21 CFR Part 11 Reference: 21 CFR 11.10(b): Record accuracy and uniqueness; permanent record identification.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Three test experiments are needed for this test. | ||||||
| 1 | Create three separate experiments. Navigate to the bottom of each experiment in view mode. Record the ELabID for each. | ELabID 1: [___________________________] ELabID 2: [___________________________] ELabID 3: [___________________________] | ||||
| 2 | Compare the three ELabIDs. | All three ELabIDs are unique. No two experiments share the same ELabID. | ||||
| 3 | Attempt to modify the ELabID of one experiment by editing any available field. | No field in the user interface allows modification of the ELabID. It is a system-generated, read-only identifier. | ||||
| 4 | Delete one of the experiments (soft delete). Create a new experiment. Verify the new experiment's ELabID. | The new experiment has a new unique ELabID. The ELabID of the deleted experiment is not reused or reassigned. |
OQ-AT-004 System Audit Log — Authentication and Admin Events
21 CFR Part 11 Reference: 21 CFR 11.10(e): Audit trail must capture all access and administrative actions.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: SysAdmin access required. Perform a deliberate set of auditable actions before checking the log. | ||||||
| 1 | Perform these actions in sequence: (a) Log in as a test user; (b) Log out; (c) Attempt login with wrong password; (d) As SysAdmin, modify a configuration setting in Sysconfig. | All actions are performed. | ||||
| 2 | As SysAdmin, navigate to Sysconfig → Audit Logs. | The system audit log page is accessible. Filtering options are available. | ||||
| 3 | Filter the log for the test user's login events from the past hour. | Successful login event and logout event for the test user are both present, each with timestamp and IP address. | ||||
| 4 | Filter for failed login attempts. | The failed login attempt (wrong password) appears with timestamp and IP address. | ||||
| 5 | Filter for SysAdmin configuration change events. | The configuration change made in Step 1(d) appears in the log with the SysAdmin's identity and timestamp. | ||||
| 6 | Attempt to delete any log entry. | No option exists to delete any log entry. The system audit log is immutable. |
OQ-AT-005 Audit Trail Completeness — Multi-Step Workflow Record
21 CFR Part 11 Reference: 21 CFR 11.10(e): Audit trail must record a complete and accurate account of all actions.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: This test verifies that a complete chain of events across a full experiment lifecycle is captured without gaps. Perform the following workflow sequentially on a new test experiment. | ||||||
| 1 | As User A, create a new experiment titled 'OQ-AT-005 Completeness Test'. Save. | Record creation is logged in Changelog. | ||||
| 2 | Add a tag 'AT-Test'. Save. | Tag addition is logged. | ||||
| 3 | Change status to 'Running' (if not default). Save. | Status change logged. | ||||
| 4 | Add a comment: 'OQ completeness test comment.' Save. | Comment creation logged. | ||||
| 5 | Upload an attachment. | Upload event logged. | ||||
| 6 | Apply an electronic signature (any type). | Signature event logged. | ||||
| 7 | Apply an RFC 3161 timestamp. | Timestamp event logged. | ||||
| 8 | Lock the experiment. | Lock event logged. | ||||
| 9 | Navigate to Ellipsis → See Changelog. Count the entries. | Changelog contains at least 8 entries corresponding to the 8 actions above. Each entry has: event type, previous value (where applicable), new value, user identity, and timestamp. No actions are missing from the record. |
4.9 Template Management [HIGH]
OQ-TM-001 Team Template Creation and Team-Wide Availability
21 CFR Part 11 Reference: 21 CFR 11.10(b): Standardized procedures for generating accurate and complete records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Log in as Admin for this test. A regular User account (non-Admin) must be available for Step 5. | ||||||
| 1 | As Admin, navigate to Experiments → Templates. Click Create. Enter template name: 'OQ-TM-001 Validation Template'. Select category. Add body text: 'Section: Results'. Add two metadata fields: (1) 'Analyst Name' (Text); (2) 'Result' (Select: Pass, Fail). Add one locked step: 'Step 1: Review all data before signing.' Mark the step as locked. Click Make available to Team. Save. | Template is created and saved without error. | ||||
| 2 | As Admin, navigate to Experiments → Templates. Search for 'OQ-TM-001 Validation Template'. | Template appears in the templates list with the team-visible indicator. | ||||
| 3 | As Admin, create a new experiment. When the template selection dialog opens, search for 'OQ-TM-001 Validation Template'. | The template appears in the template selection dialog. | ||||
| 4 | As a regular User (non-Admin), log in. Navigate to Experiments → Create. Open the template selection dialog. | The template 'OQ-TM-001 Validation Template' is visible to the regular User in the template selection list. | ||||
| 5 | As the regular User, create an experiment from the template. | New experiment opens with: (a) 'Section: Results' in the body; (b) 'Analyst Name' and 'Result' metadata fields; (c) 'Step 1' in the steps panel with a lock icon indicating it is locked. |
OQ-TM-002 Template Locked Steps Cannot Be Modified by User
21 CFR Part 11 Reference: 21 CFR 11.10(b): Standardized procedures; 11.10(e): Controls ensure procedural compliance.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Use an experiment created from OQ-TM-001 template (which has one locked step). Log in as the experiment owner (regular User, not Admin). | ||||||
| 1 | Open the experiment in edit mode. Locate the locked step 'Step 1: Review all data before signing.' | Locked step is visible. A lock icon is displayed on or near the step. The step text is not editable. | ||||
| 2 | Attempt to click on the locked step text and type replacement text. | The text field is non-editable. No modification is accepted. | ||||
| 3 | Attempt to delete the locked step by clicking any delete icon or using keyboard delete. | No delete option is available for the locked step. The step cannot be removed. | ||||
| 4 | Attempt to drag-and-drop the locked step to a different position in the steps list. | Step position cannot be changed. Locked step remains in its original position. | ||||
| 5 | Click the checkbox on the locked step to mark it as complete. | Step completion is accepted. The step is marked as complete with a timestamp and user attribution. Only the checkbox (completion) is interactive, not the step text. |
4.10 Resource Management [MEDIUM-HIGH]
OQ-RM-001 Resource Creation and Category Assignment
21 CFR Part 11 Reference: 21 CFR 11.10(b): Accurate cataloging of all materials used in GxP records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: At least one Resource Category must exist in the system. Log in as a regular User. | ||||||
| 1 | Navigate to Resources. Click Create. Enter title: 'OQ-RM-001 Test Reagent Lot'. Select a resource category. | Resource creation dialog accepts title and category. | ||||
| 2 | Add a metadata text field with key 'Lot Number' and value 'LOT-OQ-2026-001'. Add a date field 'Expiry Date' with today's date + 365 days. Save. | Resource is created and all fields are saved correctly. | ||||
| 3 | Navigate to the Resources index. Filter by the category used in Step 1. | The newly created resource appears in the filtered index. | ||||
| 4 | Search for 'OQ-RM-001' in the search bar. | The resource appears in search results, findable by title. | ||||
| 5 | Open the resource in view mode. Verify all fields (title, category, metadata fields) are displayed correctly. | All fields display the correct values entered in Steps 1 and 2. |
OQ-RM-002 Resource Scheduler — Booking and Conflict Prevention
21 CFR Part 11 Reference: 21 CFR 11.10(b): Records accurately reflect when controlled items are used.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A bookable resource (e.g., an instrument with scheduling enabled) must exist. Admin must have enabled booking on the resource. Log in as a regular User. | ||||||
| 1 | Navigate to Resources. Open a bookable resource. Click 'Book Item' or navigate to the Scheduler. | The scheduler/calendar view opens showing the resource's availability. | ||||
| 2 | Click on an available time slot for tomorrow (e.g., 10:00 AM – 12:00 PM). Add a booking note: 'OQ-RM-002 Test Booking'. Confirm. | Booking is created. The time slot appears in the calendar as occupied with the booking user's name. | ||||
| 3 | As a second user (User B), attempt to book the same resource for the same time slot. | Booking conflict is detected. User B receives an error or warning indicating the time slot is already booked. The booking is not created. | ||||
| 4 | As User A, cancel the test booking. | Booking is cancelled. The time slot becomes available again. |
4.11 User and Team Administration [HIGH]
OQ-UA-001 User Account Validation Workflow
21 CFR Part 11 Reference: 21 CFR 11.10(d): Access limited to authorized individuals only.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Self-registration must be enabled in the Team settings (Admin Panel → Team tab) for this test. Require Admin validation of new accounts must also be enabled. | ||||||
| 1 | From a browser not logged in, navigate to the LabLynx One registration page. Register a new test account with a valid email address. | Registration is accepted. A message indicates the account is pending Admin validation and cannot be used until validated. | ||||
| 2 | Attempt to log in with the newly registered account before Admin validation. | Login fails. Error message indicates the account is pending validation. Access is denied. | ||||
| 3 | As Admin, open the Admin Panel → Users tab. Locate the pending new account. | Pending account appears in a 'Validation pending' list or state. | ||||
| 4 | As Admin, click Validate for the new account. | Account is activated. The status changes to active/validated. | ||||
| 5 | Attempt login with the newly validated account credentials. | Login succeeds. User is redirected to the LabLynx One dashboard. |
OQ-UA-002 Team Export — Bulk Experiment Data Integrity
21 CFR Part 11 Reference: 21 CFR 11.10(c): Records must be accurately and readily retrievable throughout the retention period.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Admin account required. At least 5 experiments of a specific category must exist. | ||||||
| 1 | As Admin, navigate to Admin Panel → Export. Select experiment export. Filter by category = [test category]. Select PDF format. Click Export. | Export process begins. Progress may be indicated. | ||||
| 2 | After the export completes, download the output (ZIP or individual PDFs). | Files download successfully. Number of files matches the number of experiments in the selected category. | ||||
| 3 | Open one of the exported PDFs. Verify it contains the experiment's title, date, metadata, and body content. | PDF content is complete and matches the experiment's actual content in LabLynx One. | ||||
| 4 | Verify the ELabID appears in the PDF footer. | ELabID is present, enabling cross-reference between the paper PDF and the digital record. |
4.12 System Configuration and Integration [MEDIUM]
OQ-SC-001 REST API — Authentication and Read Operation
21 CFR Part 11 Reference: 21 CFR 11.70: Electronic records must be accessible through authenticated methods only.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Generate a read-only API key in Settings → API Keys before this test. Record the key value. | ||||||
| 1 | Execute: curl -H 'Authorization: [API_KEY]' https://[SERVER_NAME]/api/v2/users/me | Returns HTTP 200 with a JSON object containing the authenticated user's name, email, and team. Authentication via API key is successful. | ||||
| 2 | Execute: curl -H 'Authorization: INVALID_KEY_VALUE' https://[SERVER_NAME]/api/v2/users/me | Returns HTTP 401 Unauthorized. Invalid API keys are rejected. | ||||
| 3 | Execute: curl -H 'Authorization: [API_KEY]' https://[SERVER_NAME]/api/v2/experiments?limit=5 | Returns HTTP 200 with a JSON array of up to 5 experiments accessible to the API key's user. | ||||
| 4 | Using a Read-Only API key, attempt to create a new experiment: curl -X POST -H 'Authorization: [READ_ONLY_KEY]' https://[SERVER_NAME]/api/v2/experiments | Returns HTTP 403 Forbidden. Read-only keys cannot create or modify records. |
OQ-SC-002 Timestamping Service Configuration Verification
21 CFR Part 11 Reference: 21 CFR 11.10(c): Protection of records; trusted third-party temporal integrity.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: SysAdmin account required. Verify the TSA is configured in Sysconfig → Timestamping. | ||||||
| 1 | As SysAdmin, navigate to Sysconfig → Timestamping. Verify the configured TSA URL matches the approved TSA from Section 2.4. | TSA URL matches the configured value in Section 2.4. | ||||
| 2 | Create a test experiment. Apply an RFC 3161 timestamp (see OQ-TS-001). | Timestamp is applied without error, confirming the TSA endpoint is reachable and the configuration is valid. | ||||
| 3 | From the timestamp archive, confirm the TSA certificate chain can be verified. Execute: openssl ts -reply -in [timestamp.tsr] -text │ grep 'TSA' | TSA identity is displayed and matches the configured provider. |
4.13 OQ Summary
| OQ Summary Item | Recorded Value |
|---|---|
| Total OQ Test Cases | [Record: _____ ] |
| CRITICAL Tests — Passed | [Record: _____ ] / [Total CRITICAL: _____ ] |
| HIGH Tests — Passed | [Record: _____ ] / [Total HIGH: _____ ] |
| MEDIUM Tests — Passed | [Record: _____ ] / [Total MEDIUM: _____ ] |
| Total Tests Failed | [Record: _____ ] — Deviation IDs: [_____________________ ] |
| N/A Tests | [Record: _____ ] — (List N/A IDs: _____________________ ) |
| Open Deviations | [Record: _____ ] — All deviations documented in Appendix D |
| OQ Overall Result | PASS / FAIL / CONDITIONAL PASS (circle one) |
| Role | Name | OQ Approval Signature / Date |
|---|---|---|
| Validation Owner | [Name / Title] | [Signature / Date] |
| QA Reviewer | [Name / Title] | [Signature / Date] |
Performance Qualification (PQ)
Verifies that the configured system performs reliably under actual, representative real-world operating conditions.
The Performance Qualification demonstrates that LabLynx One operates correctly and consistently under actual use conditions with real users performing real workflows. PQ scenarios are designed to replicate complete end-to-end laboratory workflows that span multiple system features and confirm the system performs appropriately as an integrated whole.
PQ Prerequisites: (1) IQ and OQ are complete and approved. (2) The system is configured with production-representative data (at least one team, categories, templates, and user accounts). (3) All PQ testers are trained LabLynx One users who have completed any required onboarding. (4) PQ is conducted in the production environment (or an exact copy of it for initial validation).
PQ-001: Complete Regulated Analytical Experiment Lifecycle
Objective: Demonstrate that a complete GxP-compliant analytical experiment record can be created, documented, reviewed, signed, timestamped, and locked in a workflow that satisfies all 21 CFR Part 11 requirements simultaneously.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Two users required: Analyst (User A) and Supervisor (User B). A method validation or analytical run template must exist with at least 4 metadata fields and 3 steps (at least 1 locked). | ||||||
| 1 | As the Analyst, log in with personal credentials (MFA if required). Create a new experiment from the analytical template. Title: 'PQ-001 HPLC Potency — Sample Batch PQ-2026'. Set date to today. | Experiment created from template. All template fields present. | ||||
| 2 | Fill all metadata fields: Analyst = [tester name], Instrument = [instrument ID], Lot Number = [test lot], Result = [a representative numeric value], Pass/Fail = Pass. | All metadata fields populated and saved. | ||||
| 3 | Write a protocol summary in the body text (at least 3 sentences describing the analytical procedure performed). | Body text saved and visible in view mode. | ||||
| 4 | Upload a test file ('PQ-001-rawdata.pdf') as an attachment. | File attached successfully. Upload timestamp and analyst identity shown. | ||||
| 5 | Complete all protocol steps by clicking each checkbox. Verify each step shows a completion timestamp and the Analyst's name. | All steps completed and timestamped. Each step shows Analyst identity. | ||||
| 6 | Apply an electronic signature with meaning 'I certify this record is accurate, complete, and was prepared by me personally.' Re-enter credentials when prompted. | Signature block appears with Analyst name, date/time, and meaning. | ||||
| 7 | Use Request Action → Sign to request the Supervisor's countersignature. As the Supervisor, review the experiment and apply a countersignature with meaning 'Supervisor Review and Technical Approval.' | Supervisor signature block added. Both signatures are visible and individually attributed. | ||||
| 8 | Apply an RFC 3161 timestamp. Verify the timestamp archive is created (Ellipsis → Archived Attachments). | Timestamp archive is present with today's date. | ||||
| 9 | Lock the experiment. | Experiment is locked. Lock event appears in Changelog. | ||||
| 10 | Navigate to the Changelog. Verify all 10 events from this workflow are present in the audit trail (creation, field edits, file upload, step completions, two signatures, timestamp, lock). | Changelog contains at least 10 entries covering all workflow events. Each entry has timestamp and user identity. No gaps in the chain of events. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-002: Multi-User Concurrent Access and Data Isolation
Objective: Demonstrate that multiple users can simultaneously use the system without data collision, that private records remain isolated, and that all concurrent actions are individually attributed.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Three simultaneous user sessions required (three computers or browsers). Users: Analyst A, Analyst B, Admin C. All in the same team. | ||||||
| 1 | Simultaneously: Analyst A creates an experiment titled 'PQ-002-UserA-Concurrent'. Analyst B creates 'PQ-002-UserB-Concurrent'. Admin C opens the team experiment index. | All three operations succeed simultaneously without error or interference. | ||||
| 2 | Analyst A sets their experiment to 'Only Me' privacy. Analyst B sets theirs to 'My Team'. Both save. | Both privacy settings are accepted. | ||||
| 3 | Analyst B's session: navigate to the index. Search for 'PQ-002-UserA-Concurrent'. | Analyst B CANNOT see Analyst A's private experiment in search results. | ||||
| 4 | Admin C's session: navigate to the index (with Admin view of all team experiments). Search for 'PQ-002-UserA-Concurrent'. | Admin C CAN see Analyst A's private experiment (Admin privilege). The experiment is present in Admin C's view. | ||||
| 5 | Simultaneously: Analyst A adds a tag, Analyst B changes a status, Admin C exports a different experiment. All three perform their actions at the same time. | All three operations succeed without error. Each change is applied to the correct experiment. | ||||
| 6 | Verify the Changelog for each experiment shows the correct user identity for each change. | Each experiment's Changelog shows only the attributed user's changes. No cross-attribution errors. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-003: Template Enforcement Consistency Across Users
Objective: Demonstrate that a team template with locked steps produces identical structure and enforcement for all users who create experiments from it, regardless of which user creates the experiment.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Three different user accounts (all regular Users, not Admin). OQ-TM-001 template must exist with at least one locked step. | ||||||
| 1 | User A creates an experiment from the OQ-TM-001 template. Record the step descriptions as User A sees them. | Experiment created. Steps listed: [Record step 1 text: ________________________________] | ||||
| 2 | User B creates a separate experiment from the same template. Compare the steps to User A's. | Steps are identical: same text, same order, same lock status as User A's. | ||||
| 3 | User C creates a third experiment from the same template. | Steps are identical to Users A and B. | ||||
| 4 | All three users attempt to modify the locked step description on their respective experiments. | All three fail. Locked step is non-editable for all three users. | ||||
| 5 | All three users complete their locked steps by clicking the checkbox. Verify each completion shows that user's individual identity and a unique timestamp. | Each completion is individually attributed: User A's step shows User A, User B's shows User B, User C's shows User C. All timestamps are distinct. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-004: Audit Trail Integrity Under Sequential Edits by Multiple Users
Objective: Demonstrate that the audit trail captures a complete, unbroken chain of events when multiple users make sequential modifications to the same experiment record.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: One shared experiment (write access for multiple users). Three users: User A (owner), User B (editor), User C (editor). Note the experiment ELabID. | ||||||
| 1 | User A creates experiment 'PQ-004-MultiUser-AuditTest' with initial body text 'Initial content by User A.' Set permission to allow User B and C to edit. Save. | Experiment created. Changelog shows creation by User A. | ||||
| 2 | User B edits the title to append ' — Updated by B'. Saves. | Title update saved. Changelog entry: User B changed title. | ||||
| 3 | User C adds a metadata field value. Saves. | Metadata update saved. Changelog entry: User C changed metadata. | ||||
| 4 | User A changes the body text (adding a new paragraph). Saves. | Body text revision created. Revisions shows new version by User A. | ||||
| 5 | User B adds a comment: 'PQ-004 comment by User B.' | Comment added. Comment panel shows User B's name and timestamp. | ||||
| 6 | User A locks the experiment. | Lock event recorded in Changelog with User A's identity. | ||||
| 7 | Navigate to the Changelog for this experiment. | Changelog shows 5+ distinct entries in chronological order: creation (A), title change (B), metadata change (C), lock (A). Each entry has the correct user attribution and timestamp. No events are missing. | ||||
| 8 | Navigate to Revisions. Verify the body text revision history. | Revision history shows the initial version (User A) and the modified version (User A, Step 4). User B and C's changes (non-body) are in Changelog but not Revisions (correct behavior). |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-005: Resource Traceability — Lot Impact Analysis
Objective: Demonstrate that a single resource record can be linked to multiple experiments and that the complete list of linked experiments is retrievable from the resource record for impact analysis purposes.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A Resource record (e.g., a reagent lot) and 10 test experiments must be available. Batch linking via the API or manual linking of 10 experiments is acceptable. | ||||||
| 1 | Open the Resource record 'OQ-RM-001 Test Reagent Lot' (created in OQ-RM-001). Record its ID. | Resource record is open. ID: [____________] | ||||
| 2 | Link 10 different experiments to this resource (either via the body text # autocomplete or the Links panel). Verify each link is created. | All 10 experiments are linked to the resource. Each linking operation succeeds. | ||||
| 3 | Open the resource record in view mode. Navigate to the Linked Experiments or Related section. | A list of linked experiments appears. All 10 experiments that were linked in Step 2 are visible in this list. | ||||
| 4 | Click on one linked experiment from the resource. Navigate to the experiment. | Navigation to the experiment is successful. The experiment's Links panel shows the resource. | ||||
| 5 | From the experiment, click the link back to the resource. | Navigation back to the resource is successful. Round-trip bidirectional navigation confirmed. | ||||
| 6 | Search for 'OQ-RM-001 Test Reagent Lot' in the main search bar. | Search results include the resource record as a top result. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-006: Backup and Restore Integrity
Objective: Demonstrate that the backup and restore procedure produces complete, accurate, and retrievable records — satisfying 21 CFR Part 11 requirement 11.10(c) for record protection and accessibility.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: This test requires system administrator access. Schedule this during a maintenance window as it involves container restarts. For sciCloud.net® deployments, coordinate with LabLynx support. | ||||||
| 1 | Create a test experiment titled 'PQ-006-BackupRestoreTest' with: body text, 2 metadata fields, 1 attachment, 1 completed step, 1 comment, 1 signature. Note the ELabID. | Test experiment created. ELabID: [__________________________] | ||||
| 2 | Execute the backup procedure: sudo elabctl backup (or sudo /usr/local/bin/elab-backup.sh). Verify completion with no errors. | Backup completes successfully. Backup directory contains DB dump and uploads backup. | ||||
| 3 | Soft-delete the test experiment from LabLynx One. Verify it disappears from the active index. | Experiment is no longer visible in the default experiment index. | ||||
| 4 | Stop the LabLynx One containers: sudo docker compose -f /etc/elabftw.yml down | Containers stop cleanly. | ||||
| 5 | Restore the database from backup: zcat [backup]/elabftw-db.sql.gz │ sudo docker exec -i mysql mysql -u elabftw -p[password] elabftw. Restore uploads: sudo rsync -av --delete [backup]/uploads/ /var/elabftw/web/ | Restore commands execute without errors. | ||||
| 6 | Restart LabLynx One: sudo docker compose up -d. Wait for healthy status. | Both containers start and report healthy. | ||||
| 7 | Log in. Navigate to the experiments index. Search for 'PQ-006-BackupRestoreTest'. Verify all content is restored. | Experiment is present in the index. All content (body text, metadata, attachment, step completion, comment, signature) is intact and matches the pre-backup state. | ||||
| 8 | Navigate to the Changelog of the restored experiment. Verify the signature event is present. | All audit trail events are intact post-restore. The signature event is preserved with its original timestamp and attribution. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-007: System Recovery After Unplanned Restart
Objective: Demonstrate that LabLynx One recovers cleanly from an unplanned server restart, that containers auto-restart, and that no data is lost or corrupted.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: Requires system administrator access. For sciCloud.net®, coordinate with LabLynx support. Note the current state of several experiments before the test. | ||||||
| 1 | Record the titles and last-saved timestamps of 3 existing experiments. | Record: Exp 1: [________] Exp 2: [________] Exp 3: [________] | ||||
| 2 | Simulate an unplanned restart: sudo reboot (or LabLynx-managed equivalent for sciCloud.net®). Wait for the server to complete the reboot cycle (typically 2–5 minutes). | Server reboots and comes back online. | ||||
| 3 | After reboot, wait 3 minutes. Execute: sudo docker ps | Both elabftw and mysql containers show 'Up' status with healthy health check. Containers auto-started without manual intervention. | ||||
| 4 | Navigate to LabLynx One in a browser. Log in with valid credentials. | Login page loads. Login succeeds. Dashboard is accessible. | ||||
| 5 | Navigate to the three experiments recorded in Step 1. Verify their titles, last-saved timestamps, and content are unchanged. | All three experiments are present with their original content. No data has been lost or corrupted. | ||||
| 6 | Navigate to the Changelog of one of the three experiments. Verify the audit trail is intact. | Changelog shows all pre-restart events. No audit trail entries are missing. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-008: API Integration — Programmatic Record Creation and Audit Trail
Objective: Demonstrate that experiments created programmatically via the REST API are indistinguishable from UI-created records in the audit trail, and that all 21 CFR Part 11 controls apply equally to API-created records.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: A valid Read-Write API key must be available. Python with the requests library, or curl, must be available on the testing workstation. | ||||||
| 1 | Execute via API: POST /api/v2/experiments. Note the returned experiment ID from the Location header. | API returns HTTP 201 Created. Record experiment ID: [____________] | ||||
| 2 | Execute via API: PATCH /api/v2/experiments/{id} with body: {"title": "PQ-008 API Integration Test", "date": "[today]", "metadata": "{\"extra_fields\":{\"Analyst\":{\"type\":\"text\",\"value\":\"API-Integration-Test\"}}}"}. | API returns HTTP 200. Metadata field is populated. | ||||
| 3 | Execute via API: POST /api/v2/experiments/{id}/tags with body {"tag": "PQ-API-Test"} | API returns HTTP 201. Tag is added. | ||||
| 4 | In the LabLynx One browser interface, navigate to the experiment created in Step 1. Verify it appears in the index with the correct title and tag. | Experiment is visible in the UI with all API-set values. | ||||
| 5 | Navigate to the Changelog of the API-created experiment. | Changelog shows creation event attributed to the user associated with the API key, with a system timestamp. Tag addition event also recorded. | ||||
| 6 | In the UI, apply an electronic signature to the API-created experiment (with credential re-entry). Verify signature is applied. | Signature is applied and recorded exactly as for a UI-created experiment. The system treats API-created and UI-created records identically. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-009: Data Archival and Long-Term Retrievability
Objective: Demonstrate that archived experiments remain fully accessible, searchable, and retrievable, and that archived records maintain complete audit trail integrity.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: At least 10 completed, signed experiments must be available for archiving. This test simulates project closure archival. | ||||||
| 1 | As Admin, navigate to Admin Panel → Batch Actions. Select 'Archive' action. Filter to select 10 completed experiments from a specific category. Preview the action. | Preview shows the correct 10 experiments. No unintended experiments are included. | ||||
| 2 | Execute the batch archive action. | 10 experiments are archived. They no longer appear in the default experiment index. | ||||
| 3 | In the Experiments index, use the State filter to select 'Archived'. | All 10 archived experiments appear in the filtered view. | ||||
| 4 | Open one archived experiment. Verify all content (body, metadata, attachments, steps, comments, signatures, Changelog) is intact. | All content is preserved exactly as it was before archiving. | ||||
| 5 | Search for one archived experiment by title (without the archived filter). | Archived experiments may or may not appear in default search (depends on configuration). With the archived state filter enabled, the experiment is findable. | ||||
| 6 | Attempt to edit an archived experiment. | Edit is not permitted on archived experiments. The record is protected from modification. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
PQ-010: Deviation and Incident Scenario — Post-Signature Modification Detection
Objective: Demonstrate that the system's controls correctly detect and document any attempt to modify a signed and locked record, and that the audit trail provides an accurate and complete record of the modification chain.
| Step | Action / Procedure | Expected Result | Actual Result | P/F | Initials | Date |
|---|---|---|---|---|---|---|
| Prerequisites / Notes: This scenario simulates a real-world deviation scenario: a record that was signed and locked is subsequently unlocked and modified (a scenario that would require a formal change control in a GMP environment). The test verifies the audit trail captures all events accurately. | ||||||
| 1 | Create a new experiment. Populate all fields. Sign (Analyst). Apply RFC 3161 timestamp. Lock. Record the experiment title and ELabID. | Experiment signed, timestamped, and locked. ELabID: [______________] | ||||
| 2 | As Admin, unlock the experiment. (Record the reason in the Deviation Log, Appendix D). Note the unlock timestamp. | Experiment is unlocked. Unlock event appears in Changelog with Admin identity and timestamp. | ||||
| 3 | Add a corrective note to the body text: 'Correction per Deviation DEV-OQ-PQ10: [describe correction]'. Save. | Body text modified. New revision created in Revisions history. | ||||
| 4 | Re-apply the Analyst signature and the Supervisor signature (new signing events for the corrected record). | Two new signature events appear. The original signatures and the new signatures are all visible in the record. | ||||
| 5 | Re-apply an RFC 3161 timestamp (to the corrected record). | New timestamp archive created. The original timestamp archive is also preserved (archived attachment from Step 1). | ||||
| 6 | Re-lock the experiment. | Experiment locked. Re-lock event in Changelog. | ||||
| 7 | Navigate to the Changelog. Verify it shows the complete chain: creation, original signing, original timestamp, lock, UNLOCK, body edit, new signatures, new timestamp, re-lock — in chronological order with all events attributed. | The Changelog shows a complete, unbroken chain of all 10+ events. The unlock event is clearly visible, the modification is attributed to the Admin, and all post-correction signatures are separately attributed. No events are hidden or missing. The record accurately reflects everything that happened. |
| Field | Value |
|---|---|
| PQ Scenario Performed By | [Name / Title / Signature] |
| Date of Execution | [ ] |
| QA Observer / Reviewer | [Name / Title / Signature] |
| Scenario Result | PASS / FAIL (circle one) — Deviation Ref (if applicable): [_______] |
5.2 PQ Summary
| PQ Summary Item | Recorded Value |
|---|---|
| Total PQ Scenarios | 10 |
| Scenarios Passed | [Record: _____ ] |
| Scenarios Failed | [Record: _____ ] — Deviation IDs: [_____________________ ] |
| Open Deviations | [Record: _____ ] — All deviations documented in Appendix D |
| PQ Overall Result | PASS / FAIL / CONDITIONAL PASS (circle one) |
| Role | Name | PQ Approval Signature / Date |
|---|---|---|
| Validation Owner | [Name / Title] | [Signature / Date] |
| QA Reviewer | [Name / Title] | [Signature / Date] |
Change Control and Revalidation Requirements
Defines how subsequent changes to the qualified system are controlled and when revalidation is required.
21 CFR Part 11 and GAMP 5 require that validated computerized systems be maintained in a validated state throughout their operational lifetime. Any change to the system must be assessed for its impact on validation status, and appropriate revalidation must be performed before the change is placed in production use.
6.1 Change Control Trigger Criteria
| Change Type | Revalidation Requirement |
|---|---|
| LabLynx One Version Upgrade (minor: x.x.X) | Review release notes. Assess impact on validated functions. Execute regression OQ for any changed or potentially impacted features. Full revalidation not typically required for minor patch updates, but a documented risk assessment is mandatory. |
| LabLynx One Version Upgrade (major/minor: X.x.0 or x.X.0) | Full OQ repeat for all CRITICAL and HIGH-risk functions. PQ-001 through PQ-005 minimum. Update System Baseline (Section 2). Update IQ for any changed infrastructure. |
| Configuration Change (new category, template, status) | Document the change. Execute the relevant OQ test cases for the changed configuration element (e.g., OQ-TM-001/002 for a new template). Minimal revalidation may be sufficient. |
| Authentication Change (new SSO provider, MFA enforcement) | Execute OQ-AC-001 through OQ-AC-004 for the new authentication path. |
| Infrastructure Change (new server, OS upgrade, Docker upgrade) | Full IQ repeat. Execute OQ-AT-004/005 (audit log continuity). Execute PQ-007 (restart recovery). |
| Network or TLS Certificate Change | Execute IQ-005 and IQ-006. Verify application accessibility and API connectivity. |
| Backup System Change | Execute IQ-010 and PQ-006. |
| sciCloud.net® Platform Update (LabLynx-managed) | LabLynx is responsible for infrastructure change control. Customer must receive notification of changes and LabLynx's qualification documentation. Customer executes application-level OQ/PQ regression as warranted. |
Validation Summary Report
Summarizes the outcome of the IQ, OQ, and PQ execution for final QA review and sign-off.
Complete this section after all IQ, OQ, and PQ testing is complete and all deviations have been resolved or risk-accepted by QA. This section constitutes the formal conclusion of the validation exercise.
7.1 Summary of Validation Results
| Summary Element | Recorded Value |
|---|---|
| System Name and Version | LabLynx One — Version: [___________________ ] |
| Validation Period | From: [__ / __ / ____] To: [__ / __ / ____] |
| IQ Result | PASS / FAIL / CONDITIONAL PASS — Tests: [____] Passed / [____] Failed / [____] N/A |
| OQ Result | PASS / FAIL / CONDITIONAL PASS — Tests: [____] Passed / [____] Failed / [____] N/A |
| PQ Result | PASS / FAIL / CONDITIONAL PASS — Scenarios: [____] Passed / [____] Failed |
| Total Open Deviations | [____] Critical / [____] Major / [____] Minor — All closed: Yes / No |
| Overall Validation Result | VALIDATED / NOT VALIDATED / CONDITIONALLY VALIDATED (circle one) |
| Conditional Use Restrictions (if applicable) | [Describe any restrictions on system use pending CAPA completion: ____________ ] |
7.2 21 CFR Part 11 Compliance Attestation
Based on the test evidence documented in this validation package, the following attestation is made regarding LabLynx One's compliance with 21 CFR Part 11:
| 21 CFR Part 11 Section | Compliance Evidence References |
|---|---|
| §11.10(a) — Validation | LabLynx One has been validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. Evidence: IQ-001 through IQ-014; OQ-EX-007, OQ-EX-008; PQ-001 through PQ-010. |
| §11.10(b) — Record Legibility and Retention | Electronic records are accurate and complete. They can be accurately and readily retrieved throughout the records retention period. Evidence: OQ-EX-010, OQ-SC-001, PQ-005, PQ-009. |
| §11.10(c) — Record Protection | Computer-generated audit trails prevent loss or modification of records. Backup procedures protect records for retrieval during the retention period. Evidence: OQ-EX-007, OQ-AT-001 through OQ-AT-005, PQ-006. |
| §11.10(d) — Access Limitation | System access is limited to authorized individuals. Evidence: OQ-AC-001 through OQ-AC-007; IQ-005, IQ-012, IQ-013. |
| §11.10(e) — Audit Trails | Secure, computer-generated, time-stamped audit trails independently record operator entries and actions. Evidence: OQ-AT-001 through OQ-AT-005, PQ-004, PQ-010. |
| §11.30 — Open Networks | Records transmitted via open networks (HTTPS) include measures to ensure authenticity, integrity, and confidentiality. Evidence: IQ-005, IQ-006; OQ-SC-001. |
| §11.50 — Signature Manifestations | Signed electronic records contain the printed name, date/time, and meaning of the signature. Evidence: OQ-SIG-001, OQ-SIG-003. |
| §11.70 — Signature Linkage | Electronic signatures are linked to their electronic records to preclude transfer or falsification. Evidence: OQ-SIG-002, OQ-SIG-005, PQ-010. |
| §11.100 — Signature Uniqueness | Each electronic signature is unique to one individual and not reused or reassigned. Evidence: OQ-SIG-004. |
| §11.200 — Signature Components | Non-biometric signatures employ at least two distinct identification components (user ID + password / + MFA). Evidence: OQ-AC-001, OQ-AC-003, OQ-SIG-001. |
| §11.300 — Signature Controls | Controls ensure only genuine owners use their signatures; systems detect attempted misuse. Evidence: OQ-AC-002, OQ-SIG-004. |
7.3 Final Approval and Release
By signing below, the approvers confirm that: (1) all validation testing has been completed as documented in this package; (2) all deviations have been resolved or risk-accepted; (3) LabLynx One is released for use in the generation and maintenance of electronic records subject to 21 CFR Part 11; and (4) this validation package is retained as a controlled record for the life of the system.
| Role | Name / Title | Final Approval Signature / Date |
|---|---|---|
| Validation Owner | [Name / Title] | [Signature / Date] |
| Quality Assurance Director | [Name / Title] | [Signature / Date] |
| System Owner / IT Director | [Name / Title] | [Signature / Date] |
| Department Head / VP R&D | [Name / Title] | [Signature / Date] |
| Regulatory Affairs (if applicable) | [Name / Title] | [Signature / Date] |
Appendix A: 21 CFR Part 11 Traceability Matrix
Maps 21 CFR Part 11 subsections to the specific test cases in this manual that verify each requirement.
| 21 CFR § | Requirement Summary | Test Cases Providing Evidence |
|---|---|---|
| §11.10(a) | Validation | IQ-001–014; OQ-EX-001–010; OQ-SIG-001–005; OQ-TS-001–002; OQ-AT-001–005; PQ-001–010 |
| §11.10(b) | Accurate/Complete Records | OQ-EX-001,002,003,005,010; OQ-TM-001,002; OQ-RM-001; PQ-001,003,005 |
| §11.10(c) | Record Protection | OQ-EX-007,008; OQ-AT-001–005; OQ-TS-001,002; IQ-010; PQ-006,009 |
| §11.10(d) | Access Controls | OQ-AC-001–007; IQ-005,012,013; PQ-002 |
| §11.10(e) | Audit Trails | OQ-AT-001–005; OQ-EX-004; PQ-004,010 |
| §11.30 | Open Networks / Encryption | IQ-005,006; OQ-SC-001 |
| §11.50 | Signature Manifestations | OQ-SIG-001,003; PQ-001 |
| §11.70 | Signature Linkage to Record | OQ-SIG-002,005; OQ-TS-002; PQ-010 |
| §11.100 | Signature Uniqueness | OQ-SIG-004; PQ-003 |
| §11.200 | Signature Components | OQ-AC-001,003; OQ-SIG-001 |
| §11.300 | Signature Controls | OQ-AC-002; OQ-SIG-004 |
Appendix B: Deviation Log Template
A reusable template for recording and tracking deviations discovered during validation execution.
Use one form per deviation. Assign sequential deviation numbers: DEV-[DocumentNumber]-[SequentialNumber] (e.g., DEV-VLD-ELAB-001-01).
| Field | Value |
|---|---|
| Deviation Number | DEV-_________________ |
| Date of Deviation | [__ / __ / ____] |
| Validation Phase | IQ / OQ / PQ (circle one) |
| Test Case ID | [e.g., OQ-SIG-001] |
| Step Number | [Step ____] |
| Description of Deviation | [Describe exactly what occurred vs. what was expected: ________________________] |
| Expected Result (from protocol) | [Exact text from Expected Result column: ___________________________________] |
| Actual Result Observed | [Exact text of what was observed: ___________________________________________] |
| Deviation Classification | Critical / Major / Minor (circle one) |
| Immediate Impact Assessment | [Does this deviation prevent system use for GxP records? Yes / No. Justification: ___] |
| Root Cause Investigation | [Describe root cause: ________________________________________________________] |
| CAPA Required | Yes / No (circle one) |
| CAPA Description (if required) | [Describe corrective and preventive action taken: _____________________________] |
| Retest Required | Yes / No (circle one) |
| Retest Result | PASS / FAIL / N/A (circle one) |
| Resolution Date | [__ / __ / ____] |
| QA Approval | [QA Reviewer Name / Signature / Date] |
Appendix C: Abbreviations and Definitions
Defines abbreviations and terms used throughout this manual.
| Abbreviation / Term | Definition |
|---|---|
| ALCOA+ | Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available — data integrity framework. |
| CAPA | Corrective and Preventive Action. Documented response to a deviation, identifying root cause and actions to prevent recurrence. |
| CFR | Code of Federal Regulations (United States). |
| CSV | Computer System Validation. The formal process for demonstrating that a computerized system consistently produces a result meeting predetermined specifications. |
| ELN | Electronic Laboratory Notebook. |
| GAMP 5 | Good Automated Manufacturing Practice guidance for validation of automated systems, published by ISPE. Version 5 (2nd Edition) is the current reference. |
| GLP | Good Laboratory Practice. |
| GMP | Good Manufacturing Practice. |
| GxP | Collective term for Good [x] Practices (GLP, GMP, GCP, etc.). |
| IQ | Installation Qualification — documented verification that equipment/software has been installed correctly. |
| MFA | Multi-Factor Authentication — authentication requiring two or more verification factors. |
| OQ | Operational Qualification — documented verification that equipment/software operates according to its specifications. |
| PQ | Performance Qualification — documented verification that equipment/software consistently performs according to specifications under actual conditions of use. |
| RFC 3161 | Internet Standard for trusted timestamping, providing independent third-party verification of document existence at a specific time. |
| SOC 2 | Service Organization Control 2 — audit standard for service providers covering security, availability, processing integrity, confidentiality, and privacy. |
| TSA | Timestamp Authority — a trusted third party that issues RFC 3161 timestamp tokens. |
| URS | User Requirements Specification — document defining the functional and non-functional requirements that a system must meet. |
| 21 CFR Part 11 | Title 21 of the U.S. Code of Federal Regulations, Part 11 — Electronic Records; Electronic Signatures. FDA regulation. |
Appendix D: Referenced Documents
Lists documents referenced by or supporting this validation manual.
| Document | Author | Reference / Location |
|---|---|---|
| 21 CFR Part 11 (1997) | FDA | Electronic Records; Electronic Signatures. 62 FR 13430. https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11 |
| FDA Guidance — Part 11, ERR, ES (2003) | FDA | Guidance for Industry: Part 11, Electronic Records; Electronic Signatures — Scope and Application. https://www.fda.gov/regulatory-information/search-fda-guidance-documents |
| FDA Guidance — Computerized Systems in Clinical Investigations (1999) | FDA | Guidance for Industry: Computerized Systems Used in Clinical Investigations. |
| GAMP 5 (2nd Edition, 2022) | ISPE | Good Automated Manufacturing Practice (GAMP) 5: A Risk-Based Approach to Compliant GxP Computerized Systems. |
| ICH Q9(R1) Quality Risk Management | ICH | Harmonised Tripartite Guideline — Quality Risk Management. |
| LabLynx One User Manual v3.0 | LabLynx | Complete feature reference for users. Produced by LabLynx, Inc. |
| LabLynx One Administrator Manual v1.0 | LabLynx | Team and system administration reference. Produced by LabLynx, Inc. |
| LabLynx One Developer Manual v1.0 | LabLynx | REST API reference and integration guide. Produced by LabLynx, Inc. |
| LabLynx One IT Admin Manual v1.0 | LabLynx | Software stack, installation, and technical specifications. Produced by LabLynx, Inc. |
| RFC 3161 — Time-Stamp Protocol (TSP) | IETF | Internet X.509 Public Key Infrastructure Time-Stamp Protocol. https://www.rfc-editor.org/rfc/rfc3161 |
LabLynx One — IQ/OQ/PQ Validation Manual | VLD-ELAB-001
21 CFR Part 11 / GAMP 5 Category 4
LabLynx, Inc. | www.lablynx.com | support@lablynx.com | www.elabeln.com
© 2026 LabLynx, Inc. | CONFIDENTIAL — CONTROLLED DOCUMENT | All rights reserved.
LabLynx, Inc. | www.elabeln.com | support@lablynx.com Page
LabLynx, Inc. | www.elabeln.com | support@lablynx.com Page
LabLynx One FDS Roadmap
A twelve-module laboratory operations suite proposed for LabLynx One — using the native Team construct, renamed Experiments and Resources, and custom API-integrated plugin apps. Template catalogs and module scope are designed to evolve as each Team is configured.
This section describes a proposed future architecture for LabLynx One. It is a living planning document, not a specification of currently shipped functionality — nothing here should be read as available today.
The LabLynx One Concept
Before profiling each of the twelve modules, this section establishes the architectural pattern all twelve share: a single LabLynx One platform, the compliant hosting layer it runs on, one Team per module, a consistent approach to renaming Experiments and Resources, and a plugin app framework that fills native gaps with purpose-built UI/UX.
What Is LabLynx One?
LabLynx One is not a new product built from scratch. It is a solution profile — a deliberate configuration of LabLynx's proven platform into twelve functionally distinct, purpose-built modules, each operating as its own Team, extended where necessary with custom plugin apps.
Why One Platform Instead of Twelve Separate Products
Most laboratories assemble their operational stack from separate point solutions: a LIMS from one vendor, an ELN from another, a document management system from a third, a training-tracking spreadsheet, an asset register, and so on. Each integration is a maintenance burden, each vendor is a separate contract and support relationship, and each system has its own login, its own permission model, and its own idea of what a "sample," a "document," or a "user" is.
LabLynx One starts from a different premise: LabLynx One's underlying data model — Experiments, Resources, Teams, templates, custom metadata fields, electronic signatures, and a RESTful API — is general-purpose enough to be reconfigured, renamed, and extended into twelve distinct operational functions without requiring twelve distinct pieces of software. The result is one login, one audit trail, one permissions model, one API, and one unlimited-user license underneath every module a lab runs.
Every module in this profile is the same LabLynx One instance, configured differently. A user moving from the Quality Management Team to the Instrument & Asset Management Team is still in LabLynx One — but the templates, terminology, permissions, and (where a plugin app is installed) the UI itself are tailored specifically to that function.
The Layered Architecture
Everything in this document sits at one of five layers, each building on the one below it. It's worth seeing the whole stack once, up front, before diving into any single Part:
The Twelve Modules at a Glance
Who This Profile Is For
This document serves two audiences at once: it is a sales and positioning asset explaining what LabLynx One is and why a lab would want it, and it is a working functional design specification — a build reference for how each module's LabLynx One Team should actually be configured, what its Experiment and Resource templates should look like, and where a plugin app is required to close a gap the native platform doesn't cover. Expect the FDS chapters (Part II) to read more like a build document than marketing copy.
Compliant Hosting Platform
Every Team, every module, and every plugin app described in this profile runs on top of a hosting layer built specifically for regulated laboratory environments. LabLynx offers exactly two deployment options — sciCloud.net, the standard managed cloud, and LabServer, the on-premises appliance for labs that can't or won't put their data in the cloud. Both run the identical LabLynx One software stack.
sciCloud.net — The Standard Deployment
sciCloud.net is LabLynx's purpose-built laboratory informatics hosting platform — not a generic cloud host repurposed for lab data, but infrastructure designed from the ground up around FAIR data principles (Findable, Accessible, Interoperable, Reusable), regulatory compliance at the infrastructure level, and the identity and access control requirements of multi-application laboratory environments. It is the standard hosting solution for every LabLynx One deployment, not an option reserved for a subset of clients.
| Infrastructure Characteristic | Specification |
|---|---|
| Cloud Provider | Amazon Web Services (AWS) — US East and West regions |
| Tenant Architecture | Dedicated tenant per organization — no shared database infrastructure between clients |
| Uptime SLA | 99.8% availability, with real-time monitoring from multiple global locations |
| Backup Schedule | Hourly incremental backups; daily full backups with geographically distributed secondary storage |
| Disaster Recovery | Documented RTO/RPO with tested failover procedures |
| Encryption at Rest | AES-256 via AWS Key Management Service (KMS) |
| Encryption in Transit | TLS 1.2 or higher for all browser-to-server and API communications |
| Authentication | SAML 2.0 SSO via OpenSocial; MFA configurable and enforceable system-wide; LDAP integration supported |
| Access Control | Role-based access control at user, group, project, and site levels; semi-annual access reviews |
| Infrastructure Certification | AWS SSAE 18 SOC 2-certified data centers; AWS SOC 3 public attestation available |
| Annual Security Audit | Independent third-party audit against all 20 NIST SP 800-53 control families, and Virginia SEC530 |
sciCloud.studio — The Dev/Sec/Ops Layer Behind It
Underneath the hosting environment itself sits sciCloud.studio — the development, security, and operations framework that governs every application running on sciCloud.net. Because sciCloud.net is the standard hosting solution for the entire client base rather than a subset, sciCloud.studio's controlled release process applies uniformly across every LabLynx One deployment.
- Controlled release management — every update is tested, documented, and released through formal change management before it reaches a client environment
- Security testing integration — automated security scanning and penetration testing are built into the development pipeline, not bolted on after release
- Configuration management — complete configuration records for every client environment, supporting IQ/OQ/PQ validation documentation and change-impact assessment
- Quality assurance — every deliverable, from software releases to validation documents to training materials, passes quality review before release
LabServer — On-Premises Deployment
LabServer is the on-premises alternative: a pre-configured hardware/software appliance running the identical LabLynx One software stack within a laboratory's own network, data center, or air-gapped environment. It exists specifically for the minority of labs where cloud hosting isn't viable, not as a lesser-featured fallback — the software, the API, and the validation documentation are the same either way.
Government, defense, and intelligence-community labs handling classified or controlled unclassified information can run LabServer entirely on the local network — no data ever leaves the facility.
Organizations subject to regulations prohibiting cloud storage of specific data types can deploy LabServer within a facility they own and operate, maintaining full control over physical data location.
Large enterprises with existing IT management frameworks and a preference for capital-expenditure deployment can bring LabLynx One under their own monitoring and backup infrastructure.
Labs awaiting cloud-system regulatory approval can deploy LabServer to operate immediately while cloud authorization is pursued in parallel.
LabServer Technical Specifications
| Characteristic | Specification |
|---|---|
| Hardware | Pre-configured compact server appliance, shipped ready for rack or desktop installation; standard Ethernet networking; serial and USB ports for instrument connectivity |
| Software Stack | Identical to the sciCloud.net hosted edition — same applications, same REST API endpoints, same authentication, same validation documentation |
| Backup Options | Customer-managed local backup to NAS/SAN, or LabLynx-managed cloud backup where internet connectivity is available |
| Deployment Timeline | Typically 2–4 weeks, dependent on the customer's IT environment complexity (vs. under 1 week for standard sciCloud.net onboarding) |
| Updates & Patching | Managed by LabLynx on customer schedule, or by customer IT staff via offline update packages for air-gapped deployments |
When LabServer is deployed, it also serves as the LabVia Hub (Chapter 19) — the on-site hardware component for instrument connectivity. One appliance runs the platform and manages direct instrument connections, eliminating the need for separate hardware and separate IT procurement and qualification cycles.
Choosing Between Them
The overwhelming majority of LabLynx One deployments use sciCloud.net — it deploys faster, carries no IT infrastructure burden, and is operationally superior for most laboratories. LabServer exists specifically for the air-gapped, data-sovereignty, and IT-governance cases above, not as a general-purpose alternative. Either way, the choice of hosting layer is independent of which of the twelve modules or five add-on applications a lab activates — it's a decision about where the platform runs, not what it runs.
The Teams-as-Modules Architecture
LabLynx One's native Team construct is the single mechanism that makes LabLynx One possible. Each of the twelve modules is configured as its own Team, with its own membership, its own permission boundaries, and its own template library — while remaining part of one unified instance.
What a Team Natively Provides
In stock LabLynx One, a Team is a workspace boundary: it scopes which Experiments, Resources, templates, and tags a group of users can see and act on, and it supports its own administrators, its own category/status lists, and its own permission rules layered on top of the platform-wide role hierarchy (Admin / Team Leader / User). This is ordinarily used to separate research groups or departments. LabLynx One repurposes the same mechanism to separate functions instead of departments.
Cross-Team Membership Is the Norm, Not the Exception
Most lab staff will belong to more than one Team. A bench analyst is likely a member of the LIMS, ELN, and Logbooks Teams; a quality manager is likely a member of Quality Management, Document Management, and Training Tracking; a lab director may hold Team Leader rights across several. LabLynx One's multi-Team membership model supports this natively — the architecture decision is simply which Teams exist and what each one is configured to do.
One Team is the exception to that architecture decision: the Dashboard Team (Chapter 6) has no selective membership at all. Every user is added to it automatically the moment their account is created, precisely because its entire purpose is to reflect back whichever other Teams that person happens to belong to — it has to be universal to do that job.
Design Consistency Across the Twelve Teams
To keep twelve independently configured Teams from drifting into twelve inconsistent experiences, every module in this profile follows the same underlying conventions: a common naming pattern for renamed Experiments/Resources (Chapter 4), a common approach to when and how a plugin app is introduced (Chapter 5), and a common FDS structure (Part II) covering configuration, templates, roles, compliance, integration, and KPIs. This consistency is what keeps LabLynx One feeling like one coherent product rather than twelve unrelated configurations of the same software.
Renaming the Core Objects
Every LabLynx One Team is built from the same two core object types — Experiments and Resources — plus their categories, statuses, and tags. LabLynx One's design pattern renames these objects per module so that each Team's terminology matches the function it performs, without altering the underlying data model.
The General Renaming Pattern
In LabLynx One, an Experiment is a dated, signable, templated record with a body, custom metadata fields, linked items, and a status — the platform's event/activity object. A Resource is a persistent, categorized, non-dated record — the platform's registry/inventory object. Every module in this profile maps its core function onto one or both of these objects and renames them accordingly in that Team's configuration (category labels, template names, and — where a plugin app is installed — the UI chrome itself).
| Native LabLynx One Object | General Role | Typical Rename Pattern |
|---|---|---|
| Experiment | Dated, signable, workflow-driven record | Test Order, Notebook Entry, Log Entry, Course Completion, Controlled Doc Revision, Deviation/CAPA, Work Order, Transaction, Portal Request |
| Resource | Persistent, categorized registry item | Sample/Specimen, Protocol, Logbook, Course/Curriculum, Controlled Document, Quality Record Type, Instrument/Asset, Inventory Item, Portal Widget |
| Category | Grouping/classification layer | Test Panel, Experiment Type, Log Type, Course Category, Document Type, Quality Record Class, Asset Class, Item Class, Portal Section |
| Status | Workflow state | Module-specific lifecycle (e.g., Received → In Testing → Reviewed → Reported for LIMS; Draft → Review → Approved → Locked for Document Management) |
| Tag | Free-form cross-cutting label | Generally retained as-is across modules for cross-Team searchability |
Renaming preserves every native LabLynx One capability — templating, custom metadata fields, e-signatures, audit trail, versioning, linking, the API — while presenting each Team with terminology that matches how its users actually think and talk. A calibration technician should see "Instrument," not "Resource"; a document controller should see "Controlled Document," not "Resource." The data model doesn't change; the label does.
Where the Detail Lives
The full, module-by-module renaming map — every Experiment and Resource label, per Team — is documented in each module's FDS chapter (Part II, "Object Renaming Map") and consolidated for quick reference in Appendix A.
The Plugin App Framework
Renaming closes the terminology gap. It does not close every functional gap. Where a module's requirements exceed what native templates, fields, and workflows can reasonably deliver, this profile calls for a custom plugin app — a purpose-built UI/UX layer that talks to LabLynx One entirely through its existing RESTful API.
When a Plugin App Is Warranted
How a Plugin App Talks to LabLynx One
Every plugin app in this profile is architected as a thin client against LabLynx One's native RESTful API — it authenticates as a service account or on-behalf-of a logged-in user, reads and writes Experiments/Resources/metadata/tags/uploads through documented endpoints, and never bypasses LabLynx One's own permission, audit-trail, or e-signature logic. The plugin supplies the UI; LabLynx One remains the single system of record. This is detailed further in Chapter 38.
A hard architectural rule for this profile: no plugin app maintains its own independent database of record. Every plugin reads from and writes back to LabLynx One via API. This keeps the audit trail, e-signature chain, and reporting layer unified across all twelve modules even when three or four of them have custom front-ends.
Plugin Apps Proposed in This Profile
Each module's FDS chapter (Part II) specifies its own plugin app under "Plugin App Specification," including its purpose, its proposed UI/UX, and the API endpoints/webhooks it depends on. As a preview, plugin apps are proposed for Dashboard (the universal home screen and module launcher every user lands on), LIMS (sample intake & chain-of-custody console), LIS (patient order & result console with critical-value workflow), LES (a coordinated suite spanning guided step-by-step execution, live calculation, in-process control checking, and real-time deviation capture), Quality Management (CAPA/nonconformance workflow board), Instrument & Asset Management (calibration/maintenance calendar and asset map), Inventory Management (reorder dashboard and barcode receiving console), and the Lab Portal (external client-facing request and results portal). The remaining modules (ELN, Logbooks, Training Tracking, Document Management) are assessed as sufficiently served by native LabLynx One with lighter-weight UI accents rather than a full plugin build — a determination each chapter explains under "Functional Gaps Identified."
Cross-Cutting Platform Plugin Apps
The plugin apps above are each scoped to a single module's specific job. A second category of plugin app cuts across every Team instead — general-purpose capability that any module can draw on, built once against the API and reused everywhere rather than rebuilt per Team. These are proposed as shared, platform-wide plugin apps available to whichever Teams need them.
Cross-cutting plugin apps follow the identical architectural pattern established earlier in this chapter: they talk to LabLynx One entirely through the RESTful API, authenticate on-behalf-of the requesting user so they never expose more than that person's existing permissions already allow, and never maintain an independent database of record. Being reusable across Teams doesn't change the rule that LabLynx One remains the single system of record.
The Twelve Modules — Functional Design Specifications
Each chapter that follows profiles one module as its own LabLynx One Team. Every chapter follows the same eleven-part structure so the twelve modules stay directly comparable: overview, Team configuration, object renaming, native capabilities, functional gaps, plugin app specification, template catalog, roles, compliance, integration points, and KPIs.
Dashboard
The Dashboard Team is the one Team every single user in LabLynx One belongs to. Where every other module is scoped to a function some staff perform, the Dashboard module is scoped to a person — it is the home screen a user lands on at login, showing which modules they can reach and what their work looks like across every Team they're actually a member of.
Module Overview & Positioning
Every other Team in this profile answers "what work happens here." The Dashboard Team answers a different question: "what does my day look like across all of the Teams I belong to?" It is the first thing a user sees when they log in, and it is deliberately built almost entirely as a plugin app rather than as native LabLynx One screens — because its entire job is to reach across Team boundaries and pull together a single, personalized view, something the native per-Team UI was never designed to do.
Positioned this way, Dashboard is the internal counterpart to the Lab Portal (Chapter 17): the Lab Portal is the unified front door for people outside the lab, and the Dashboard is the unified front door for people inside it. Both are aggregation layers built primarily as plugin apps over the same underlying Teams; they differ in audience, in what they're allowed to see, and in how they authenticate against the API (detailed in Chapter 20).
Every other Team in this profile has deliberate, functional membership — a person joins the Quality Management Team because their job touches quality records. The Dashboard Team breaks that pattern on purpose: membership is automatic and universal. Every user account, at the moment it's created, is added to the Dashboard Team with no action required by an administrator. This is what guarantees nobody ever logs in to a blank screen.
Team Configuration
- Team name: Dashboard. Unlike the other twelve Teams, this one has no sub-groupings by department or discipline — everyone is a Member of the same single Team.
- Permission model: Member (automatic for every user — views their own personalized dashboard only), Dashboard Content Admin (publishes lab-wide announcements and manages default widget layouts per role), Team Leader (full configuration).
- Status workflow: this Team's own native records are lightweight — primarily Announcements, which follow Draft → Published → Expired. The "work" a user sees on their dashboard isn't native to this Team at all; it's pulled live, in real time, from whatever other Teams that specific user belongs to.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Experiment | Announcement / Notice | A dated, lab-wide broadcast item (e.g., "Instrument down for maintenance," "New SOP published") |
| Resource | Saved View / Widget Configuration | A user's or role's personalized dashboard layout |
| Resource | Role-Based Default Layout | The out-of-the-box widget set shown to a new user based on their role |
| Experiment Category | Announcement Type | Maintenance, policy, training, general |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native cross-Team aggregation or summary view — LabLynx One's UI is built around one Team at a time, not a rollup across several.
- No native module launcher that reflects which Teams a specific logged-in user actually belongs to.
- No native "my open items" queue spanning multiple Teams (e.g., open test orders, pending quality cases, and expiring qualifications shown together).
- No native lab-wide announcement/notice surfaced automatically at login.
- No native personalization — pinning, reordering, or hiding widgets on a per-user basis.
Plugin App Specification
The Dashboard Plugin App is presented as the main menu / home screen of the entire LabLynx One experience — the first screen after login, and the one persistent "home" link available from anywhere in the system. Unlike the module-specific plugins in Part II (which sit alongside their native Team), Dashboard's plugin largely is the module — the native Team underneath mainly exists to hold Announcements and layout preferences.
- → One tile per Team the logged-in user belongs to
- → Generated dynamically from actual membership — never shows a locked tile for a Team the user can't access
- → One click opens that Team's native LabLynx One view or its plugin app
- → Open test orders assigned to me (LIMS/LIS)
- → Pending quality cases assigned to me (Quality Management)
- → Qualifications expiring soon (Training Tracking)
- → Documents awaiting my review (Document Management)
- → Calibrations/maintenance due on assets I own (Instrument & Asset Mgmt)
- → Low-stock items I manage (Inventory Management)
- → Published Announcements shown by priority/audience
- → Read/acknowledgment tracking for policy-critical notices
- → Pin, reorder, or hide individual widgets
- → Role-based default layout on first login
This is the single most important architectural rule for this module: every "My Work Summary" query the Dashboard plugin runs must authenticate as the logged-in user, not as an elevated service account, so a person only ever sees exactly what they'd see by visiting each Team directly — never more. This is a different pattern than the Lab Portal's aggregation (which authenticates as a scoped service account to assemble one external client's cross-Team view). The two module's plugins share an architecture but not a permission model, and the distinction matters for security: Dashboard must never become a backdoor to data a user couldn't otherwise reach.
Experiment & Resource Template Catalog
This module's own template catalog is intentionally small — its value comes from what it reads from the other twelve Teams, not from records it originates itself.
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Lab-Wide Announcement | Experiment | Announcement Type | Broadcasts a dated notice to all or targeted users | Priority, audience/role targeting, expiration date | Draft → Published → Expired | — |
| Personal Widget Configuration | Resource | Saved View | Stores one user's pinned/reordered widget layout | Widget list, order, visibility | Active | — |
| Role-Based Default Layout | Resource | Role-Based Default Layout | Defines the out-of-the-box widget set for a given role | Role, default widget list | Active → Retired | — |
Roles & Permissions
| Role | View Own Dashboard | Publish Announcements | Manage Default Layouts | Configure Team |
|---|---|---|---|---|
| Member (every user, automatic) | ✓ | — | — | — |
| Dashboard Content Admin | ✓ | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
This module's primary compliance concern isn't a regulatory framework specific to lab testing — it's the security discipline described above: a cross-Team aggregation view must never expose more than the user's own existing permissions already allow. Published Announcements still carry a full audit trail of authorship and edit history like any other Experiment.
Integration Points with Other Modules
Dashboard reads — but does not write to — every other Team a given user belongs to: LIMS and LIS open orders, Quality Management assigned cases, Training Tracking expiring qualifications, Document Management pending reviews, Instrument & Asset Management due calibrations, Inventory Management low-stock alerts, and more, as a lab's specific Team configuration warrants. It is the one module whose "Integration Points" section is, by design, every other module in this profile.
Success Metrics / KPIs
- Percentage of user sessions that begin at the Dashboard rather than a bookmarked deep link
- Average time from login to reaching the needed task (time-to-task)
- Announcement read/acknowledgment rate
- Widget personalization adoption rate
LIMS
The LIMS Team turns LabLynx One's Experiment/Resource model into a sample-centric laboratory information management system — accessioning, chain of custody, test ordering, results, and reporting — for labs that need core LIMS functionality without a second platform.
Module Overview & Positioning
The LIMS module positions LabLynx One as the sample-of-record system: every physical sample entering the lab is accessioned as a renamed Resource, every test performed against it as a renamed Experiment, with pass/fail comparison against renamed specification Resources. This is the module most dependent on a plugin app, since native LabLynx One's Experiment/Resource pairing was not originally built around high-volume, barcode-driven sample accessioning.
LabLynx One's LIMS is scoped for small-to-mid-volume labs needing core accessioning, chain-of-custody, worklist, and reporting functionality — not for high-throughput clinical or pharmaceutical operations requiring deep instrument autoverification and complex reflex-testing logic, which remain better served by LabLynx's dedicated ELabLiMS product.
Team Configuration
- Team name: LIMS, with sub-groupings by department where a lab runs multiple test disciplines (e.g., Chemistry, Microbiology).
- Permission model: Accessioning Staff (create/edit samples), Analysts (enter results, cannot release), Reviewers/Approvers (e-sign and release), Team Leader (full configuration rights).
- Status workflow: Received → Accessioned → In Testing → Pending Review → Reviewed → Reported → Archived.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Sample / Specimen | One Resource record per accessioned sample; category = sample type |
| Resource | Specification / Limits Set | Reference Resource holding pass/fail criteria per test/product |
| Experiment | Test Order / Result Record | One Experiment per test performed against a Sample |
| Experiment Category | Test Panel | Groups related tests ordered together |
| Resource Category | Sample Matrix / Sample Type | Water, soil, blood, product, etc. |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native barcode-driven accessioning console — sample intake would otherwise mean manually creating a Resource per sample.
- No native automated pass/fail comparison against a specification Resource — this comparison must be presented and computed for the user rather than relying on manual lookup.
- No native chain-of-custody transfer log purpose-built for multi-handler sign-off chains.
- No native worklist/batch view grouping samples by instrument, method, or due date.
Plugin App Specification
A Sample Accessioning & Chain-of-Custody Console is proposed: a purpose-built UI presented to Accessioning Staff and Analysts, reading/writing to LabLynx One's Resource and Experiment endpoints, that overlays barcode scanning, automatic specification comparison, and a worklist view on top of the native Team.
- → Barcode/label scan to create Sample
- → Auto-populated metadata from pre-registration
- → Receipt variance check against order
- → Print label on save
- → Group by instrument, method, or due date
- → Batch status roll-up
- → One-click export to instrument
- → Auto pass/fail against linked spec Resource
- → Flag out-of-spec for review routing
- → Qualifier support (<, >, ±)
- → Sequential handler sign-off
- → Timestamp per transfer
- → External transfer certification capture
Experiment & Resource Template Catalog
The following is a starter catalog for the LIMS Team — sufficient to launch, expected to grow as new sample types and test panels are onboarded. Each row follows the standard schema: name, type, category, purpose, key metadata, workflow states, and linked modules.
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Standard Sample Accession | Resource | Sample Intake | General-purpose sample registration | Client, matrix, collection date/site, container type | Received → Accessioned | Inventory (containers) |
| Environmental Water Sample | Resource | Sample Intake | Water-specific accessioning | Site code, sampler, temperature at receipt, preservative | Received → Accessioned | Lab Portal |
| Composite/Bulk Sample | Resource | Sample Intake | Multi-source composite accessioning | Source list, compositing method | Received → Accessioned | — |
| General Chemistry Test Order | Experiment | Test Panel | Routine chemistry test recording | Method, instrument, analyst, dilution factor | Ordered → In Testing → Reviewed → Reported | Instrument & Asset Mgmt |
| Microbiology Test Order | Experiment | Test Panel | Plate/culture-based test recording | Media lot, incubation time/temp, colony count | Ordered → In Testing → Reviewed → Reported | Inventory (media lots) |
| Specification/Limits Set — Product | Resource | Reference | Pass/fail criteria per product | Limit values, units, effective date range | Draft → Approved → Superseded | Quality Management |
| Specification/Limits Set — Regulatory | Resource | Reference | Pass/fail criteria per regulation | Regulation citation, limit values, jurisdiction | Draft → Approved → Superseded | Quality Management |
| Chain-of-Custody Transfer Log | Experiment | Custody | Records each custody handoff | From/to handler, timestamp, condition at transfer | Open → Closed | — |
| Retest/Resample Request | Experiment | Exception | Documents justification for retesting | Original result reference, reason code | Requested → Approved → Completed | Quality Management |
| Certificate of Analysis (COA) | Experiment | Reporting | Final client-facing report generation | Sample list, result summary, release signature | Draft → Approved → Released | Lab Portal, Document Mgmt |
| Sample Disposal/Retention Record | Experiment | Retention | Tracks retention period and disposal | Retention date, disposal method, authorizer | Active → Eligible → Disposed | — |
| Recurring/Scheduled Sampling Program | Resource | Program | Defines a repeating sampling schedule | Frequency, site list, test panel | Active → Suspended → Retired | Lab Portal |
Roles & Permissions
| Role | Create/Edit Samples | Enter Results | Approve/Release | Configure Team |
|---|---|---|---|---|
| Accessioning Staff | ✓ | — | — | — |
| Analyst | ✓ | ✓ | — | — |
| Reviewer/Approver | ✓ | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Electronic signatures at result-entry and result-release satisfy Part 11 intent; the linked specification model and full audit trail support ISO 17025 traceability expectations for accredited testing labs.
Integration Points with Other Modules
Feeds Certificates of Analysis to Document Management; routes out-of-spec results to Quality Management for CAPA; consumes calibration status from Instrument & Asset Management to gate instrument selection; consumes reagent/media lot data from Inventory Management; surfaces order status to the Lab Portal for client-facing visibility.
Success Metrics / KPIs
- Average turnaround time from accession to report
- Percentage of results auto-compared to specification without manual lookup
- Chain-of-custody exceptions per 1,000 samples
- Retest/resample rate
LIS
The LIS Team configures LabLynx One as a patient-testing laboratory information system — physician/EHR order intake, patient and specimen identity, clinical result reporting, and critical-value notification — for labs whose testing is performed on human patients rather than industrial, environmental, or research samples.
Module Overview & Positioning
Where the LIMS module (Chapter 7) is built around industrial, environmental, and general testing samples, the LIS module is built around the specific workflow of clinical/patient testing: an order originates from a physician or an EHR rather than a client submission, the "sample" is a patient specimen tied to a positively identified individual, and the output is a clinical result that may trigger critical-value callback obligations rather than a standard Certificate of Analysis. This module is scoped for labs running routine clinical testing — hospital-affiliated, reference, or independent clinical labs — and is designed to interoperate with LabLynx's broader platform for labs that also run non-clinical testing through the LIMS module side by side.
Because patient identity, order provenance, and result reporting carry legal and clinical-safety weight beyond general LIMS testing, this module places heavier emphasis on positive patient identification, order/result interfacing with external systems (EHRs, physician portals), and time-sensitive critical-value notification — all areas where a dedicated plugin app is warranted.
Team Configuration
- Team name: LIS, with sub-groupings by discipline where a lab runs multiple clinical testing sections (e.g., Chemistry, Hematology, Microbiology, Molecular).
- Permission model: Accessioning/Registration Staff (register patients and specimens), Clinical Analysts (enter results, cannot release), Pathologist/Clinical Reviewer (e-sign and release results, including critical values), Team Leader (full configuration rights).
- Status workflow: Ordered → Specimen Collected → Received/Accessioned → In Testing → Pending Review → Reviewed/Released → Reported → Amended (if applicable).
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Patient Specimen | One Resource per accessioned patient specimen; category = specimen type |
| Resource | Patient Record (Demographic Reference) | Reference Resource holding patient identity and demographic data |
| Resource | Reference Range / Clinical Limits Set | Age/sex-adjusted normal ranges and critical-value thresholds per analyte |
| Experiment | Clinical Test Order / Result Record | One Experiment per test performed against a Patient Specimen |
| Experiment | Physician Order | Captures the originating order, ordering provider, and clinical indication |
| Experiment Category | Test Panel / Clinical Discipline | Chemistry, Hematology, Microbiology, Molecular, etc. |
| Resource Category | Specimen Type | Blood, urine, tissue, swab, etc. |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native positive patient identification (two-identifier match) console for specimen registration.
- No native HL7/EHR order-intake and result-transmission interface — orders and results must otherwise be entered and delivered manually.
- No native automated critical-value flagging against age/sex-adjusted reference ranges, or callback/notification workflow with required read-back documentation.
- No native cumulative patient result report (multiple dates/tests for one patient in a single trended view).
Plugin App Specification
A Patient Order & Result Console is proposed: a purpose-built UI for Accessioning/Registration Staff and Clinical Analysts that overlays positive patient identification, HL7-based order intake and result transmission, automated critical-value detection with callback documentation, and cumulative reporting on top of the native LIS Team — reading and writing to LabLynx One's Resource and Experiment endpoints throughout.
- → Two-identifier positive ID check at specimen collection
- → Auto-populated demographics from HL7 ADT feed
- → Specimen label printing on save
- → Inbound ORM order intake from EHR
- → Outbound ORU result transmission
- → Order/result reconciliation queue
- → Auto-flag against reference range Resource
- → Required callback documentation (who, when, read-back confirmation)
- → Escalation timer if not acknowledged
- → Trended multi-date result view per patient
- → Flag out-of-range values across visits
Experiment & Resource Template Catalog
The following is a starter catalog for the LIS Team — sufficient to launch, expected to grow as new specimen types and clinical test panels are onboarded.
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Standard Patient Specimen Accession | Resource | Specimen Type | General-purpose patient specimen registration | Patient ID, two-identifier match, collection date/time, specimen type | Ordered → Collected → Accessioned | Lab Portal |
| Blood/Serum Specimen | Resource | Specimen Type | Blood draw-specific accessioning | Draw site, tube type, fasting status | Collected → Accessioned | — |
| Microbiology Culture Specimen | Resource | Specimen Type | Culture/swab specimen accessioning | Collection site, transport medium | Collected → Accessioned | Inventory Management |
| Physician Order | Experiment | Order | Captures the originating clinical order | Ordering provider, clinical indication, priority (STAT/routine) | Received → Acknowledged | Lab Portal |
| Clinical Chemistry Test Order | Experiment | Test Panel: Chemistry | Routine clinical chemistry result recording | Method, instrument, analyst, reference range applied | Ordered → In Testing → Reviewed → Reported | Instrument & Asset Mgmt |
| Hematology Test Order | Experiment | Test Panel: Hematology | CBC/differential and related result recording | Instrument, flagged parameters | Ordered → In Testing → Reviewed → Reported | Instrument & Asset Mgmt |
| Microbiology Culture & Sensitivity Order | Experiment | Test Panel: Microbiology | Culture identification and susceptibility result recording | Organism identified, sensitivity panel results | Ordered → In Testing → Reviewed → Reported | Inventory Management |
| Reference Range / Clinical Limits Set | Resource | Reference | Age/sex-adjusted normal and critical-value thresholds | Analyte, low/high normal, critical low/high | Draft → Approved → Superseded | Quality Management |
| Critical Value Callback Record | Experiment | Critical Value | Documents notification of a critical result | Notified party, time of call, read-back confirmation | Flagged → Notified → Closed | Quality Management |
| Result Amendment/Correction | Experiment | Amendment | Documents a correction to a previously reported result | Original result reference, reason, notified parties | Requested → Approved → Amended | Quality Management |
| Patient Report (Cumulative) | Experiment | Reporting | Final clinical report generation, single or cumulative | Result summary, release signature, recipient | Draft → Approved → Released | Lab Portal, Document Mgmt |
| Specimen Rejection Record | Experiment | Exception | Documents rejection of an unsuitable specimen | Rejection reason, notified provider | Rejected → Recollection Requested | Quality Management |
Roles & Permissions
| Role | Register Patients/Specimens | Enter Results | Approve/Release | Configure Team |
|---|---|---|---|---|
| Accessioning/Registration Staff | ✓ | — | — | — |
| Clinical Analyst | ✓ | ✓ | — | — |
| Pathologist/Clinical Reviewer | ✓ | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Positive patient identification, critical-value notification with documented read-back, and result amendment procedures are named, specific requirements under CLIA and CAP clinical laboratory accreditation; patient demographic data throughout this module falls under HIPAA's data-privacy and access-control obligations.
Integration Points with Other Modules
Feeds Patient Reports to Document Management for retention and to the Lab Portal for referring-physician/patient access where applicable; routes specimen rejections and critical-value escalations to Quality Management; consumes calibration status from Instrument & Asset Management to gate instrument selection; consumes reagent/media lot data from Inventory Management; verifies analyst competency via Training Tracking before allowing result entry on regulated assays.
Success Metrics / KPIs
- Average turnaround time from order to result release, by priority (STAT vs. routine)
- Critical-value notification time from flag to documented callback
- Specimen rejection rate
- Result amendment rate
LES
The LES Team turns an approved procedure into a live, gated execution engine — walking an analyst through a method step by step, in real time, and refusing to let them proceed until each step's requirements are actually satisfied. Where Document Management owns the approved text of a procedure and LIMS/LIS own the final result, LES owns the moment-by-moment act of performing it correctly.
Module Overview & Positioning
LES sits deliberately between three modules it's often confused with. Document Management (Chapter 12) stores the approved SOP as static, versioned text — a person could still deviate from it and nothing in the document itself would stop them. ELN (Chapter 10) is narrative and retrospective — a scientist writes up what they did after, or while, doing it, but nothing forces the write-up to match a prescribed sequence. LIMS and LIS (Chapters 6–7) own the sample, the order, and the final result, but neither was built to gate the in-between steps of producing that result. LES is the module that closes that gap: it takes an approved method, converts it into a structured, machine-enforceable sequence, and will not let an analyst advance from step 3 to step 4 until step 3's requirements are genuinely met.
This is the module in the profile with the strongest data-integrity and regulatory case behind it — real-time, contemporaneous, system-enforced execution is precisely what 21 CFR Part 11 and ALCOA+ data-integrity expectations are reaching for, and it's difficult to demonstrate convincingly with only a static SOP and a narrative ELN entry after the fact.
Team Configuration
- Team name: LES, typically sub-grouped by method discipline where a lab's execution needs vary widely by department (e.g., Chemistry Execution, Microbiology Execution).
- Permission model: Analysts (execute runs), Method Authors (build and maintain the structured executable version of a method), QA/Method Approvers (approve a method version before it becomes usable in live execution, and review completed runs), Team Leader (full configuration).
- Status workflow — per run: Not Started → In Progress → On Hold (deviation raised) → Completed → Reviewed → Approved. Separately, per method version: Draft → Approved → Active → Retired — a method must reach Active before any analyst can start a run against it.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Executable Method / Method Version | The structured, step-gated translation of an approved Document Management SOP |
| Experiment | Method Execution Run | One Experiment per instance of a method being performed start to finish; step-level data accumulates within it as the run progresses |
| Experiment | In-Process Deviation | Raised automatically when a gated check fails mid-run |
| Experiment Category | Method Type / Discipline | Chemistry, microbiology, molecular, physical testing, etc. |
| Resource Category | Method Family | Groups related method versions (e.g., all versions of one titration method over time) |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native gated, sequential step-by-step execution UI — LabLynx One's Experiment body is one continuous document, not an enforced sequence.
- No native live calculation engine tied to in-progress step data entry.
- No native in-process control/interlock checking against conditions in other Teams (calibration status, reagent expiration, analyst qualification) before allowing a step to unlock.
- No native step-level signature or witness prompting mid-run — only whole-Experiment signing.
- No native real-time deviation-to-Quality-Management handoff at the moment a check fails.
- No native way to translate a static, approved SOP into a structured, machine-enforceable step sequence.
- No native mandatory wait-timer enforcement tied to step completion.
- No native direct instrument-to-field data capture.
Plugin App Specification
LES is built as a coordinated suite of plugin components rather than one single app, because "guided execution" genuinely spans several distinct capabilities. The first three are non-negotiable — together they're what actually makes this an LES rather than a nicer-looking ELN. The rest layer in supporting capability around that core.
- → Renders one step at a time
- → Blocks advancing until required fields/checks are met
- → No skipping ahead without a documented reason
- → Evaluates embedded formulas the instant data is entered
- → Pulls reference values from LIMS/LIS in real time
- → Immediate pass/fail judgment at the step, not after the fact
- → Checks reagent lot date (Inventory Management)
- → Checks instrument calibration status (Instrument & Asset Mgmt)
- → Checks analyst qualification (Training Tracking)
- → Step stays locked if any check fails
- → Witness/second-check sign-off injected mid-run
- → Doesn't wait for whole-run completion
- → Webhook opens a Quality Management case the instant a check fails
- → Pre-populated with run/step context
- → Translates an approved Document Management SOP into structured steps
- → Defines tolerances, required fields, formulas per step
- → The bridge between "approved" and "enforced"
- → Mandatory incubation/reaction/settling countdowns
- → Step cannot be marked complete until timer elapses
- → Direct feed from balances/meters into step fields
- → Reduces manual-transcription error
- → Heavier integration lift — recommended as a later addition
Teams tend to assume the execution console itself is the hard part. In practice, the Method Authoring / Executable-Script Builder is what most implementations underestimate — every method a lab wants gated has to be manually re-expressed as a structured sequence of steps, tolerances, and formulas before the console has anything to enforce. Budget for this component accordingly.
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Executable Method — Chemistry | Resource | Method Type: Chemistry | Structured, step-gated chemistry method version | Step sequence, tolerances, formulas | Draft → Approved → Active → Retired | Document Management |
| Executable Method — Microbiology | Resource | Method Type: Microbiology | Structured, step-gated microbiology method version | Step sequence, incubation timers | Draft → Approved → Active → Retired | Document Management |
| Method Execution Run — General | Experiment | Run | Records one full execution of a method | Linked sample, linked method version, step data array | Not Started → In Progress → Completed → Reviewed | LIMS, LIS |
| In-Process Control Check Definition | Resource | Interlock | Defines a specific gating condition and its source | Check type, source Team/endpoint, pass/fail logic | Active → Retired | Instrument & Asset Mgmt, Inventory Mgmt, Training Tracking |
| In-Process Deviation | Experiment | Deviation | Auto-created when a gated check fails mid-run | Run/step reference, failed check, analyst response | Opened → Routed → Closed | Quality Management |
| Step-Level Witness Signature | Experiment | Signature | Records a mid-run witness/second-check event | Witness identity, step reference, timestamp | Requested → Signed | — |
| Method Authoring Draft | Experiment | Authoring | Working record of translating an SOP into executable steps | Source SOP reference, step-by-step mapping | Drafting → Submitted for Approval | Document Management |
| Instrument Data Bridge Configuration | Resource | Integration | Defines a direct instrument-to-field data mapping | Instrument ID, field mapping, data format | Active → Retired | Instrument & Asset Mgmt |
Roles & Permissions
| Role | Execute Runs | Author Methods | Approve Methods/Runs | Configure Team |
|---|---|---|---|---|
| Analyst | ✓ | — | — | — |
| Method Author | ✓ | ✓ | — | — |
| QA/Method Approver | ✓ | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
This module makes the strongest data-integrity case in the entire profile: contemporaneous, system-enforced, step-gated execution with a full audit trail is precisely what regulators mean by "build integrity in, don't inspect it in afterward." A static SOP plus a retrospective ELN entry can describe the correct procedure; only a gated execution engine can demonstrate it was actually followed, in real time, every time.
Integration Points with Other Modules
Consumes approved procedures from Document Management as the source for method authoring; links every run to its LIMS or LIS sample/specimen and feeds the final result back; checks live status against Instrument & Asset Management (calibration) and Inventory Management (reagent/lot expiration) before unlocking gated steps; verifies analyst qualification via Training Tracking; opens real-time cases in Quality Management the instant an in-process check fails.
Success Metrics / KPIs
- Percentage of runs completed with zero manual overrides
- In-process control failure rate, by check type
- Average run completion time vs. standard method time
- Deviation rate per 100 runs
ELN
The ELN Team is the closest to LabLynx One's native, unmodified purpose — rich-text, templated, signable experiment documentation for bench scientists whose work is not sample-centric in the LIMS sense.
Module Overview & Positioning
Where the LIMS Team is sample-centric, the ELN Team is narrative- and protocol-centric: research notebook entries, method development, and general experimental documentation that doesn't necessarily begin with a physical sample being accessioned. This module requires the least renaming and the least plugin support of all twelve, since it is essentially LabLynx One's core ELN functionality used directly.
Team Configuration
- Team name: ELN, optionally sub-grouped by research program or bench.
- Permission model: Authors (create/edit own entries), Peer Reviewers (comment/co-sign), Team Leader (template governance).
- Status workflow: Draft → Signed → Countersigned (optional) → Locked.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Experiment | Notebook Entry | Kept close to native terminology by design |
| Resource | Protocol / Reagent Reference | Reusable methods and reference material entries |
| Experiment Category | Research Program / Project | Groups related notebook entries |
| Resource Category | Protocol Type | Assay, synthesis, characterization, etc. |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
No dedicated plugin app is proposed for the ELN Team. Native capabilities cover the core use case well; any gaps (e.g., structure drawing for chemistry-heavy groups, LaTeX rendering for mathematically intensive research) are addressed as optional, lab-specific configuration rather than a standard part of this profile, and can be added later without architectural change.
Plugin App Specification
Not required for baseline LabLynx One deployment. If a lab's research emphasis warrants it, a lightweight chemistry structure-drawing accent can be layered in later using the same API-based plugin pattern established elsewhere in this profile (see Chapter 5), without disrupting the ELN Team's core configuration.
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| General Notebook Entry | Experiment | Research Program | Free-form dated research documentation | Project, hypothesis, date | Draft → Signed | — |
| Method Development Entry | Experiment | Research Program | Iterative method design documentation | Parent method version, objective | Draft → Signed | Quality Management |
| Assay Protocol | Resource | Protocol Type | Reusable structured assay procedure | Reagents, steps, controls | Draft → Approved → Superseded | Inventory Management |
| Synthesis Protocol | Resource | Protocol Type | Reusable chemical synthesis procedure | Reactants, conditions, yield target | Draft → Approved → Superseded | Inventory Management |
| Reagent Reference | Resource | Reference | Reagent property/handling reference | Hazard class, storage condition | Active → Retired | Inventory Management |
| Peer Review / Countersignature Entry | Experiment | Review | Documents supervisor countersignature | Reviewer, review date, comments | Pending → Countersigned | — |
| Literature Reference Note | Experiment | Reference | Links published literature to research | Citation, relevance note | Draft → Signed | Document Management |
Roles & Permissions
| Role | Create/Edit Own Entries | Countersign Others | Manage Templates | Configure Team |
|---|---|---|---|---|
| Author | ✓ | — | — | — |
| Peer Reviewer | ✓ | ✓ | — | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Version history and e-signature timestamps give research entries defensible evidentiary weight for both regulatory and intellectual-property purposes.
Integration Points with Other Modules
Protocols developed here feed LIMS test methods and Quality Management method-validation records; reagent references link to Inventory Management stock; finalized protocols can be published to Document Management as controlled SOPs.
Success Metrics / KPIs
- Entries signed within target time of experiment completion
- Percentage of entries using a governed template (vs. free-form)
- Countersignature turnaround time
Logbooks
The Logbooks Team digitizes the paper logbook — equipment-use logs, cleaning logs, temperature logs, and access logs — as short, repeatable, timestamped entries rather than long-form narrative documentation.
Module Overview & Positioning
Logbooks differs from the ELN Team primarily in entry shape: where an ELN entry is a long-form narrative record, a logbook entry is short, frequent, and highly structured — a single line confirming a cleaning was performed, a temperature was checked, or a piece of equipment was used, by whom, and when. This module leans heavily on structured metadata fields and lightly on rich-text narrative.
Team Configuration
- Team name: Logbooks, with Resources representing each physical or logical logbook (e.g., "Freezer 3 Temperature Log," "Balance Room Cleaning Log").
- Permission model: Loggers (any authorized staff member creates entries), Logbook Owner (manages templates/categories for their logbook), Team Leader (full configuration).
- Status workflow: typically single-state (Logged), since most logbook entries are complete on creation; exceptions route to Quality Management.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Logbook | One Resource per physical/logical logbook |
| Experiment | Log Entry | One Experiment per individual log line |
| Experiment Category | Log Type | Cleaning, temperature, usage, access, calibration-check |
| Resource Category | Logbook Class | Equipment log, room log, safety log |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native rapid-entry "quick log" interface — creating a full Experiment record per entry is heavier than a one-line paper logbook entry.
- No native automated out-of-range flagging for numeric log values (e.g., a temperature reading outside acceptable range).
- No native recurring reminder/missed-entry alerting (e.g., "no cleaning log entry recorded for Room 4 today").
Plugin App Specification
A lightweight Quick-Log Entry Widget is proposed: a simplified, mobile-friendly form presenting only the fields relevant to a specific logbook, writing directly to the corresponding Experiment template via API, with automatic range-checking and missed-entry alerting.
- → Single-screen entry, minimal fields
- → Auto-fill logger identity and timestamp
- → Mobile-first layout for bench-side use
- → Configurable acceptable range per logbook
- → Immediate flag on out-of-range entry
- → Missed-entry reminder scheduling
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Equipment Usage Log Entry | Experiment | Log Type: Usage | Records who used a piece of equipment and when | Equipment ID, start/end time, purpose | Logged | Instrument & Asset Mgmt |
| Cleaning Log Entry | Experiment | Log Type: Cleaning | Records cleaning/sanitization events | Method used, agent, verifier initials | Logged | Quality Management |
| Temperature/Environmental Log Entry | Experiment | Log Type: Temperature | Records periodic temperature/humidity checks | Reading, unit, acceptable range flag | Logged | Instrument & Asset Mgmt |
| Room/Area Access Log Entry | Experiment | Log Type: Access | Records entry/exit from a controlled area | Person, purpose, time in/out | Logged | Quality Management |
| Calibration Check Log Entry | Experiment | Log Type: Calibration-Check | Quick daily/pre-use verification check | Check result, standard used | Logged | Instrument & Asset Mgmt |
| Master Logbook Registry | Resource | Logbook Class | One entry per active logbook in the lab | Owner, location, retention period | Active → Retired | Document Management |
Roles & Permissions
| Role | Create Entries | Manage Logbook Templates | Configure Team |
|---|---|---|---|
| Logger (any authorized staff) | ✓ | — | — |
| Logbook Owner | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Timestamped, attributable entries satisfy the "contemporaneous" requirement of ALCOA+ and provide the documented environmental/equipment history auditors specifically request.
Integration Points with Other Modules
Feeds equipment usage history to Instrument & Asset Management; out-of-range entries route to Quality Management as potential deviations; logbook registry is cross-referenced in Document Management for retention scheduling.
Success Metrics / KPIs
- On-time logging rate (percentage of scheduled entries completed on time)
- Out-of-range entries flagged and resolved
- Missed-entry alerts triggered per logbook per month
Training Tracking
The Training Tracking Team manages staff competency records — courses, qualifications, and periodic re-certifications — as a structured registry that other modules can query to confirm a person is currently qualified to perform a given task.
Module Overview & Positioning
This module answers a question every other module eventually asks: is this specific person currently qualified to do this specific thing? Rather than a full learning-management system with content authoring and grading, LabLynx One's Training Tracking module focuses on the compliance side — recording completion, expiration, and current qualification status — and is designed to interoperate with LabLynx's dedicated LabCourses product where full course delivery is required.
Team Configuration
- Team name: Training Tracking, with Resources representing each course/curriculum and Experiments representing each individual completion event.
- Permission model: Trainees (view own record), Trainers/Assessors (record completions), Training Coordinator (manage curriculum, run expiration reports), Team Leader (full configuration).
- Status workflow: Assigned → In Progress → Completed → Expiring Soon → Expired/Renewed.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Course / Curriculum | One Resource per course or qualification type |
| Experiment | Training Completion Record | One Experiment per person per completion event |
| Experiment Category | Qualification Type | Method-specific, safety, SOP-specific, role-based |
| Resource Category | Curriculum Track | New-hire onboarding, annual refresher, role-specific |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native expiration dashboard surfacing who is expiring soon or already expired, at a glance, across the whole lab.
- No native automatic blocking of task assignment (in other Teams) for an unqualified or expired person.
- No native course-content delivery (quizzes, e-learning modules) — by design, deferred to LabCourses where full course delivery is needed.
Plugin App Specification
A Qualification Status Dashboard is proposed: a cross-Resource view surfacing every person's current qualification status by course, with expiration alerts, and an API-exposed qualification-check endpoint other modules' plugin apps (e.g., Instrument & Asset Management's calibration console) can call before allowing a task assignment to proceed.
- → Traffic-light status per person per course
- → Filter by department, role, or course
- → Automated reminder emails at 30/14/7 days
- → Callable by other modules' plugins
- → Returns current/expired/not-qualified
- → Used to gate task or instrument assignment
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Method-Specific Qualification | Resource | Qualification Type | Defines a test-method qualification requirement | Method reference, recert interval | Active → Retired | LIMS |
| Safety/Biosafety Training | Resource | Qualification Type | General lab safety course definition | Regulation reference, recert interval | Active → Retired | Quality Management |
| SOP-Specific Training | Resource | Qualification Type | Training tied to a specific controlled SOP | Linked SOP ID/version | Active → Retired | Document Management |
| Equipment-Specific Qualification | Resource | Qualification Type | Qualification to operate a specific instrument | Linked asset ID | Active → Retired | Instrument & Asset Mgmt |
| New-Hire Onboarding Curriculum | Resource | Curriculum Track | Bundled course list for new staff | Course list, target completion window | Active → Retired | — |
| Training Completion Record | Experiment | Completion | Records one person's completion of one course | Score, assessor, expiration date | Assigned → Completed | — |
| Competency Re-Assessment | Experiment | Completion | Periodic re-verification of ongoing competency | Observation notes, pass/fail | Scheduled → Completed | Quality Management |
Roles & Permissions
| Role | View Own Record | Record Completions | Manage Curriculum | Configure Team |
|---|---|---|---|---|
| Trainee | ✓ | — | — | — |
| Trainer/Assessor | ✓ | ✓ | — | — |
| Training Coordinator | ✓ | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Documented, signed competency records are a named, specific requirement under most accreditation frameworks and are frequently the first records an auditor requests.
Integration Points with Other Modules
Qualification status gates task and instrument assignment in LIMS and Instrument & Asset Management; safety training links to Quality Management incident investigations; SOP-specific training links to Document Management revision-driven retraining triggers.
Success Metrics / KPIs
- Percentage of staff currently in-date on required qualifications
- Average days to renew an expiring qualification
- Unqualified-assignment attempts blocked
Document Management
The Document Management Team governs controlled documents — SOPs, policies, forms, and specifications — through their full lifecycle: draft, review, approval, publication, periodic revision, and retirement.
Module Overview & Positioning
Where LabDrive is LabLynx's dedicated, full-featured scientific document management product, the Document Management module delivers core controlled-document lifecycle management natively within LabLynx One for labs that don't yet need LabDrive's deeper co-authoring and external-sharing feature set, while remaining a natural upgrade path to LabDrive as document volume and collaboration needs grow.
Team Configuration
- Team name: Document Management, with Resources representing each controlled document and Experiments representing each revision/approval cycle.
- Permission model: Readers (view published documents), Authors (draft/edit), Reviewers (comment), Approvers (e-sign to publish), Document Controller (manages the master list), Team Leader (full configuration).
- Status workflow: Draft → In Review → Approved → Published → Superseded/Retired.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Controlled Document | One Resource per document, all versions attached |
| Experiment | Document Revision / Approval Cycle | One Experiment per revision's review-approval process |
| Experiment Category | Document Type | SOP, policy, form, work instruction, specification |
| Resource Category | Document Domain | Quality, safety, technical, administrative |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native master document list/register view showing every controlled document, its current version, and its next review date at a glance.
- No native periodic-review scheduling and reminder automation.
- No native distinction between "published, uncontrolled copy" and "current controlled copy" for printed/exported documents.
Plugin App Specification
A Master Document Register is proposed: a single dashboard view listing every Controlled Document Resource, its current version, approval status, and next scheduled review date, with automated reminders to Document Controllers ahead of review due dates.
- → Sortable by type, domain, review date
- → Status badges (current, in review, overdue)
- → One-click access to current published version
- → Configurable review interval per document type
- → Automated reminders to owner/controller
- → Auto-generates next revision Experiment on due date
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Standard Operating Procedure (SOP) | Resource | Document Type: SOP | Core controlled procedure document | Owner, review interval, linked training | Draft → Approved → Published → Superseded | Training Tracking |
| Policy Document | Resource | Document Type: Policy | Organizational policy statement | Owner, effective date | Draft → Approved → Published | Quality Management |
| Blank Form Template | Resource | Document Type: Form | Controlled fillable form | Form ID, revision | Draft → Approved → Published | — |
| Work Instruction | Resource | Document Type: Work Instruction | Step-level supplement to an SOP | Parent SOP reference | Draft → Approved → Published | Logbooks |
| Document Revision/Approval Cycle | Experiment | Approval Cycle | Records one revision's review/approval | Change summary, reviewers, approvers | Draft → In Review → Approved | — |
| Periodic Review Record | Experiment | Approval Cycle | Documents a scheduled no-change review | Reviewer, outcome (no change/revise) | Scheduled → Completed | — |
| Document Retirement Record | Experiment | Retirement | Formal retirement/withdrawal of a document | Reason, replacement reference | Requested → Retired | Quality Management |
Roles & Permissions
| Role | View Published | Draft/Edit | Approve/Publish | Manage Register |
|---|---|---|---|---|
| Reader | ✓ | — | — | — |
| Author | ✓ | ✓ | — | — |
| Approver | ✓ | ✓ | ✓ | — |
| Document Controller | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Multi-tier approval and version control satisfy the document-control expectations common across nearly every laboratory accreditation and regulatory framework.
Integration Points with Other Modules
Publishes controlled SOPs referenced by Training Tracking; stores CAPA-driven document revisions from Quality Management; archives Certificates of Analysis from LIMS; hosts client-facing published documents surfaced through the Lab Portal.
Success Metrics / KPIs
- Percentage of documents reviewed on schedule
- Average approval-cycle turnaround time
- Number of documents past due for review
Quality Management
The Quality Management Team is the lab's nonconformance, deviation, and CAPA engine — the module every other Team routes an exception to, and the one most reliant on a dedicated workflow-board plugin app.
Module Overview & Positioning
Quality Management is architecturally the hub of LabLynx One: an out-of-spec result in LIMS, a missed logbook entry, an expired qualification in Training Tracking, or an overdue instrument calibration can all generate a record here. The module's job is to capture the deviation, drive a structured investigation and corrective/preventive action (CAPA) workflow, and close the loop back to whichever module triggered it.
Team Configuration
- Team name: Quality Management, with Resources representing quality record types and Experiments representing individual nonconformance/CAPA cases.
- Permission model: Reporters (any staff member can open a nonconformance), Investigators (assigned to investigate), QA Reviewers (review/close), Quality Manager (Team Leader, full configuration).
- Status workflow: Opened → Investigating → Root Cause Identified → CAPA Assigned → CAPA Implemented → Effectiveness Check → Closed.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Experiment | Nonconformance / Deviation / CAPA Record | One Experiment per case, from open through closure |
| Resource | Quality Record Type | Defines a class of quality record (internal audit finding, client complaint, OOS, deviation) |
| Experiment Category | Case Type | OOS, deviation, complaint, audit finding, near-miss |
| Resource Category | Quality Program Area | Sample/testing, equipment, documentation, personnel |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native kanban/board visualization of open cases by workflow stage — critical for a QA manager triaging active workload.
- No native cross-Team automatic case creation when another Team's data crosses a defined threshold (e.g., an out-of-spec LIMS result).
- No native CAPA effectiveness-check scheduling and reminder automation.
Plugin App Specification
A CAPA/Nonconformance Workflow Board is proposed: a kanban-style visualization of every open case by stage, with drag-and-drop status transitions (writing back through the API), automatic case creation triggered by webhook from other Teams, and effectiveness-check scheduling.
- → Columns per workflow stage
- → Drag-and-drop status transition
- → Filter by case type, severity, owner
- → Webhook-triggered case creation from LIMS/Logbooks/Instrument & Asset Mgmt
- → Pre-populated with triggering record link
- → Scheduled effectiveness-check reminders
- → Trend view of recurring root causes
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Out-of-Specification (OOS) Investigation | Experiment | Case Type: OOS | Investigates a failed test result | Linked sample/result, root cause, retest decision | Opened → Investigating → Closed | LIMS |
| Equipment Deviation | Experiment | Case Type: Deviation | Investigates an equipment-related deviation | Linked asset, downtime, impact assessment | Opened → Investigating → Closed | Instrument & Asset Mgmt |
| Client Complaint | Experiment | Case Type: Complaint | Tracks and resolves external client complaints | Client, complaint summary, resolution | Opened → Investigating → Closed | Lab Portal |
| Internal Audit Finding | Experiment | Case Type: Audit Finding | Tracks findings from internal quality audits | Audit reference, finding severity | Opened → CAPA Assigned → Closed | Document Management |
| Near-Miss / Safety Observation | Experiment | Case Type: Near-Miss | Records a safety near-miss for trending | Location, potential severity | Opened → Reviewed → Closed | Logbooks |
| CAPA Action Plan | Experiment | CAPA | Defines corrective/preventive actions and owners | Action items, owners, due dates | Assigned → Implemented → Verified | Training Tracking |
| Quality Record Type Registry | Resource | Quality Program Area | Master list of defined case types | Definition, applicable regulation | Active → Retired | — |
Roles & Permissions
| Role | Open Case | Investigate | Review/Close | Configure Team |
|---|---|---|---|---|
| Reporter (any staff) | ✓ | — | — | — |
| Investigator | ✓ | ✓ | — | — |
| QA Reviewer | ✓ | ✓ | ✓ | — |
| Quality Manager (Team Leader) | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
A documented, closed-loop CAPA process with independent QA review is a named, specific requirement across virtually every laboratory accreditation and regulatory framework represented in this profile.
Integration Points with Other Modules
Receives auto-intake cases from LIMS, Logbooks, and Instrument & Asset Management; triggers retraining assignments in Training Tracking; drives document revisions in Document Management; surfaces resolved complaint status to the Lab Portal.
Success Metrics / KPIs
- Average case closure time by case type
- CAPA on-time completion rate
- Repeat/recurring root-cause rate
Instrument & Asset Management
The Instrument & Asset Management Team is the registry and calendar for every calibrated, maintained, or otherwise tracked piece of lab equipment — and the gatekeeper that can prevent an out-of-calibration instrument from being selected for use elsewhere in the suite.
Module Overview & Positioning
Every instrument and significant asset in the lab is registered here once, as a persistent Resource, with its calibration and maintenance history recorded as linked Experiments over time. Because instrument qualification status has to be checked by other modules (LIMS test-order selection, Logbooks usage entries), this module exposes its qualification status through the same API pattern the Training Tracking module uses for personnel.
Team Configuration
- Team name: Instrument & Asset Management, with Resources representing each instrument/asset and Experiments representing each calibration, maintenance, or qualification event.
- Permission model: Operators (view status, log usage), Calibration Technicians (record calibration/maintenance events), Metrology Lead (approve calibration records, manage schedules), Team Leader (full configuration).
- Status workflow (per asset): In Service → Due Soon → Overdue/Out of Service → Under Investigation → Returned to Service.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Instrument / Asset | One Resource per physical instrument or significant asset |
| Experiment | Calibration / Maintenance Event | One Experiment per calibration, PM, or repair event |
| Experiment Category | Event Type | Calibration, preventive maintenance, repair, qualification (IQ/OQ/PQ) |
| Resource Category | Asset Class | Analytical instrument, general lab equipment, facility asset |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native calendar view of upcoming/overdue calibration and maintenance across the full asset fleet.
- No native automatic blocking of an out-of-calibration instrument from being selected in the LIMS Team.
- No native visual asset/floor-plan map for larger labs with equipment spread across multiple rooms.
Plugin App Specification
A Calibration & Maintenance Calendar with Asset Map is proposed: a calendar view of every scheduled and overdue event across the fleet, plus an optional floor-plan visualization, exposing a qualification-check API endpoint that the LIMS plugin app calls before allowing instrument selection on a Test Order.
- → Month/week view of due/overdue events
- → Color-coded by asset class
- → One-click event creation from calendar
- → Returns in-service/due/overdue status
- → Called by LIMS plugin before instrument selection
- → Visual room-by-room asset layout
- → Click-through to asset record
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Analytical Instrument Registration | Resource | Asset Class: Analytical | Registers a calibrated analytical instrument | Make/model/serial, calibration interval | In Service → Retired | LIMS |
| General Lab Equipment Registration | Resource | Asset Class: General | Registers non-analytical equipment (centrifuges, ovens) | Make/model/serial, maintenance interval | In Service → Retired | Logbooks |
| Calibration Event | Experiment | Event Type: Calibration | Records a calibration performed against a standard | Reference standard, as-found/as-left values | Scheduled → Completed → Approved | Inventory Management |
| Preventive Maintenance Event | Experiment | Event Type: PM | Records scheduled preventive maintenance | Checklist completed, parts replaced | Scheduled → Completed | Inventory Management |
| Repair/Corrective Maintenance Event | Experiment | Event Type: Repair | Records unscheduled repair work | Fault description, resolution | Opened → Completed | Quality Management |
| IQ/OQ/PQ Qualification Record | Experiment | Event Type: Qualification | Documents installation/operational/performance qualification | Qualification protocol reference, results | Planned → Executed → Approved | Quality Management |
| Reference Standard Registration | Resource | Asset Class: Standard | Registers a certified reference/measurement standard | Certificate number, traceability chain | Active → Expired | Inventory Management |
Roles & Permissions
| Role | View Status | Log Usage | Record Calibration/PM | Approve Records | Configure Team |
|---|---|---|---|---|---|
| Operator | ✓ | ✓ | — | — | — |
| Calibration Technician | ✓ | ✓ | ✓ | — | — |
| Metrology Lead | ✓ | ✓ | ✓ | ✓ | — |
| Team Leader | ✓ | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Metrological traceability to certified reference standards, and system-enforced blocking of out-of-calibration instrument selection, are both explicit ISO 17025 expectations this module is designed to satisfy.
Integration Points with Other Modules
Gates instrument selection in LIMS; supplies asset context to Logbooks usage entries; opens equipment deviation cases in Quality Management; consumes calibration-standard stock from Inventory Management; verifies operator qualification via Training Tracking.
Success Metrics / KPIs
- Percentage of fleet currently in-calibration
- Average calibration overdue duration before resolution
- Unscheduled repair events per asset per year
Inventory Management
The Inventory Management Team tracks reagents, consumables, and standards — quantities on hand, lot/expiration status, storage location, and reorder triggers — and supplies lot-level traceability back to every module that consumes inventory.
Module Overview & Positioning
Inventory Management is the supply-side counterpart to almost every other module: LIMS test orders consume reagents, ELN experiments consume reagents, Instrument & Asset Management calibration events consume reference standards. This module's core job is maintaining accurate stock levels and lot/expiration status so that consumption anywhere else in the suite reflects reality and expired or unapproved material can't silently be used.
Team Configuration
- Team name: Inventory Management, with Resources representing each stocked item/lot and Experiments representing receiving, consumption, and adjustment transactions.
- Permission model: Requesters (any staff can request/consume), Receiving Staff (log incoming shipments), Inventory Manager (approve vendors, set reorder points, Team Leader).
- Status workflow (per lot): Quarantined → Approved/In Stock → Low Stock → Expired/Depleted → Disposed.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Inventory Item / Lot | One Resource per distinct item lot |
| Experiment | Inventory Transaction | One Experiment per receiving, consumption, or adjustment event |
| Experiment Category | Transaction Type | Receiving, consumption, adjustment, disposal |
| Resource Category | Item Class | Reagent, consumable, standard, hazardous material |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native barcode-based receiving console for rapid intake of shipments.
- No native automated reorder-point alerting or purchase-request generation.
- No native at-a-glance stock-level dashboard across item classes and storage locations.
Plugin App Specification
A Reorder Dashboard & Barcode Receiving Console is proposed: a stock-level dashboard with configurable reorder thresholds and automated purchase-request generation, plus a barcode-scanning receiving workflow that creates the corresponding lot Resource and quarantine-to-approved transition automatically.
- → Current quantity by item/lot/location
- → Low-stock and expiring-soon flags
- → Filter by item class
- → Configurable reorder threshold per item
- → Auto-generated purchase request
- → Vendor approval-status check before ordering
- → Scan-to-receive with lot/expiration capture
- → Quarantine-pending-QC status by default
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Reagent Lot | Resource | Item Class: Reagent | Registers a distinct reagent lot | Lot number, expiration, storage location | Quarantined → In Stock → Depleted | LIMS, ELN |
| Consumable Stock Item | Resource | Item Class: Consumable | Registers general consumable stock (tips, tubes) | Quantity, reorder threshold | In Stock → Low Stock → Depleted | LIMS |
| Certified Reference Standard | Resource | Item Class: Standard | Registers a certified calibration standard | Certificate number, expiration | In Stock → Expired | Instrument & Asset Mgmt |
| Hazardous Material Stock Item | Resource | Item Class: Hazardous | Registers a hazard-classified material | Hazard class, SDS reference | In Stock → Disposed | Quality Management |
| Receiving Transaction | Experiment | Transaction Type: Receiving | Records an incoming shipment | Vendor, PO reference, quantity received | Received → Quarantined → Approved | — |
| Consumption Transaction | Experiment | Transaction Type: Consumption | Records use of an item against an experiment/sample | Quantity used, linked experiment/sample | Logged | LIMS, ELN |
| Inventory Adjustment | Experiment | Transaction Type: Adjustment | Records a manual count correction | Reason, quantity delta | Logged → Approved | — |
Roles & Permissions
| Role | Request/Consume | Log Receiving | Approve Vendors | Configure Team |
|---|---|---|---|---|
| Requester (any staff) | ✓ | — | — | — |
| Receiving Staff | ✓ | ✓ | — | — |
| Inventory Manager (Team Leader) | ✓ | ✓ | ✓ | ✓ |
Compliance & Standards Touchpoints
Lot-level traceability and quarantine-pending-approval status directly support both material-control expectations under GMP and recall-readiness for any material later found defective.
Integration Points with Other Modules
Supplies reagent/media lot data to LIMS and ELN; supplies reference standard stock to Instrument & Asset Management; hazardous material handling links to Quality Management safety programs; vendor approval status shared with Document Management-controlled vendor qualification records.
Success Metrics / KPIs
- Stockout incidents per month
- Percentage of inventory value nearing expiration
- Average time from reorder trigger to received stock
Lab Portal
The Lab Portal Team is the external-facing front door of LabLynx One — the module non-lab users (clients, patients, referring physicians) touch — and the module most fully delivered through a plugin app rather than LabLynx One's native scientist-facing UI.
Module Overview & Positioning
Every other module in this profile is built for people who work inside the laboratory. The Lab Portal is built for people who don't: clients submitting sample requests, checking order status, and downloading reports, without ever needing to understand what a Team, Experiment, or Resource is. Architecturally, this module is almost entirely plugin app, with LabLynx One's native Experiment/Resource model working quietly underneath as the aggregation and data source layer.
Team Configuration
- Team name: Lab Portal, with Resources representing each external client/account and Experiments representing each portal-submitted request.
- Permission model: this Team is unusual in that most "users" are external clients interacting only through the plugin app, never logging into LabLynx One's native UI directly; internal Portal Administrators manage account provisioning and content.
- Status workflow: Submitted → Acknowledged → In Progress (mirrors linked LIMS/Quality Management status) → Completed → Delivered.
Object Renaming Map
| Native Object | Renamed As | Notes |
|---|---|---|
| Resource | Client Account / Portal Widget | One Resource per external client account or dashboard widget config |
| Experiment | Portal Request | One Experiment per client-submitted request (sample submission, report request, complaint) |
| Experiment Category | Request Type | Sample submission, status inquiry, report download, complaint |
| Resource Category | Account Tier | Standard client, contract/CRO client, internal department |
Native LabLynx One Capabilities Leveraged
Functional Gaps Identified
- No native client-facing UI at all — LabLynx One's scientist-oriented interface is not appropriate to expose to external clients.
- No native self-service sample submission form tailored to non-technical external users.
- No native client-specific branding/white-labeling of the request/status experience.
Plugin App Specification
A full Client-Facing Portal is proposed: a self-service web application for account holders to submit sample requests, track status in real time, download reports, and file complaints — entirely decoupled from LabLynx One's native UI, reading and writing exclusively through the API and webhook layer described in Chapter 38.
- → Guided sample-submission form
- → Pre-registration flowing into LIMS accessioning
- → Printable pre-populated labels
- → Real-time order status (webhook-driven)
- → Report/COA download
- → Historical order search
- → Structured complaint form
- → Auto-creates Quality Management case via webhook
- → Client-specific theming for CRO/contract accounts
- → Configurable per Client Account Resource
Experiment & Resource Template Catalog
| Template | Type | Category | Purpose | Key Metadata Fields | Workflow States | Linked Module(s) |
|---|---|---|---|---|---|---|
| Client Account Profile | Resource | Account Tier | Master record for an external client account | Contract terms, billing contact, branding config | Active → Suspended → Closed | — |
| Sample Submission Request | Experiment | Request Type: Submission | Client-initiated sample pre-registration | Requested tests, site, expected volume | Submitted → Acknowledged → Received | LIMS |
| Report/COA Download Request | Experiment | Request Type: Report | Tracks client access to a finalized report | Report reference, download timestamp | Requested → Delivered | LIMS, Document Management |
| Status Inquiry | Experiment | Request Type: Inquiry | Client question about an in-progress order | Order reference, question text | Submitted → Answered | LIMS |
| Client Complaint | Experiment | Request Type: Complaint | Client-submitted complaint intake | Order reference, complaint summary | Submitted → Routed → Resolved | Quality Management |
| Portal Dashboard Widget Config | Resource | Portal Widget | Defines a configurable dashboard element per account | Widget type, data source, refresh interval | Active → Retired | — |
Roles & Permissions
| Role | Submit Requests | View Own Account Only | Manage Accounts/Branding | Configure Team |
|---|---|---|---|---|
| External Client User | ✓ | ✓ | — | — |
| Portal Administrator | ✓ | All accounts | ✓ | — |
| Team Leader | ✓ | All accounts | ✓ | ✓ |
Compliance & Standards Touchpoints
Strict account-level data segregation is the primary compliance concern for this module — one client account must never be able to view another's samples, results, or complaints, enforced both at the LabLynx One Team-permission layer and again at the plugin app layer.
Integration Points with Other Modules
Reads live status from LIMS; downloads finalized reports from Document Management; routes complaints into Quality Management; is the single aggregation point referenced throughout Chapter 37 as the suite's unified front door.
Success Metrics / KPIs
- Percentage of orders submitted via self-service vs. staff-entered
- Average time from result finalization to client notification
- Client complaint resolution time (portal-to-close)
Add-on Applications
The twelve modules in Part II are Teams built entirely on the LabLynx One data model. The five applications in this section are different in kind: they are separately licensed, independently developed LabLynx products that install alongside LabLynx One and extend it into capabilities the core platform doesn't attempt to cover natively — file collaboration, instrument integration, governance/risk/compliance, formal learning management, and client relationship management. Because these are standalone products rather than configured Teams, each chapter here follows a lighter structure than Part II's FDS template: product overview, core capabilities, how it integrates with LabLynx One, licensing, and compliance touchpoints.
LabDrive
LabDrive is LabLynx's cloud-based Scientific Data Management System (SDMS) — a secure, collaborative environment for managing scientific files, documents, and data across departments, projects, and locations, with the version control, e-signatures, and audit trail regulated labs require.
Product Overview & Positioning
Where LabLynx One's own Document Management module (Chapter 13) covers core controlled-document lifecycle management natively, LabDrive is the deeper, dedicated file-collaboration and SDMS product for labs that need more: real-time co-authoring, file locking, task/project management, and large-scale file synchronization across devices and sites. It's the natural upgrade path once a lab's document volume or collaboration needs outgrow the native Document Management module.
Core Capabilities
Integration with LabLynx One
LabDrive is the natural expansion point for the Document Management module — labs that start with native controlled-document management can move deeper collaboration, large file volumes, and co-authoring workflows into LabDrive without disrupting their document control chain of custody. LabCourses also draws on LabDrive as its source library for embedded training documents and SOP references, keeping training content synchronized with the current approved procedure version.
Licensing & Availability
LabDrive is an optional add-on to LabLynx One, licensed on an annual subscription that includes unlimited users, consistent with LabLynx's platform-wide licensing model. Support includes implementation assistance, custom onboarding and training, and continuous feature updates.
Compliance & Standards Touchpoints
Encrypted communications, configurable SSO/LDAP authentication, and full version/audit history give LabDrive the same data-integrity posture regulated labs expect from every LabLynx product.
LabVia
LabVia is LabLynx's laboratory integration and automation platform — the connectivity layer that lets instruments, software, and edge devices across the lab speak a common language and route their data to the right destination in real time.
Product Overview & Positioning
Several modules in this profile — LIMS, LIS, LES, and Instrument & Asset Management chief among them — assume instruments and external systems are feeding data in reliably. LabVia is what actually makes that assumption true at scale: rather than every module building its own bespoke instrument connections, LabVia centralizes protocol translation, data normalization, and orchestration across the entire instrument fleet.
Core Capabilities
Integration with LabLynx One
LabVia is the connective tissue behind several modules' plugin apps: it's what feeds live instrument data into LES's Instrument Data Bridge component, what supplies real-time calibration and usage signals to Instrument & Asset Management, and what routes instrument results into LIMS and LIS test orders without manual transcription. When LabServer is deployed as the on-premises appliance, it also serves as the LabVia Hub — no separate hardware required.
Licensing & Availability
LabVia is an optional add-on to LabLynx One, licensed on an annual subscription with maintenance, support, and warranty included. LabVia Hub deployment includes guided setup with remote or on-site assistance from LabLynx professionals.
Compliance & Standards Touchpoints
Source-level data validation and a documented, protocol-translated chain from instrument to platform support the same data-integrity expectations covered elsewhere in this profile.
LabGRC
LabGRC is LabLynx's dedicated Governance, Risk, and Compliance platform — built on the proven Eramba GRC framework and pre-configured for laboratory regulatory environments — providing the strategic compliance layer that sits above day-to-day quality operations.
Product Overview & Positioning
The Quality Management module (Chapter 14) manages quality operations — CAPAs, nonconformances, audits. LabGRC manages a different, complementary layer: which regulatory standards apply, what controls are required, whether those controls are actually in place and effective, and where residual risk remains. Together, LabLynx One's Quality Management module and LabGRC provide both the operational and the strategic layers of a complete laboratory compliance program.
Core Capabilities
Integration with LabLynx One
LabGRC's CAPA records cross-link directly to Quality Management nonconformance cases; its risk register draws on operational quality events across every module; its personnel-related control requirements auto-assign training in LabCourses; and policies it governs are stored and version-controlled in LabDrive. This is the profile's clearest example of an add-on application acting as connective tissue across both the core modules and the other add-ons.
Licensing & Availability
LabGRC is an optional add-on, selected by regulated laboratories, accredited testing facilities, and quality-system-driven organizations requiring formal GRC framework management, CAPA, risk registers, and internal audit workflows.
Compliance & Standards Touchpoints
LabGRC's regulatory template library is purpose-built to give laboratories a structured, evidence-backed way to demonstrate compliance across whichever of these frameworks apply to their operations, simultaneously.
LabCourses
LabCourses is LabLynx's full-featured laboratory learning management system (LMS) — going well beyond the completion-tracking native to the Training Tracking module by adding course authoring, competency assessment, role-based learning pathways, and verified, tamper-resistant training transcripts.
Product Overview & Positioning
The Training Tracking module (Chapter 12) records that a qualification was completed and tracks its expiration. LabCourses answers a stricter question ISO 17025, ISO 15189, CAP, CLIA, and ANAB all actually ask: not just that someone attended training, but that they demonstrated a defined, tested level of competency. Labs that need to generate that evidence — rather than just a completion date — are the natural LabCourses buyer.
Core Capabilities
Integration with LabLynx One
LabCourses is the natural upgrade path from the Training Tracking module once a lab needs assessed competency evidence rather than completion tracking alone. It receives auto-assigned training requirements from LabGRC whenever a personnel-related control gap is identified, and reports completions back as compliance evidence — closing the loop without manual data entry. Course content draws on LabDrive for embedded, version-synchronized SOP references.
Licensing & Availability
LabCourses is an optional add-on, selected by accredited laboratories, regulated facilities, and organizations with formal personnel competency requirements. It's most commonly deployed alongside LabGRC to link compliance training requirements directly to verified personnel competency records.
Compliance & Standards Touchpoints
LabCourses is built specifically to generate the assessed — not merely attended — competency evidence these accreditation bodies require.
LabCRM
LabCRM is LabLynx's client relationship management add-on — extending LabLynx One's operational modules with the sales, quoting, contract, and renewal management layer a commercial or contract laboratory needs to run the business side of client relationships, not just the testing side.
Product Overview & Positioning
The Lab Portal module (Chapter 17) gives an existing client a place to submit samples, track orders, and download reports. LabCRM covers what happens before and around that relationship: lead tracking, quoting, contract and pricing management, account renewal pipelines, and the sales-side visibility a lab's business development team needs — information the operational modules were never meant to hold.
Unlike LabDrive, LabVia, LabGRC, and LabCourses — each with an established, detailed product datasheet — LabCRM is a newer addition to this lineup, and its capabilities below are scoped at the positioning level pending a full product specification. Treat this chapter as a placeholder for that detail rather than a finalized feature list.
Core Capabilities (Scoped)
Integration with LabLynx One
LabCRM is expected to read order volume, turnaround time, and complaint history from the Lab Portal and LIMS/LIS modules to inform account health and renewal conversations, while keeping sales-side data (quotes, pricing negotiations, pipeline stage) separate from the operational client account record — the same separation of concerns already established between LabGRC and Quality Management.
Licensing & Availability
LabCRM is positioned as an optional add-on for commercial and contract laboratories with a dedicated business development function. Final licensing terms should be confirmed with LabLynx sales, consistent with the other add-ons in this Part.
Solution Template Libraries
The twelve modules (Part II) are building blocks. The five add-on applications (Part III) are extended building blocks. This Part is where those pieces get pre-assembled into ready-to-deploy starting configurations for thirteen specific laboratory verticals — each one curating a subset of modules, add-ons, roles, compliance mappings, and Dashboard KPIs into a single named bundle, so an implementer starts from an industry-tuned baseline rather than a blank platform. Each chapter here is deliberately thin: it references templates and roles already defined in Parts II and III rather than redefining them, and can be thought of as a manifest — what's activated, what's included, and what's recommended alongside it — rather than a full specification in its own right.
Academic/Research
Bundles a lightweight, FAIR-data-principled configuration for academic and university research labs — narrative documentation, minimal compliance overhead, and reagent tracking sized for a research group rather than a regulated production environment.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| ELN | General Notebook Entry, Assay Protocol, Synthesis Protocol, Literature Reference Note |
| Logbooks | Equipment Usage Log Entry |
| Inventory Management | Reagent Lot, Consumable Stock Item |
Role & Permission Presets
Author (graduate student/researcher), Peer Reviewer, Principal Investigator (Team Leader)
Compliance Framework Mapping
Dashboard KPI Presets
Entries signed within target time; percentage of data meeting FAIR retrievability standards
Recommended Add-on Applications
LabDrive (collaboration across multi-institution research teams)
Agriculture Testing
Bundles the matrix- and commodity-based testing configuration agricultural labs need out of the box. This solution spans a wide range of agricultural testing disciplines: feed, seed, fertilizer, cannabis/hemp, fuel, dairy, animal health, horticulture, soil, microbiology, and genetics. Each discipline brings its own sample types, test panels, and certifying bodies, but shares the same underlying LIMS-driven pattern — commodity-specific accessioning, specification/limit comparison, and certificate-of-analysis reporting back to growers, producers, or regulators.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession, Composite/Bulk Sample, General Chemistry Test Order, Microbiology Test Order, Specification/Limits Set — Regulatory, Certificate of Analysis (COA), Recurring/Scheduled Sampling Program |
| Quality Management | Out-of-Specification (OOS) Investigation, Retest/Resample Request |
| Inventory Management | Reagent Lot, Certified Reference Standard |
Role & Permission Presets
Accessioning Staff, Analyst, Reviewer/Approver, Program Coordinator (manages recurring sampling and certification programs)
Compliance Framework Mapping
Dashboard KPI Presets
Turnaround time by commodity/discipline; certification/regulatory deadline compliance rate; retest rate by matrix type
Recommended Add-on Applications
LabGRC (multi-jurisdiction and multi-discipline regulatory framework mapping, since requirements vary widely by commodity and state)
Biobanking
Bundles the long-term specimen storage and chain-of-custody configuration biobanks and biorepositories need — inventory-centric tracking of stored specimens over years or decades, distinct from the throughput-oriented accessioning pattern most other solutions use.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| Inventory Management | Reagent Lot pattern adapted for specimen lots, Hazardous Material Stock Item, Inventory Adjustment |
| LIMS | Standard Sample Accession, Sample Disposal/Retention Record |
| Quality Management | Equipment Deviation (freezer/storage excursions) |
Role & Permission Presets
Specimen Custodian, Inventory Manager, Repository Director
Compliance Framework Mapping
Dashboard KPI Presets
Storage excursion incidents per year; specimen retrieval accuracy; retention-schedule compliance rate
Recommended Add-on Applications
LabVia (continuous freezer/storage-condition monitoring integration)
Clinical/Diagnostic Testing
Bundles patient-testing configuration for hospital-affiliated, reference, and independent clinical labs — positive patient identification, critical-value callback workflow, and CLIA/CAP-aligned reference range handling, centered on the LIS module.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIS | Standard Patient Specimen Accession, Blood/Serum Specimen, Physician Order, Clinical Chemistry Test Order, Hematology Test Order, Reference Range/Clinical Limits Set, Critical Value Callback Record, Result Amendment/Correction, Patient Report (Cumulative), Specimen Rejection Record |
| Quality Management | Out-of-Specification (OOS) Investigation, Near-Miss/Safety Observation |
| Training Tracking | Method-Specific Qualification, Equipment-Specific Qualification |
Role & Permission Presets
Accessioning/Registration Staff, Clinical Analyst, Pathologist/Clinical Reviewer, Quality Manager
Compliance Framework Mapping
Dashboard KPI Presets
Turnaround time by priority (STAT vs. routine); critical-value notification time; specimen rejection rate
Recommended Add-on Applications
LabGRC (CLIA/CAP framework templates), LabCourses (assessed competency evidence for personnel requirements)
CRO/CDMO
Bundles the multi-client, contract-driven configuration contract research and development/manufacturing organizations need — account-segregated reporting, quoting/contract visibility through LabCRM, and client-facing status transparency through the Lab Portal.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession, General Chemistry Test Order, Certificate of Analysis (COA) |
| Lab Portal | Client Account Profile, Sample Submission Request, Report/COA Download Request, Status Inquiry |
| Quality Management | Client Complaint |
Role & Permission Presets
Accessioning Staff, Analyst, Reviewer/Approver, Portal Administrator, Account/Contract Manager
Compliance Framework Mapping
Dashboard KPI Presets
Percentage of orders submitted via self-service portal; contract renewal rate; per-client turnaround time variance
Recommended Add-on Applications
LabCRM (quoting, contract, and account renewal management — the defining add-on for this solution), LabDrive (client-facing document sharing)
Environmental Testing
Bundles the site-, matrix-, and program-based testing configuration environmental labs need out of the box. This solution spans several distinct environmental testing disciplines: environmental monitoring & remediation, environmental health & safety, municipal water/wastewater, industrial pretreatment, commercial environmental testing, and air quality monitoring. Each shares the same underlying LIMS-driven pattern — accessioning by matrix and site, specification/limit comparison against a regulatory reference, and recurring sampling-program scheduling — even though the samples, methods, and regulatory bodies involved differ considerably from one discipline to the next.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession, Environmental Water Sample, Composite/Bulk Sample, Specification/Limits Set — Regulatory, Chain-of-Custody Transfer Log, Recurring/Scheduled Sampling Program |
| Quality Management | Out-of-Specification (OOS) Investigation, Internal Audit Finding |
| Instrument & Asset Management | Calibration Event, Reference Standard Registration |
Role & Permission Presets
Field Sampler (site collection, chain-of-custody sign-off), Accessioning Staff, Analyst, Reviewer/Approver, Program Coordinator (manages recurring sampling schedules)
Compliance Framework Mapping
Dashboard KPI Presets
Percentage of recurring program samples collected on schedule; average turnaround by matrix type and discipline; regulatory limit exceedance rate
Recommended Add-on Applications
LabGRC (multi-jurisdiction regulatory mapping across whichever environmental discipline applies), LabVia (field sensor and instrument integration — particularly relevant for continuous air quality monitoring)
Food & Beverage Safety Testing
Bundles the FDA/USDA/HACCP-aligned configuration for food and beverage safety labs — pathogen and contaminant test panels, batch/lot traceability, and quality-case handling tuned to recall-readiness rather than general nonconformance tracking.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession, Microbiology Test Order, Specification/Limits Set — Regulatory, Certificate of Analysis (COA) |
| Quality Management | Out-of-Specification (OOS) Investigation, Internal Audit Finding, CAPA Action Plan |
| Inventory Management | Reagent Lot, Consumption Transaction |
Role & Permission Presets
Accessioning Staff, Analyst, Reviewer/Approver, HACCP/Food Safety Coordinator
Compliance Framework Mapping
Dashboard KPI Presets
Pathogen detection turnaround time; recall-readiness evidence assembly time; batch traceability completeness
Recommended Add-on Applications
LabGRC (HACCP/FSMA framework mapping and recall-readiness evidence packages)
Forensic Case & Evidence Management
Bundles the case- and evidence-centered configuration forensic and evidentiary labs need — organizing evidence intake, examination, and case-level tracking from submission through report or testimony. Case and evidence management is the actual purpose of the work performed in this solution; chain-of-custody logging is the compliance and data-integrity backbone that runs underneath it, ensuring every transfer and examination is defensible, not the primary framing of the solution itself.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession (evidence intake), Chain-of-Custody Transfer Log, Retest/Resample Request, Sample Disposal/Retention Record |
| Logbooks | Room/Area Access Log Entry, Master Logbook Registry |
| Quality Management | Internal Audit Finding, CAPA Action Plan |
Role & Permission Presets
Case Manager (oversees case lifecycle from intake through report/testimony), Evidence Custodian (custody-chain sign-off authority), Accessioning Staff, Analyst, Reviewer/Approver, Legal/Records Liaison
Compliance Framework Mapping
Dashboard KPI Presets
Case turnaround time (submission to report); chain-of-custody exceptions per 1,000 items; retention/disposal compliance rate
Recommended Add-on Applications
LabDrive (long-term evidentiary document retention), LabGRC (accreditation audit management)
GMP Manufacturing QC
Bundles the regulated production QC configuration any GMP-governed manufacturing site needs — gated, step-enforced test execution, tight equipment/material qualification gating, and CAPA-driven deviation management, centered on the LES module. This solution spans pharmaceutical, cosmetics, nutraceutical/dietary supplement, and medical device manufacturers, and other GMP-regulated producers — industries that share the same underlying discipline (validated methods, equipment qualification, batch release, documented deviation handling) even though the specific regulation governing each differs.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LES | Executable Method — Chemistry, Method Execution Run — General, In-Process Control Check Definition, In-Process Deviation, Step-Level Witness Signature |
| LIMS | General Chemistry Test Order, Specification/Limits Set — Product |
| Quality Management | Out-of-Specification (OOS) Investigation, CAPA Action Plan |
| Instrument & Asset Management | Calibration Event, IQ/OQ/PQ Qualification Record |
Role & Permission Presets
Analyst, Method Author, QA/Method Approver, Quality Manager, Metrology Lead
Compliance Framework Mapping
Dashboard KPI Presets
Percentage of runs completed with zero manual overrides; in-process control failure rate; CAPA on-time completion rate
Recommended Add-on Applications
LabGRC (formal risk register and GMP framework mapping across whichever of these regulations applies — pharma, device, supplement, or cosmetic), LabCourses (assessed operator competency)
Manufacturing QC
Bundles a general-purpose, in-house product and process quality-control configuration for manufacturers across industries — electronics, plastics, consumer goods, automotive and aerospace components, industrial equipment — where consistent product testing, specification compliance, and nonconformance handling matter, but the deep GMP-specific rigor of the GMP Manufacturing QC solution (Chapter 28) isn't required. This is the broader, industry-agnostic counterpart to that GMP-regulated solution.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession, General Chemistry Test Order, Specification/Limits Set — Product, Certificate of Analysis (COA) |
| Instrument & Asset Management | Analytical Instrument Registration, General Lab Equipment Registration, Calibration Event |
| Quality Management | Out-of-Specification (OOS) Investigation, CAPA Action Plan, Internal Audit Finding |
| Document Management | Standard Operating Procedure (SOP), Work Instruction |
Role & Permission Presets
Accessioning Staff, Analyst, Reviewer/Approver, Quality Manager, Production/Process QC Coordinator
Compliance Framework Mapping
Dashboard KPI Presets
First-pass inspection yield; nonconformance rate per production run; CAPA closure time
Recommended Add-on Applications
LabGRC (multi-standard framework mapping across ISO 9001, IATF 16949, and AS9100), LabDrive (SOP and work-instruction document control at scale)
Pharmaceutical & Biotech R&D
Bundles the research-and-discovery configuration for pharmaceutical and biotech R&D groups — protocol-driven experimentation, method development documentation, and reagent tracking, centered on the ELN module rather than sample-throughput modules.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| ELN | General Notebook Entry, Method Development Entry, Assay Protocol, Synthesis Protocol, Reagent Reference, Peer Review/Countersignature Entry |
| LES | Method Authoring Draft, Executable Method — Chemistry |
| Inventory Management | Reagent Lot, Consumable Stock Item |
Role & Permission Presets
Author (bench scientist), Peer Reviewer, Principal Investigator/Team Leader
Compliance Framework Mapping
Dashboard KPI Presets
Entries signed within target time of experiment completion; percentage of entries using a governed template
Recommended Add-on Applications
LabDrive (deeper collaboration and co-authoring as research groups scale)
Point-of-Care Testing
Bundles a decentralized, minimal-footprint configuration for point-of-care and near-patient testing settings — fast patient/specimen registration and streamlined result entry, deliberately light on the heavier LIS workflow for high-volume central labs.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIS | Standard Patient Specimen Accession, Clinical Chemistry Test Order, Critical Value Callback Record |
| Training Tracking | Method-Specific Qualification, Equipment-Specific Qualification |
| Instrument & Asset Management | Calibration Check Log Entry via Logbooks module (cross-referenced) |
Role & Permission Presets
Point-of-Care Operator, Clinical Reviewer, POC Coordinator (oversees decentralized site compliance)
Compliance Framework Mapping
Dashboard KPI Presets
Percentage of operators current on required qualification; result turnaround at point of care; QC failure rate
Recommended Add-on Applications
LabVia (device connectivity across many small, distributed instruments)
Used-Oil/Asset Health
Bundles the fleet-adjacent, asset-health monitoring configuration echoing LubeDx's positioning — instrument- and asset-centric tracking with calibration and maintenance history as the primary data product, for labs performing used-oil and wear-metal analysis on behalf of equipment owners.
Activated Modules & Add-ons
Referenced Template Subset
| Source Module | Templates Included (see Part II for full definitions) |
|---|---|
| LIMS | Standard Sample Accession, Certificate of Analysis (COA), Recurring/Scheduled Sampling Program |
| Instrument & Asset Management | Analytical Instrument Registration, Calibration Event, Preventive Maintenance Event, Repair/Corrective Maintenance Event |
| Inventory Management | Reagent Lot, Certified Reference Standard |
Role & Permission Presets
Accessioning Staff, Analyst, Reviewer/Approver, Fleet Account Liaison
Compliance Framework Mapping
Dashboard KPI Presets
Average turnaround from sample receipt to fleet-operator report; trend-alert accuracy on wear-metal thresholds
Recommended Add-on Applications
LabVia (instrument data bridge for high-volume wear-metal analyzers)
Cross-Module Architecture
With the twelve modules (Part II), the five add-on applications (Part III), and the thirteen solution template libraries (Part IV) all specified, this section addresses how everything on those layers functions as one system: shared taxonomy, the Lab Portal's role as aggregation layer, the API/plugin architecture underlying every custom app and add-on, and how security and compliance hold together across the entire platform — not just the twelve core Teams.
Cross-Team Data Flow & Shared Taxonomy
Twelve independently configured Teams only function as one coherent suite if certain things are held in common across all of them: how a person is identified, how a physical item is referenced across modules, and how tags and categories don't collide.
Shared Identity Across Teams
Every user is a single LabLynx One account regardless of how many Teams they belong to. This is what allows a qualification check in Training Tracking, a permission check in LIMS, and a signature in Quality Management to all resolve to the same, single identity — critical for any audit trail that needs to reconstruct who did what across module boundaries.
Cross-Referencing Physical and Logical Items
Several items exist conceptually in more than one Team — an instrument is registered in Instrument & Asset Management but referenced by Logbooks usage entries and gated against in LIMS; a reagent lot is registered in Inventory Management but consumed in LIMS and ELN. LabLynx One's convention is that the owning Team holds the canonical Resource record, and every other Team links to it via LabLynx One's native Experiment-to-Resource linking rather than duplicating the record.
| Shared Entity | Owning Team | Referenced By |
|---|---|---|
| Person / Qualification Status | Training Tracking | LIMS, LIS, Instrument & Asset Mgmt, Quality Management |
| Patient / Physician Order | LIS | Lab Portal, Quality Management, Document Management |
| Executable Method | LES | LIMS, LIS, ELN, Document Management, Quality Management |
| Instrument / Asset | Instrument & Asset Management | LIMS, LIS, Logbooks, Quality Management |
| Reagent / Standard Lot | Inventory Management | LIMS, LIS, ELN, Instrument & Asset Mgmt |
| Controlled Document | Document Management | Training Tracking, Quality Management, LIMS, LIS |
| Client Account | Lab Portal | LIMS, LIS, Quality Management |
Tag and Category Governance
Tags are intentionally left global across Teams to support cross-Team search, while Categories are Team-scoped by design (per Chapter 4's renaming pattern) to keep each module's classification structure meaningful to its own users. A shared tag vocabulary — client names, project codes, regulatory citations — is maintained as a lightweight governance practice rather than a technical constraint.
Lab Portal as the Unified Front Door
While eleven of the twelve modules serve internal lab staff, the Lab Portal is the one place external stakeholders touch LabLynx One — and its plugin app is built to aggregate, not just relay, data from across the other eleven Teams.
Aggregation, Not Just Pass-Through
A client checking order status isn't just viewing one LIMS record — they may be viewing a combined view spanning an in-progress Test Order (LIMS), a linked complaint case (Quality Management), and a downloadable Certificate of Analysis (Document Management). The Lab Portal plugin app's job is to assemble that composite view from multiple Teams' API responses into one coherent client-facing screen.
Consistency With Internal Workflows
Nothing the Lab Portal displays should ever be out of sync with what internal staff see in the native LabLynx One UI, since both draw from the same underlying records. Real-time consistency is maintained through the webhook pattern described in Chapter 38 — a status change in LIMS pushes an event the Portal plugin subscribes to, rather than the Portal polling for changes on a delay.
API & Plugin Architecture
Every plugin app described in Part II shares one architecture: a thin client authenticating against LabLynx One's RESTful API, reading and writing Experiments/Resources/metadata, and subscribing to webhook events for real-time updates — with LabLynx One remaining the single system of record throughout.
Authentication
Plugin apps authenticate either as a scoped service account (for cross-Team aggregation views like the Lab Portal and the Training Tracking qualification-check endpoint) or on-behalf-of the logged-in user (for Team-specific consoles like the LIMS accessioning screen, and — critically — for the Dashboard's cross-Team "My Work Summary," which must always run as the viewing user rather than an elevated account so it can never surface more than that person already has permission to see), so that LabLynx One's native permission model is always the final authority on what a given request is allowed to do.
Core Endpoint Categories Used Across This Profile
Webhook-Driven Cross-Team Events
Where a plugin app needs to react to an event happening in another Team — Quality Management's auto-intake from LIMS, the Lab Portal's real-time status updates, the Training Tracking qualification-check consumed by other modules — the profile relies on webhook-based event notification rather than polling, consistent with the pattern introduced in Chapter 5.
Repeating the rule established in Chapter 5 because it governs every technical decision in this chapter: plugin apps may cache for performance, but the authoritative record — and the audit trail behind it — always lives in LabLynx One.
Security, Audit Trail & Compliance Across the Platform
Twelve Teams, several plugin apps, and one shared regulatory posture: this chapter consolidates what auditors will expect to see regardless of which module they're examining.
One Audit Trail, Twelve Teams
Because every module is the same LabLynx One instance, the platform-wide audit trail spans all twelve Teams natively — a genuine advantage over a twelve-vendor stack, where reconstructing a cross-system event timeline means correlating logs from separate systems with separate clocks and separate identity models.
Consolidated Standards Coverage
Plugin App Boundary Doesn't Weaken Compliance
Because every plugin app writes back through LabLynx One's own API rather than maintaining a parallel data store, no module's compliance posture is weakened by having a custom front end — the e-signature chain, audit trail, and version history behind a LIMS accessioning console or a Lab Portal request are identical in rigor to a record entered directly through LabLynx One's native UI.
Delivering the Solution
With the twelve modules, the five add-on applications, the thirteen solution template libraries, and the cross-module architecture all specified, this section addresses how LabLynx One is actually licensed, implemented, and positioned against alternative approaches.
Licensing & Deployment Model
LabLynx One inherits its underlying platform's unlimited-user licensing model — a single server-based subscription rather than per-seat pricing — which is what makes a twelve-Team, cross-functional deployment economically sensible in the first place.
Why Unlimited Users Matters Specifically Here
A per-seat LIMS, a per-seat document management system, and a per-seat training tracker each charge for every named user independently. Under LabLynx One's model, every person touching any of the twelve Teams — from a bench analyst to an occasional Logbooks user — is the same unlimited-user license, since all twelve modules are Teams within one LabLynx One instance.
Deployment Options
LabLynx One can be deployed through any of LabLynx's existing sciCloud.net deployment paths — fully hosted cloud, or on-premises LabServer — with the choice driven by the same data-residency and connectivity considerations that apply to any deployment of this kind, not by anything specific to the twelve-module configuration itself.
Implementation Methodology & Rollout Sequencing
Twelve modules should not be configured simultaneously on day one. This chapter proposes a phased rollout sequence prioritizing the modules with the fastest time-to-value and the least cross-Team dependency.
Because every user is a member of the Dashboard Team from day one (Chapter 6), it doesn't get a rollout phase of its own. It's active from the very first login and simply reflects whichever Teams have gone live so far — a lab in Phase 1 sees a Dashboard with two module tiles; by Phase 4, it shows all twelve. There's nothing to "roll out" beyond enabling the plugin app itself alongside the very first module.
A lab with an urgent, specific pain point — say, an accreditation audit citing calibration-tracking gaps — should reorder this sequence to address that module first. The value of LabLynx One's architecture is that any subset of the twelve Teams can be stood up independently and in any order.
LabLynx One vs. Point Solutions
The alternative to LabLynx One is not "no software" — it is twelve separate point solutions from twelve separate vendors. This chapter compares the two approaches directly.
| Dimension | Twelve Point Solutions | LabLynx One |
|---|---|---|
| Vendor relationships | Up to twelve separate contracts and support lines | One vendor, one contract |
| User identity | Separate login per system | Single LabLynx One identity across all twelve Teams |
| Audit trail | Fragmented across systems, manually correlated | Single, unified, platform-wide audit trail |
| Licensing | Per-seat across multiple products | Unlimited users under one server license |
| Cross-module workflow | Manual hand-off or costly custom integration | Native linking + API/webhook pattern built in |
| Rollout flexibility | Constrained by each vendor's own onboarding | Any subset of twelve Teams, any sequence |
This comparison isn't a claim that LabLynx One always outperforms best-of-breed point solutions on depth in any single function — a lab with extremely deep, high-volume LIMS needs may still be better served by ELabLiMS specifically, and a lab with heavy document co-authoring needs may outgrow this module into full LabDrive. LabLynx One's case is architectural: for a lab that needs all twelve functions at a reasonable depth, one platform beats twelve.
Get Started with LabLynx One
The fastest way to evaluate LabLynx One is to pick the one or two modules causing the most immediate operational pain and configure those Teams first — not to attempt all twelve at once.
- Identify which of the twelve modules addresses your lab's most urgent gap today.
- Review that module's FDS chapter in Part II as a build reference for your own configuration.
- Use Appendix B's blank FDS template to scope any additional module not yet detailed here.
- Treat the template catalogs in Part II and Appendix C as a living starting point — expect to add templates as real use cases surface.
Reference Material
Consolidated, at-a-glance reference tables pulling together the renaming conventions and template catalogs detailed throughout Part II, a blank FDS template for scoping any future module, and an index of every solution template library from Part IV.
Master Object-Renaming Glossary
Every module's Experiment and Resource rename, in one table, for quick cross-reference.
| Module | Resource Renamed As | Experiment Renamed As |
|---|---|---|
| Dashboard | Saved View/Widget Configuration; Role-Based Default Layout | Announcement/Notice |
| LIMS | Sample/Specimen; Specification/Limits Set | Test Order/Result Record |
| LIS | Patient Specimen; Patient Record; Reference Range/Clinical Limits Set | Clinical Test Order/Result Record; Physician Order |
| LES | Executable Method/Method Version | Method Execution Run; In-Process Deviation |
| ELN | Protocol/Reagent Reference | Notebook Entry |
| Logbooks | Logbook | Log Entry |
| Training Tracking | Course/Curriculum | Training Completion Record |
| Document Management | Controlled Document | Document Revision/Approval Cycle |
| Quality Management | Quality Record Type | Nonconformance/Deviation/CAPA Record |
| Instrument & Asset Management | Instrument/Asset | Calibration/Maintenance Event |
| Inventory Management | Inventory Item/Lot | Inventory Transaction |
| Lab Portal | Client Account/Portal Widget | Portal Request |
FDS Template (Blank)
The reusable eleven-part structure used for every module chapter in Part II — for scoping any future module added to this profile.
| # | Section | What It Covers |
|---|---|---|
| 1 | Module Overview & Positioning | What the module does, how it differs from adjacent modules, and any related dedicated LabLynx product it complements or upgrades to |
| 2 | Team Configuration | Team name, permission model, status workflow |
| 3 | Object Renaming Map | Table of native LabLynx One objects and their module-specific renames |
| 4 | Native LabLynx One Capabilities Leveraged | Which built-in LabLynx One features carry the module's core function |
| 5 | Functional Gaps Identified | What native LabLynx One cannot reasonably deliver for this module |
| 6 | Plugin App Specification | Whether a plugin is warranted, its purpose, and its proposed UI/UX |
| 7 | Experiment & Resource Template Catalog | Starter set of templates: name, type, category, purpose, key metadata, workflow states, linked modules |
| 8 | Roles & Permissions | Role-by-role permission matrix for the Team |
| 9 | Compliance & Standards Touchpoints | Relevant regulatory/accreditation frameworks |
| 10 | Integration Points with Other Modules | What this module sends to, and receives from, the other eleven |
| 11 | Success Metrics / KPIs | How the module's effectiveness is measured |
Master Template Catalog
Every Experiment and Resource template proposed across all twelve modules, consolidated into one reference list. This is explicitly a starting catalog — expect dozens more templates to be added per Team as real use cases surface during configuration and rollout.
| Module | Template Count (This Profile) | Representative Templates |
|---|---|---|
| Dashboard | 3 | Lab-Wide Announcement, Personal Widget Configuration, Role-Based Default Layout |
| LIMS | 12 | Standard Sample Accession, General Chemistry Test Order, Specification/Limits Set, Chain-of-Custody Transfer Log, COA |
| LIS | 12 | Standard Patient Specimen Accession, Physician Order, Clinical Chemistry Test Order, Reference Range/Clinical Limits Set, Critical Value Callback Record |
| LES | 8 | Executable Method (Chemistry/Microbiology), Method Execution Run, In-Process Control Check Definition, In-Process Deviation, Method Authoring Draft |
| ELN | 7 | General Notebook Entry, Assay Protocol, Synthesis Protocol, Peer Review/Countersignature Entry |
| Logbooks | 6 | Equipment Usage Log Entry, Cleaning Log Entry, Temperature/Environmental Log Entry, Master Logbook Registry |
| Training Tracking | 7 | Method-Specific Qualification, SOP-Specific Training, Training Completion Record, Competency Re-Assessment |
| Document Management | 7 | SOP, Policy Document, Blank Form Template, Document Revision/Approval Cycle |
| Quality Management | 7 | OOS Investigation, Equipment Deviation, Client Complaint, CAPA Action Plan |
| Instrument & Asset Management | 7 | Analytical Instrument Registration, Calibration Event, IQ/OQ/PQ Qualification Record |
| Inventory Management | 7 | Reagent Lot, Certified Reference Standard, Receiving Transaction, Consumption Transaction |
| Lab Portal | 6 | Client Account Profile, Sample Submission Request, Client Complaint, Portal Dashboard Widget Config |
Total starter templates across LabLynx One: 89. Full field-level definitions for each template are documented in the corresponding module's FDS chapter in Part II.
Solution Template Library Index
All thirteen solution template libraries from Part IV, consolidated into one at-a-glance index of activated modules and recommended add-ons — consistent with how Appendix C consolidates Part II without duplicating it.
| Solution Template | Modules Activated | Add-ons Recommended |
|---|---|---|
| Academic/Research | Dashboard, ELN, Logbooks, Inventory Mgmt, Document Mgmt | LabDrive |
| Agriculture Testing | Dashboard, LIMS, Quality Management, Instrument & Asset Mgmt, Inventory Mgmt, Document Mgmt | LabGRC |
| Biobanking | Dashboard, Inventory Mgmt, LIMS, Quality Management, Document Mgmt | LabVia |
| Clinical/Diagnostic Testing | Dashboard, LIS, Quality Management, Training Tracking, Instrument & Asset Mgmt, Inventory Mgmt | LabGRC, LabCourses |
| CRO/CDMO | Dashboard, LIMS, LES, Lab Portal, Quality Management, Document Mgmt | LabCRM, LabDrive |
| Environmental Testing | Dashboard, LIMS, Quality Management, Instrument & Asset Mgmt, Inventory Mgmt, Document Mgmt | LabGRC, LabVia |
| Food & Beverage Safety Testing | Dashboard, LIMS, Quality Management, Inventory Mgmt, Document Mgmt | LabGRC |
| Forensic Case & Evidence Management | Dashboard, LIMS, Logbooks, Quality Management, Document Mgmt, Training Tracking | LabDrive, LabGRC |
| GMP Manufacturing QC | Dashboard, LES, LIMS, Quality Management, Instrument & Asset Mgmt, Inventory Mgmt, Training Tracking | LabGRC, LabCourses |
| Manufacturing QC | Dashboard, LIMS, Instrument & Asset Mgmt, Quality Management, Document Mgmt | LabGRC, LabDrive |
| Pharmaceutical & Biotech R&D | Dashboard, ELN, LES, Document Mgmt, Inventory Mgmt | LabDrive |
| Point-of-Care Testing | Dashboard, LIS, Training Tracking, Instrument & Asset Mgmt | LabVia |
| Used-Oil/Asset Health | Dashboard, LIMS, Instrument & Asset Mgmt, Inventory Mgmt, Quality Management | LabVia |
Every module referenced here is documented in full in Part II; every add-on is documented in full in Part III. This index exists purely for fast cross-reference when scoping a new solution or comparing two verticals' footprints.