Workflows
A workflow is a multi-step review, saved. Not one check - a sequence: pull the schedules, cross-reference them against the plans, check the details resolve, write it up the way this client wants it.
Where a check answers one question and a checklist works a list of them, a workflow is a whole review procedure you've decided is worth keeping.
Use case: the six things you always do on a Fairhaven distribution-centre set, in order, on every new revision.
Where they live
Open Workflows from the tools rail in a project. One scrolling list of collapsible sections:
- Personal at the top - yours, private, open by default.
- Shared below a divider - everything your organization or your teams have adopted, grouped.
The shared groups are one flat level that mixes disciplines, clients and offices - "Mechanical" sits next to "Fairhaven" next to "Toronto". That's not an oversight; it's what the underlying team model is. Membership is all-inclusive rather than a hierarchy, because a mechanical engineer on the Fairhaven account is genuinely in both groups.
The Workflows panel: Personal above the ORG divider
Where a group spans several disciplines, a chip row inside it lets you narrow. Where a group is all one discipline, there's no chip row to clutter it.
Making one
The usual route is the chat. Give it a job, work through it, and when the result is right, ask it to save the workflow. You get something re-runnable without having built anything.
Running one
Open the workflow from the panel. It starts a fresh chat with the workflow already in place as an @-pill - the saved procedure travels with the pill, so there's nothing to paste or re-explain.
Whatever you type after the pill is this run's instructions, layered over the saved steps: "@Fairhaven Set Review - just M-601", or "@Tag Reconciliation - note the schedule was reissued Tuesday". The procedure stays as saved; your words steer this one run.
Discipline is a preference, not a permission
Your discipline is preselected on the chips, and it's self-selected - you set it, and you can see other disciplines' workflows freely. Only editing is restricted.
Teams are the opposite: a workflow shared with a team is listed only for that team's members. So the chips are for finding, and the list itself is already yours - nothing confidential is sitting behind a filter you could clear. See Teams gate, disciplines label.
Sharing
Workflows follow the standard model: private, then shared with a team, then shared with the organization, each promotion reviewed. See How access works.
A workflow shared with a team appears in that team's page under Workflows.
Removing vs deleting
Two different actions, and the difference matters:
- Remove from list takes the workflow off a team's shelf. It un-shares it - the workflow itself is untouched and still yours.
- Delete removes the workflow itself, and it is recoverable if you delete one by mistake.
Deleting an item also withdraws any share requests still pending on it, so nothing is left waiting for review on something that no longer exists.
Revit workflows
Saved routines for the Revit add-in are their own kind, and they get their own section on a team page. They run against the live model rather than a drawing set.
Workflows are switched on per organization. If you don't see the tool, talk to us.
Some of what the panel can display - approval state, step counts, recent activity - arrives as the backend catches up, and each part degrades on its own. A group with no chips or an empty review queue means that detail isn't being served yet, not that something is broken.