The library
A workspace with more than a couple of processes lands on a library, grouped by category. Open one and the module narrows to that workflow's own tabs.
If your workspace defined a module for one specific process in Builder, that module opens straight into its workflow and never shows the library.
Board and views
One dataset, five ways of looking at it: Table, Board, Calendar, Gallery and Lane.
A view is a rendering rather than a separate dataset. All five read the same records, which is what stops the old habit of building a second workflow because the first had no calendar and then watching the two disagree within a week.
The board shows how long each record has been where it is, because a case sitting still is the thing a board exists to make visible.
Which view you are in is not saved beyond the workflow's default. Switching to Calendar is something one person does for a minute.
Stages and steps
A stage says where a job is. A step is what somebody actually does.
Steps are the unit the rest of the product borrows. A step becomes a task. Its evidence becomes the audit trail. Its done criteria is what stops two people disagreeing about whether a stage is finished.
Stages come in four kinds: an ordinary stage, one that runs in parallel with another, one that needs approval, and one that waits on somebody outside the company.
Editing here is additive. A published workflow's existing steps are read only, because renaming or reordering one changes what a job has to do in order to close, and that belongs to a new version rather than to a live process.
Databases
A workflow does not only move work along, it produces things. Each stage keeps its own table of what it produced: the fields pinned to that stage plus the shared fields every stage carries.
That is what makes the output of a process findable by kind instead of buried one job at a time.
Analytics
How long jobs take, where they stop, and which stage is holding them. A workflow that looks fine on the board and takes eleven days at one stage is the thing this tab exists to show.
Settings
Three panes behind the Settings control, because they are read once when the process is designed rather than forty times a day.
Process detail. Its owner, its purpose, how often it is reviewed, and what happens when something escalates.
What starts a job. The signal this workflow listens for, and its recent runs. A trigger can be one of: a record is created, a record changes state, a form is submitted, a payment or external event arrives, a date arrives, somebody creates it by hand, or an upstream workflow finishes.
The runs list shows what actually happened, including the outcomes that are not "fired": deduplicated, not matched, not ready, blocked, failed. A trigger that has never fired looks identical to one that works until you can see why.
Where it reads and writes. The modules this workflow touches. It is wired automatically from the workflow's own definition rather than configured here.
Creating a workflow
The wizard walks through the trigger, the stages, the steps in each stage and the fields each stage records. Publish it when it is ready, and it starts listening.
How it connects
- Steps become tasks, so they appear in My Work and in Meetings and tasks.
- A job sitting with you past its allowance raises a stuck row in My Work.
- Builder is where a workspace turns one workflow into a module of its own.
- Stage timings feed Insights.
Common questions
Why can I not rename a step? Because the workflow is published and jobs are running through it. Changing what a job must do mid flight makes the history unreadable. Publish a new version.
Why does my trigger say not matched? The signal arrived and did not fit the condition the trigger is looking for. The runs list shows each one so you can correct the condition rather than guess.
Can two workflows share a record? Yes, through the upstream trigger: one finishing is a signal another can listen for.