Our Workflows feature allows you to create and run your own workflows or pipelines on One Codex. It can be helpful to have the outputs for one workflow be available as inputs for other workflows. This becomes particularly helpful in cases where multiple workflows have the same starting steps. You don't want to have to rerun the same steps in different workflows. "Dependencies" can help to cut down on repeated pre-processing steps, saving you time.

Dependencies are workflows whose outputs can be used as inputs to other workflows. When creating a new workflow, you can set it to depend upon other workflows, which will be run prior to the current workflow.

In the example below, "Parent Workflow A" and "Parent Workflow B" are set as dependencies for Your Workflow (direct dependencies). This means that "Parent Workflow A" and "Parent Workflow B" must be run prior to running Your Workflow. If these have not yet been run, we will run them for you.

Direct Dependencies can have their own dependencies too. For instance, "Parent Workflow A" depends upon "Grandparent Workflow C". And "Parent Workflow B" depends on both "Grandparent Workflow C" and "Grandparent Workflow D". We refer to these as "Indirect Dependencies" for Your Workflow, as they are not specifically marked as dependencies for Your Workflow, but are needed for its dependencies.

When drafting your workflow, to the right of the code block, you will see the option to Add Dependency, above the Assets and Arguments fields.

When you choose a workflow as a Dependency, you will see the name of the workflow, the date it was created, and whether it has been published or is in a draft state. You will also see where the outputs of that workflow will be injected into Your Workflow. In the below example, the outputs from the "Hello Fastq" workflow will be injected into /out/hello-fastq.

Note that you will not be able to select workflows as dependencies if they have required arguments with non-default values. For instance, in the below screenshot, "Workflow with Arguments" is a workflow that has required arguments, but for which no defaults have been set. This is because we cannot automatically launch the workflow, as we don't know what the values should be. You may want to edit your dependency so that it has default values, in order to use it as a dependency for other workflows.

When you go to publish a workflow, we first check if its parent workflows have also been published. A parent workflow must be published in order for a child workflow to be allowed to be published. The reason for this is, publishing a workflow prevents that workflow from being changed, allowing for version controlling of your workflow. If we allowed direct or indirect dependencies of a workflow to be editable (i.e. in a draft state), then we could not guarantee the version controlling of your workflow, as the draft dependencies that it relies upon could be edited.

Once all parent (and indirect) dependencies have been published, only then can Your Workflow be published.

When you try to launch a workflow that has dependencies (e.g. Your Workflow in blue, in the below example), we will first check if the workflows that it depends upon (e.g. "Parent Workflow A" and "Parent Workflow B") have already been run. In this case, "Parent Workflow A" has already been run on your sample, but "Parent Workflow B" has not yet been run. If you click to run Your Workflow on this sample, we will first launch "Parent Workflow B" with default values, so that its outputs are available for Your Workflow.

If you wish to use non-default values for a dependency workflow (e.g. "Parent Workflow B"), then you will need to launch Parent Workflow B manually, prior to launching Your Workflow.

If a dependency workflow has been run multiple times with different arguments, the most-recent successful run of that dependency will be used as the input for Your Workflow. For instance, in the below, Parent Workflow A was run 3 times; once with default values, and twice more with non-default values. The most recent of those 3 runs is chosen as the input.

If a workflow has been run on a sample when the workflow was in a draft state, then this can be used as an input dependency if Your Workflow is also in a draft state. However if Your Workflow has been published, then the draft run of the dependency (e.g. previous runs of Parent Workflow B before it was published) cannot be used as an input to the published version of Your Workflow. This is to further enforce version control with published workflows.

To manage this, if you try to run a Your Workflow, where one of its dependencies has only been run while in a draft state, we will automatically launch a new run of the now-published Parent Workflow B, and use its results as the input for Your Workflow.

If a dependency run fails, then all of the workflow runs which were awaiting its results will also be marked as failed.

You can rerun the failed dependency. This will trigger the downstream workflow runs to also rerun once the dependency completes successfully.

If a workflow (e.g. Your Workflow in the below image) is set as a dependency for another workflow (e.g. Parent Workflow A), the dependency workflow (Parent Workflow A) cannot use the first workflow (Your Workflow) as its own dependency. This would result in circular dependencies, where both rely upon the outputs of the other, which would mean neither could run as they're both waiting for the other to complete. We prevent setting a workflow as a dependency if that workflow itself depends upon the one you are trying to edit.

Indirect dependencies provide their outputs to direct dependencies. But their outputs are not automatically passed to Your Workflow. If you require the outputs from an indirect dependency in Your Workflow, you will need to explicitly set the dependency workflow (e.g. Grandparent Workflow D) as a direct dependency for Your Workflow as well as a dependency for its other dependencies (e.g. Parent Workflow B).

Now that you know what dependencies are and how to set them up, learn more about the other workflow setup steps here.