> For the complete documentation index, see [llms.txt](https://docs.labii.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.labii.com/widgets/section-widgets/productivity/automation/workflows.md).

# Workflows

## Specs

| Label                     | Value                         |
| ------------------------- | ----------------------------- |
| **Version**               | 0.1.0 (updated on 2024-01-13) |
| **Developer**             | Labii Inc.                    |
| **Type**                  | Section                       |
| **Support Configuration** | Yes                           |

## Overview

The Workflows widget provides a record-level launch panel for predefined Labii workflows, allowing users to trigger automation directly from the record they are currently viewing. Instead of navigating away to a separate workflow management area, users can run selected workflows in context and monitor their execution history from the same section. This is useful for operational processes that should begin from a specific record, such as creating downstream records, generating aliquots, or launching predefined automation actions tied to a sample, project, or request. The widget depends on workflows that administrators configure in advance through the [Workflows admin guide](/admin-guide/workflows.md).

## Use Cases

* **Aliquot generation**: Launch a predefined workflow that creates multiple aliquots from a source sample record.
* **Biospecimen processing**: Trigger extract-generation or derivative-record workflows directly from a specimen record.
* **Operational handoff**: Start downstream automation from a request, order, or intake record without switching interfaces.
* **Standardized record actions**: Reuse approved automation workflows for repeatable laboratory or operational tasks.
* **Execution monitoring**: Check whether a manually launched workflow has completed successfully by opening its execution log.

## Interface

### Read-only View

In read-only view, the widget displays the workflows selected in its configuration as a simple action list. Each listed workflow shows its name and provides controls to execute the workflow or open its execution log. The workflow runs in the background and uses the current record as the trigger context.

* **Workflow List**: Shows the predefined workflows available from this record.
* **Execution Action**: Provides an **Execute Workflow** button for each configured workflow.
* **Log Access**: Provides a **View Execution Log** button to inspect prior or current execution details.
* **Record Context**: Runs the selected workflow using the current record's data and variables.

<figure><img src="/files/8PovCYPq65hbx6sgP1Vg" alt="Read-only view of the Workflows widget"><figcaption><p>The read-only view lists configured workflows with actions to execute them and review their logs</p></figcaption></figure>

### Edit View

The Workflows widget does not provide free-form content editing. In practice, edit mode is centered on configuration: selecting which predefined workflows should appear in the section. Once configured, users interact with those workflows through execution and log-review controls rather than by editing workflow definitions inside the widget.

* **Input Methods**: Select one or more predefined workflows in the widget configuration.
* **Formatting Options**: No content formatting is available because the widget renders configured workflow actions rather than editable text.
* **Validation**: Only existing workflows can be selected; workflow logic itself is managed in the administration area.
* **Collaboration**: Multiple users can launch the same approved workflows from the same record context when permissions allow.

{% hint style="info" %}
The Workflows widget runs workflows that already exist in Labii. It does not create or edit workflow definitions inside the section.
{% endhint %}

## Configuration

The widget requires at least one predefined workflow to be selected before it becomes useful. Workflow definitions themselves are created and managed by administrators outside the section widget.

### Initial Setup

{% stepper %}
{% step %}
Open the target record and add the **Workflows** widget to a section.
{% endstep %}

{% step %}
Open the widget configuration panel.
{% endstep %}

{% step %}
In the **Workflows** field, select one or more predefined workflows that should be available from this record.
{% endstep %}

{% step %}
Click **Save**. The selected workflows appear in the section as executable actions.
{% endstep %}
{% endstepper %}

### Required Settings

* **Workflows**: Select one or more workflows to display and allow users to execute from this widget.

### Optional Settings

The Workflows widget has no additional optional settings beyond choosing which workflows to display.

{% hint style="warning" %}
If no workflows are selected, the widget has nothing to execute. Confirm that administrators have created the required workflows before adding this widget to production records.
{% endhint %}

## Additional Functions

### Execute a Workflow

Click **Execute Workflow** next to a listed workflow to start it. The workflow runs in the background and uses the current record as the trigger context, allowing workflow variables and downstream actions to resolve against that record.

### View Execution Log

Click **View Execution Log** to inspect the workflow's execution history. This is useful for confirming whether the run completed successfully or for troubleshooting workflow behavior.

### Administrator-Defined Workflow Support

The widget is designed to surface workflows that administrators define in the platform settings. Use the [Workflows admin guide](/admin-guide/workflows.md) to create or manage the underlying workflow definitions, triggers, and actions.

## Best Practices

### Data Organization

* Add only the workflows that are relevant to the current record type so users are not overwhelmed with unrelated automation options.
* Use clear workflow names in the administration area because those names appear directly in the widget.
* Place the widget near the section where users make the decision to launch automation, such as sample intake, request review, or preparation steps.

### Performance Optimization

* Keep the workflow list short and purpose-specific to make execution choices fast and unambiguous.
* Review execution logs instead of repeatedly relaunching a workflow when the status of a previous run is unclear.
* Prefer one well-scoped workflow per operational goal rather than one large multi-purpose workflow that is harder to monitor and troubleshoot.

### Security and Compliance

* Limit available workflows to those that users are authorized to trigger in that operational context.
* Validate workflow actions in the admin area before exposing them to production records, especially when workflows create or modify regulated data.
* Use execution logs as part of operational review when automated actions affect important downstream records.

{% hint style="success" %}
The Workflows widget works best when each workflow has a clear operational purpose and is exposed only on the record types where users genuinely need to run it.
{% endhint %}

### Common Pitfalls to Avoid

* **Avoid** adding too many unrelated workflows to one widget, because this makes execution choices harder and increases the risk of launching the wrong automation.
* **Avoid** assuming the widget defines workflow logic; all triggers and actions must already exist in the workflow administration area.
* **Instead** keep workflows small, clearly named, and tied to specific record-level tasks.

### Maintenance and Troubleshooting

* If a workflow does not appear, confirm that it was selected in the widget configuration.
* If a workflow run seems incomplete or incorrect, open **View Execution Log** before attempting another run.
* If users need a new automation path, create or revise the workflow definition in the admin settings rather than trying to solve it in the section widget.

### Workflow Integration Tips

* Use the Workflows widget with [Flowchart](https://github.com/Labii/labii-gitbook-docs/blob/gitbook/widgets/process-management/flowchart.md) when users need both manual launch points and visual process logic in the same broader workflow ecosystem.
* Pair it with [Steps](https://github.com/Labii/labii-gitbook-docs/blob/gitbook/widgets/process-management/steps.md) when a record needs both guided human execution and optional automated follow-up actions.
* Combine it with communication or notification widgets when a workflow should trigger downstream messaging or task coordination.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.labii.com/widgets/section-widgets/productivity/automation/workflows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
