The workflow

Decision outcomes

A decision step gives its assignee a set of outcomes to choose from. A plain approval is just two outcomes — Approve and Deny — but you can define your own list ("Under $500", "Over $500"; or one outcome per request category). Each outcome says where the request goes next: continue to the next step, jump to a specific step (skipping the ones between), deny the request, or mark the approval milestone and continue with any remaining logistics steps.

Branching a form's path

To route submissions differently, add an early decision step whose outcomes name the paths — for example a director's classification step with one outcome per request type. Point each outcome at the step where its path begins; paths rejoin wherever an outcome routes back to a shared step. Because the router is a person choosing an outcome, judgment calls that used to need workarounds ("this one needs board review") are just another outcome.

Task steps

A task step is work someone completes before the flow continues: filling a step-owned section of the form, uploading required documents, or completing a document form. A step's assignee can be a group (optionally limited to members at the submitter's site), the submitter's supervisor, a specific person, or the submitter — so a request can come back to the person who filed it mid-flow (say, to pick menu items after an approval) and then continue on. Steps in the same parallel group run at the same time and must all complete before the flow moves on.

External steps

An external step emails a secure link to a contact outside the district — a vendor or agency — who completes their part (uploads, sign-off) without needing an account. The link is valid for 30 days, and the contact is reminded automatically until they respond.

Holds and timers

A hold step parks the request under a public status label ("Pending board approval") until an assigned handler releases it — optionally recording details like the board date — or until a date on the form arrives. Any step can also carry a date reminder (e.g. the event date plus one day → "upload the sign-in sheets") and an escalation reminder if it sits too long.

Send-back

The person acting on the current step can send the request back to any earlier step — including all the way back to the submitter to revise the submission. The flow re-runs from the chosen step; everything that happened stays on the request's timeline.

The request lifecycle

A request starts as a draft, becomes active when submitted, and ends denied, cancelled, or — when the final step completes — closed. An approval milestone outcome records the approval date the moment it's taken, even while later logistics steps keep running, so "approved" and "finished" can be different moments. While active, the submitter sees the current step's public status label ("PO received / order authorized", "Pending board approval"), so "where is my request?" always has a plain answer.

The case file

Every request's page is a case file: the form's current values, a timeline of everything that has happened, and a work panel showing what you can do right now. It carries:

• One shared conversation — the submitter and everyone who handles the request post in the same thread, open for the request's entire life.
• Internal notes — visible only to handlers and admins, never to the submitter, and never included in the printed PDF.
• Attachments — anyone involved can attach a file at any point, not just at their own step; each attachment records who added it and when.
• Document checklist — a per-form list of required documents ("Approved PO", "Sign-in sheets"), each checked off by linking an attachment, visible to everyone on the request.

Running a step only for some requests

Any step can carry "Run this step only when…" — a rule built from the form's answers, the same way as a visibility rule ("Run this step when Pre-approved trip equals No"). The rule is checked when the request reaches the step. When it is not met, the step is skipped and the request moves on to the next one; the case file records the skip. A request whose remaining steps are all skipped closes.

The Flow view shows the rule on the step's card ("Runs only when…"). It reads the answers as they stand at that moment, so a value entered at an earlier step counts too.