> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom Workflows

> Reusable, step-structured procedures Dexter runs the same way every time — and improves run over run.

## Overview

A **custom workflow** is a reusable, step-structured procedure that you and [Dexter](/product/ai-assistant) run again and again — a scheduling pass, a weekly quality audit, a recurring report, a data-refresh-and-compare cycle. It captures how *your* operation runs the process: the order of steps, the constraints that matter (and how much), the judgement calls, the scripts that do the deterministic work, and the sign-off gates.

Custom workflows persist across conversations, appear in the **Workflows** tab automatically, and improve run over run through a built-in reflection loop. The first run of a new workflow is rarely perfect — it becomes so as Dexter absorbs your corrections into the workflow's own files.

## When a Workflow Is Worth Creating

* You run a recurring operational process — daily, weekly, monthly, per-order — and want it standardized so it runs the same way every time.
* You've just finished a complex multi-step task with Dexter that you'll want to repeat.
* You want a future Dexter session (or a teammate) to execute the process the way you would, without re-explaining the operation from scratch.

One-off analyses don't need a workflow. Anything you'll run more than a handful of times probably does.

## What a Workflow Contains

A workflow lives as a small directory of files that Dexter reads at execution time:

| File               | Role                                                                                                                                                                                                                   |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **README**         | The procedure itself: the workflow's name and description, an overview, one heading per step in strict order, and cross-references. The workflow's detail page renders its step headings as your at-a-glance overview. |
| **Auxiliary docs** | Constraint catalogs (what's hard, what's a soft preference and how strong, where the data is wrong and your knowledge wins, example judgement calls with reasoning), complex mappings, judgement context.              |
| **Scripts**        | Python for deterministic transformations, validations, and consistency checks — cleaning an export, building a first-pass allocation, checking a draft against the constraint catalog.                                 |
| **Learnings**      | Dexter's per-run notes, one dated file per run. The audit trail of why the workflow evolved, and the fuel for the improvement loop.                                                                                    |

The workflow's name has to be unique — it can't duplicate a built-in procedure's name — and its directory is kebab-cased. Dexter handles both when it sets the workflow up.

Two structural rules apply to every workflow:

1. **Step 1 is always the day-of conditions intake.** Before touching any data, Dexter asks what's different about this run — equipment down, deliveries missing or late, labor short, rush orders. Operational conditions change daily and the data rarely says so; this step is how those changes enter the run.
2. **The final step is always reflection.** After the deliverable is out, Dexter reads the run's learnings, proposes concrete improvements to the workflow's files, and applies them only after you approve.

## Creating a Workflow with Dexter

Tell Dexter you want to save a process — *"make this reusable"*, *"create a workflow for our weekly quality audit"*, *"standardize the way we build the daily schedule."* Dexter may also propose creating one on its own after you finish a complex multi-step task it can tell you'll repeat; either way, nothing is written until you confirm. Dexter draws the process out of you before writing anything. Expect questions about:

* **The goal** — what the process produces, who consumes it, what "done" looks like
* **The steps as you run them today** — in order, with inputs and outputs per step
* **The data sources each step touches** — and which ones you trust
* **The constraints** — for each one, how much it matters: a hard rule that's never violated, a soft preference weighted by how much you care, or data that looks like a rule but should be ignored
* **The judgement calls** — where you decide by feel, with example decisions and the reasoning behind them
* **What varies day to day** — so the conditions intake asks about the disruptions this process is actually sensitive to

Dexter then lays out the structure, writes the README, auxiliary docs, and scripts, and reads the procedure back so you can confirm the step headings and gate placements before it goes live. The workflow is available immediately in the same conversation and appears in the **Workflows** tab automatically.

<Tip>
  Grade constraints on a continuum, never as yes/no. "The compatibility sheet says this combination is disallowed — in practice it's a strong preference to avoid, acceptable under pressure" is exactly the kind of nuance that makes a workflow produce the answer you would have produced.
</Tip>

## Gates: How Dexter Checks In During a Run

A **gate** is a checkpoint where Dexter presents an intermediate result and waits for your approval before the next step consumes it — a summary of what was produced, the choices that shaped it, and an approve / request-changes decision.

New workflows carry more gates than mature ones. Every gate is a course-correction point: the feedback rescues the current run and feeds the improvement loop. A gate only comes out when *you* ask for it; the reflection step may propose removing one once runs are consistently clean, but the decision is yours.

## Reflection and the Improvement Loop

At the end of every run, Dexter reviews where you corrected it mid-flight, where a script caused friction, where an instruction was ambiguous enough to force a guess, and what information the workflow's files didn't carry. It translates that into concrete edits — a new hard constraint, a soft preference regraded, a judgement example added, an ambiguous instruction rewritten — and presents them as a proposal.

<Note>
  Nothing is applied without your explicit approval. If you approve some changes and not others, only the approved subset lands. Consumed learnings stay in place as an audit trail, so if an "improvement" later turns out to be a regression, the trail shows what changed and why.
</Note>

Over enough runs, this loop is what converges a workflow toward autonomous execution.

## Running a Workflow

**From chat** — ask for it by name: *"Run the daily production schedule."* Dexter picks up the workflow, walks the steps in order, records learnings as it goes, presents gates at the checkpoints, and closes with the reflection step. Long runs maintain a visible task list so you always know which step is in progress.

**From the Workflows tab** — open **Workflows** in the top navigation to see every custom workflow in the factory, searchable by name and description, each showing its status (**Running**, **Awaiting input**, or **Inactive**) and run count. Open a workflow to see its detail page:

* **Overview** — what the workflow does
* **Steps** — the step headings from the workflow definition
* **Recent Runs** — each run with its status; open one to see the full conversation it executed in
* **Latest Output(s)** — the deliverables the most recent run produced
* **Run** — start a manual run now; it appears under Recent Runs, and you can open it from there once it's going

Runs are ordinary Dexter conversations, so every gate, tool call, and output remains reviewable after the fact.

## Custom vs. Built-In Procedures

ProDex ships built-in procedures for the recurring shapes of work Dexter supports everywhere — building a simulation model, running an [experiment](/product/experiments), a [Monte Carlo study](/product/monte-carlo), generating a [report](/product/dexter/reports), [exploratory data analysis](/product/exploratory-analysis), [BOM explosion](/product/bom-explosion) and [configuration](/product/configurator), [CAD analysis](/product/cad/analysis), and [planning](/product/planning-overview) runs. Dexter follows those automatically when the task calls for them; they don't appear in the Workflows tab and you can't edit them.

Custom workflows are yours: they encode your operation's specifics and evolve through the reflection loop. When a built-in procedure almost fits but needs your operation layered on, create a custom workflow that leans on the built-in from its steps.

## Limits and Caveats

* **Scoped to the active factory.** A workflow runs against whichever factory you're in; a process that spans factories needs a workflow per factory.
* **Gates are non-optional until you remove them.** Dexter won't skip a gate to save time. If a gate asks for something a run doesn't produce, flag it in the run so the reflection step can fix the workflow.
* **Learnings are per-workflow.** What Dexter learns running your daily schedule workflow doesn't transfer to the weekly audit workflow. Cross-workflow knowledge belongs in the [knowledge base](/product/dexter/memories).
* **The step order is a contract.** Steps run strictly in order — no skipping, reordering, or merging. Where a step legitimately branches, the branch is encoded explicitly in the step's instructions.

<Warning>
  Workflow edits change every future run. Review the reflection step's proposals with the same care you'd give a procedure change on the floor — that's why the approval gate exists.
</Warning>