Last Updated: 7/24/2026
Workflows
Availability: Workflows is available only if it has been enabled for your organization. It’s turned on by Jolli for your organization - you can’t enable it yourself. If you don’t see a Workflows entry in the sidebar, it isn’t enabled for your organization.
A Workflow keeps a Space up to date for you. It watches the Sources you choose, runs a Jolli prompt against them on a trigger you set, and writes the result into a target Space - creating and updating Articles instead of you doing it by hand.
Use a Workflow when documentation needs to track something that keeps changing: a codebase, another Space, or a repository’s activity. Each run reads the current state of your Sources and produces the Articles that describe them.
How a Workflow is built
Every Workflow is defined by four parts. On the Workflows screen, each Workflow card lays these out as a labeled timeline.
- When - the trigger that starts a run (Manual, a schedule, or GitHub activity).
- Watching - the Sources the Workflow reads (repositories and/or Spaces).
- Then run - the prompt that tells Jolli what to do with those Sources.
- Target - the Space (and optional Folder) the output lands in, and how it’s published.
Where you manage Workflows
There are two places to work with Workflows, and both show the same Workflow cards.
- The Workflows screen (sidebar → Workflows) lists every Workflow you can see across your organization. Select New workflow to create one.
- A Space’s Workflows tab (Space Settings → Workflows) lists only the Workflows that target that Space; creating one here pins the target Space. For a Company Space, its Owners and Admins can see and pause any Workflow that targets it; for your Personal Space, only you can.
You can edit any Workflow you created, plus any Workflow that targets a Space you administer.
Creating a Workflow
Select New workflow and fill in the form. The target Space and the Workflow type are fixed once the Workflow is created; everything else can be changed later.
Workflow type
If your organization has published its own Workflow types, a Workflow type picker appears so you can choose one; otherwise new Workflows use the standard freeform prompt (“None (freeform prompt)”).
Name
A short, unique label so you can recognize the Workflow in the list.
Trigger
Choose when the Workflow runs.
| Trigger | When it runs |
|---|---|
| Manual only | Never runs on its own - only when you choose Run now. The default for a new Workflow. |
| On a schedule | Runs on a recurring schedule at a time you set. Presets cover daily, every weekday, weekly (pick the weekdays), and monthly (by date or by weekday), plus a custom every-N-days/weeks/months option; you can also set an end date or a maximum number of runs. The schedule uses the timezone from your profile, so set that correctly first. |
| On GitHub events | Runs when Jolli receives selected GitHub activity on a connected repository - Pushes and/or Merged pull requests. You can optionally limit it to a single owner/repo. This trigger requires at least one repository Source. |
Sources
Pick what the Workflow reads - Repositories connected to the target Space, and/or Spaces (including your Personal Space and Company Spaces). Only repositories connected to your chosen target Space are offered, so choose the target Space first. If some Sources are hidden because you lack access, the form notes how many you can’t see.
Prompt and starting points
The System prompt is the instruction Jolli follows on each run - for example, “document the attached repository into this Space.” Write it from scratch, or click a Starting point to fill in a ready-made prompt and then edit it. Starting points stay available after you begin writing your own, and Undo restores what was there before your last click.
If the prompt uses Prompt variables (for example, an intended audience or a maximum number of sections), the form shows a typed field for each. Fill them in to shape the output; you can also override them per run (see below).
Target Space and Folder
- Target space - where the resulting Changeset lands. You can only target a Space you can edit, and it can’t be changed after creation.
- Target folder (optional) - write output into a specific Folder instead of the Space root. The Folder can be changed later.
Where the output lands
| Setting | After a successful run |
|---|---|
| Review first | Leaves a Changeset in the target Space for you to review before publishing. The default. |
| Auto-commit | Publishes the run’s Changeset automatically, with no review step (the Auto-commit changes option). |
| Pull request | For a git-backed target Space, the run always stages output to a pull request for review - Auto-commit doesn’t apply. |
For how Changesets are reviewed and published, see The Jolli Agent.
Notify on completion
Choose whether a finished run notifies anyone. Turn on Send a summary when a run finishes and pick who receives it - any combination of Space owner, Workflow owner, and All space members. The default is the Workflow owner; with the switch off (or no recipients selected), a finished run notifies no one.
Notifications land in each recipient’s Inbox as a Workflow complete notification, showing how many documents the run affected and whether the result was applied automatically, opened as a pull request, or is awaiting review - with links to the run and the Article(s) it produced. (Inbox delivery today; Linear and Slack are marked coming soon.)
Running a Workflow
- Run now - every Workflow, including a Manual-only one, can be run on demand. Run now is the workflow card’s primary button; the other actions - Cancel, Duplicate, Move, and Delete - live in the card’s overflow (⋯) menu. If the prompt uses variables, a dialog lets you review or override them for that run only (those values aren’t saved back). A Workflow runs one at a time; if a run is already queued or in progress, Jolli tells you rather than starting a second.
- Cancel - while a run is queued or in progress the card shows “Run in progress…” and the menu offers Cancel running workflow. Nothing is published.
- Pause / Resume - each card has a toggle. A paused Workflow won’t fire on its schedule or on GitHub events, and Run now is unavailable until you resume it. Pausing deletes nothing.
- When a Source disconnects - if a repository Source is no longer connected to the target Space, Jolli pauses the Workflow and the card shows a Reconnect source link. Reconnect before re-enabling.
- Delete - Delete workflow permanently removes the Workflow and any schedule attached to it. Past run history is preserved.
Duplicating or moving a Workflow
From a Workflow card’s overflow menu you can copy or relocate a Workflow:
- Duplicate - creates a copy (in the same Space, or a different one you can edit). The copy starts disabled and keeps no run history; leave the name blank to name it after the original with “(copy)” appended, or turn on Enable immediately to have it start running right away.
- Move to space… - moves the Workflow to another Space you can edit. The original is removed and its run history does not carry over. Moving needs the same authority as deleting.
When you duplicate or move into a different Space, each repository Source is re-checked against the target Space; if a Source isn’t connected there, Jolli tells you rather than creating a broken copy.
Run history
Each card’s History button opens the run history. Per run you can see:
- Status - Queued, Running, Success, Failed, or Cancelled.
- How it was triggered - Manual, Schedule, or Event.
- Duration and a short summary of what it produced.
- How many documents it affected, broken out as Created, Edited, and Deleted (for example, “Affected 3 · Created 1 · Edited 2”), each Article linked when still active.
- The publish outcome - Applied automatically, Opened a pull request for review, Pending review, or a Publish conflict / Publish failed state.
- For a git-backed target, the pull request it opened (shown as “PR #N opened”).
When a run fails, the history shows a plain-language reason - for example, that a Source could not be read, that the Sources were too large for the model’s context window, or that writing to the destination failed.
Organization defaults
Organization admins can set defaults for every Workflow run under Settings → Workflow Defaults. These are advanced controls - the built-in defaults are sensible, and any individual Workflow can override them from its own Advanced execution settings. A blank field means “use the built-in default.”
- Models - which model each agent role (writer, analyzer, reducer) runs on, plus fallback models by tier.
- Agent counts & limits - the number of writers and researchers per run, max output tokens, and the per-run timeout (values above the platform limit are capped).
- Destination article index - whether writer agents are handed the existing target-Space Articles relevant to their task, so they update or avoid duplicating them instead of re-researching.
Viewing this page needs Workflows view access; saving needs edit access.
How Workflows relate to Changesets
Unless you turn on Auto-commit, each successful run writes its output as a Changeset in the target Space - the same reviewable unit you get editing by hand - which you review and publish exactly as usual. For a git-backed Space, the run stages a pull request instead, and that PR is the review gate.
In other words, a Workflow is an automated author feeding the review flow you already use: it proposes Article changes across your Sources, and you stay in control of what actually publishes. See The Jolli Agent for that review-and-publish flow.
Next steps
- The Jolli Agent - the Jolli Agent, Changesets, and Gap Analysis.
- Managing a Space - the per-Space settings a Workflow targets.
- Jolli Sites - publish the resulting content at a URL.