Skip to content

Example Use Cases

The scenarios below illustrate typical ways this solution is used. Names and identifiers are illustrative, not real accounts.

1. Publishing Instrument Output for an External Partner

Scenario: A lab runs a sequencing instrument that produces a sample sheet and associated run output files. An external analysis partner needs these files to perform downstream processing.

Flow:

  1. The instrument (or a lab user) writes the sample sheet and run output files to the lab's upload directory on the on-premises file share.
  2. The files are automatically synchronized to cloud storage.
  3. The external partner connects via SFTP and downloads the files from their read-only inbound directory.

Why this solution helps: The lab doesn't need to know anything about the partner's systems or provide them broader network access — the files simply appear where the partner expects them, with no manual export step.

2. Receiving Partner-Submitted Data for Lab Processing

Scenario: An external partner performs analysis on lab-submitted data and needs to return results (e.g. processed reports, QC results, supplementary metadata) back to the lab.

Flow:

  1. The partner connects via SFTP and uploads their results into their outbound directory.
  2. An event-driven pipeline detects the new file and triggers a targeted refresh of the corresponding on-premises folder.
  3. Lab users see the returned files on the on-premises share shortly after upload, with no manual polling or refresh required.

Why this solution helps: Results are available to lab users almost as soon as the partner uploads them, without either side needing custom integration or a shared internal system.

3. Onboarding a New Laboratory

Scenario: A new laboratory needs to start exchanging files with external partners using the same shared platform.

Flow:

  1. The platform/integration team creates a new access group for the lab and provisions its upload/download directories.
  2. Lab users are added to the new access group.
  3. The lab can immediately begin using the standard file-share workflow described in "How to Use It" — no new infrastructure is required.

Why this solution helps: Each new lab reuses the same underlying platform and isolation model, so onboarding is a configuration change rather than a new build.

4. Onboarding a New External Partner

Scenario: A lab needs to begin exchanging files with a new external collaborator who has not previously used the platform.

Flow:

  1. The partner generates an SSH key pair and shares their public key with the Hybrid File Transfer Solution team.
  2. The Hybrid File Transfer Solution team provisions a dedicated set of directories for the partner and registers their public key, scoping their access policy to only those directories.
  3. The partner can immediately connect via SFTP using their private key.

Why this solution helps: Each partner is isolated from every other partner and from internal lab systems, so onboarding a new external collaborator carries no risk of cross-partner data exposure.

5. Supporting a Lab Working with Multiple External Partners Simultaneously

Scenario: A single lab collaborates with several external partners at once — for example, sending different subsets of instrument output to different analysis providers, each of whom should only see their own data.

Flow:

  1. Each external partner is provisioned with their own isolated set of directories (inbound/outbound), independent of any other partner.
  2. The lab publishes files intended for Partner A into Partner A's inbound directory, and files intended for Partner B into Partner B's inbound directory.
  3. Each partner connects via SFTP and only ever sees their own directories — neither partner can see the other's files, submissions, or even that the other partner exists.
  4. Partners submit their respective results back independently, with no risk of cross-partner data exposure.

Why this solution helps: A lab can scale to working with many external collaborators on the same platform without needing separate infrastructure per partner, while the isolation model guarantees no partner can access another's data.

Stronger isolation option: For partners requiring a higher degree of separation than prefix-level isolation within a shared bucket, a dedicated, separate storage bucket can be provisioned per partner instead. This gives that partner their own fully isolated storage boundary — rather than sharing a bucket with other partners under different prefixes — and can be used selectively where a partner's requirements call for it, without affecting how other partners are configured.