Discipline-to-Discipline Review

Passing a drawing or project round the engineering disciplines in turn — Process, Mechanical, Electrical, I&C, Civil — with each step going to somebody who actually holds that discipline on the project, the reviewer choosing who gets it next, and work sent back to an earlier discipline when it needs rework.

The default sequence

The standard library includes Discipline review (P→M→E→I&C→C): five Human review steps, one per discipline, each approving forward to the next. It is a default, not a rule — install it, then copy and edit it to add, remove or reorder disciplines (see Building a Template). A tenant that reviews with a Structural or HVAC discipline simply names it on its steps.

Who is in each discipline

A step that names a discipline draws its assignee from the project's team: the members who hold that discipline on this project. Each project member has a Discipline (Process, Mechanical, Electrical, I&C, Civil, or your own name for one). Short codes are understood — P, M, E, I, C, and ICA / Instrumentation for I&C — so "I" on one member and "I&C" on a step are the same discipline.

A step can also name a minimum project role — Viewer, Author, Checker, Approver or Manager. The pool is then the members at or above that role: a step for "Mechanical, Approver or above" goes to Mechanical approvers and managers, not to a Mechanical author.

The project comes from what the workflow runs on: a Project is its own; a Drawing belongs to its project; a Bill of Quantities or a drawing's I/O list belongs to the project of the BoQ or drawing (see Reviewing Schedules).

Setting a member's discipline is done through the project-members API today (PATCH /api/v1/odata/ProjectMembers({id}) with {"Discipline": "Mechanical"}); a team screen for it is planned.

Handing over

When you approve a step, the review dialog shows who the next step goes to before you confirm:

The next step's pool has…	What you see	What happens if you choose nobody
Several people	A Hand step to picker listing exactly them	The step opens to the whole pool: it appears in every member's Approvals list, marked with the pool's name, and whichever of them acts first takes it
One person	Their name — there is no choice to make	They are assigned automatically
Nobody	A warning, and a picker of everyone in the company	The step waits as Needs assignee
(the step names no discipline or role)	A warning, and a picker of everyone in the company	The step waits as Needs assignee

A choice from outside a non-empty pool is refused. The step is never handed back to you just because nobody else was named — that used to happen, and it let one person walk a review through every discipline alone.

Starting a workflow works the same way: when the first step names a discipline, Assign first step to offers that discipline's members only, and a one-person pool is assigned without asking.

Who may act on a step

• A step assigned to a named person — only that person.
• A step open to its pool — any member of the pool.
• A step that needs an assignee — nobody, until somebody is named.
• A workflow admin (anyone who can manage workflow templates) can act on any step, and can name the assignee of a step that needs one.

Anyone else gets "Only the assignee…" or "Only a member of the … pool…" and nothing changes.

Clearing "Needs assignee"

A step with nobody to go to is shown as Needs assignee on the workflow and in the approvals list (red badge). To clear it, either give somebody on the project that discipline, or have a workflow admin, the step's pool or its current assignee name someone (POST /api/v1/workflows/{id}/assign with {"assigneeId": "…"}).

Sending work back: the rework loop

A discipline that finds a problem does not have to restart the review. Besides Approve and Reject, every step after the first offers two return actions in the review dialog:

Action	Sends the work to	Who gets it
Return to previous	The step that handed it over — Electrical returns to Mechanical	Whoever completed that step last time; if nobody has, its pool
Return to originator	The step the review began on — usually Process	Whoever completed it, normally the originator
Reject	The template's reject route (in the discipline review: the previous discipline)	As for a return

Write the reason in the comments box before you press the button: it is stored with the return in the workflow's history. The reopened step then runs forward again as normal — when Mechanical re-approves, the work comes back to Electrical, and so on — so a loop reads in order in the history:

started        Process
Approve        Process     → Mechanical
Approve        Mechanical  → Electrical
Returned to previous  Electrical → Mechanical   "Pump duty point missing"
Approve        Mechanical  → Electrical
Approve        Electrical  → I&C

At the first step there is nowhere earlier to go. Rejecting (or returning) there closes the workflow as Rejected — it no longer loops back onto the same step, which used to leave the review open with nobody able to tell it had been turned down. Start a new workflow once the underlying problem is fixed.

Running a discipline review from /draw

You do not have to leave the drawing to run its review. In the editor, the review buttons sit at the top-right of the canvas, beside the comments button. The Review workflow button (the branch icon) opens the Review workflow panel next to the drawing. The drawing must be saved first.

Starting. When no review is running on the drawing, the panel says so and offers Start discipline review. This opens the usual start dialog with the drawing already filled in and locked, and Discipline review (P→M→E→I&C→C) already chosen as the template. You can pick another template if you need to. The first step's assignee picker works as described under Handing over.

What the panel shows while a review runs:

• the template and its status (Active, Paused);
• the current step and its discipline;
• who holds the step. This is either a name, Open to the n people in the discipline pool, or Needs assignee. For the last two there is an Assign button. It offers the step's pool, or everyone in the company when the pool is empty, and it follows the rules in Clearing "Needs assignee";
• how many open comments were raised on this step (see below);
• Review step, but only when the step is yours to act on. It opens the review dialog with the next-assignee picker, Return to previous and Return to originator;
• the handover trail: every start, approval, assignment and return in order. Rework loops appear as Returned to previous or Returned to originator rows.

Comments belong to the step. While a review is running, a new comment thread raised from the drawing's comments drawer is linked to the workflow and to the step that is current at that moment. The drawer shows "New comments are linked to the review step …" above the form. Replies stay with their thread. A comment raised when no review is running carries no link.

The comment lifecycle does not change: the comment is still answered, resolved, closed and reopened in the drawer, by the same people as before.

Approving with comments still open. A comment counts as open for the step until it is Resolved or Closed, so Open, Answered and Reopened threads all count. If any are open when you approve, the review dialog warns "n comments raised on this step are not settled yet". This is a warning only, and you can still approve. The comments stay open on the drawing, and the next discipline sees them in the drawer.

Demo tenants see all of this, along with Approvals in the sidebar and Start workflow on the project page. These surfaces follow the drawing (feature F1), so any demo tenant that can open a drawing can run its review.

Things worth knowing

• A named assignee on the step still wins. If a template step has Assign to set to a person, the pool is only consulted when the reviewer hands over to somebody else from it.
• The pool is read when the step is reached, not when the workflow starts. Adding a Civil member half-way through a review means the Civil step will find them.
• Approving a view or issuing a drawing is a separate check. The view approval actions use their own role gate, not the workflow pool.

See also

• Starting a Workflow — the start dialog and notifications
• Building a Template — setting a step's discipline and role
• Running a Design Review — the comments a review produces

Notifications and reminders

Everyone involved in a discipline review is told when something happens to it, without having to watch the workflow page. Each notice appears in the bell and is also emailed (email follows your Notifications > Email preference; in-app notices follow your muted kinds - mute workflow handovers and reminders to silence this whole family). The person who took the action is never told about their own action, and nobody is told twice for one event.

What happened	Who is told
A step is handed to a named person	That person
A step is open to a discipline/role pool	Every member of the pool
A step needs an assignee (nobody assigned, pool empty)	The person who started the workflow, plus the project's Managers (the highest project role, in the workflow's own project only)
A step is returned to an earlier discipline	The reopened step's assignee (or its pool) and the person who started the workflow; the reviewer's reason is included
The workflow completes or is rejected	The person who started it and everyone who acted on, or was assigned, a step

Due-date reminders

A step has a due date when the workflow was started with a deadline, or when the step's template configuration sets an SLA in hours (slaHours, for example 48): the due date is stamped when the step is handed over. An hourly background job then reminds whoever the step is waiting on:

• once when the due date is less than 24 hours away (due soon), and
• once when it is overdue.

Each reminder is sent once per assignment - the job records how far it got, so it does not nag. If a step is reassigned, the new assignee is reminded afresh. Steps that are completed, rejected, cancelled, paused or already passed on send nothing. A step with nobody assigned and an empty pool has nobody to remind; add a pool member or assign it and the next pass picks it up.

Operators can tune this under Notifications in configuration: WorkflowReminderIntervalMinutes (default 60, zero or negative turns the job off) and WorkflowDueSoonHours (default 24).