Workflow cases and process types

Process types: the blueprint

A process type is the reusable blueprint of an academic procedure — creating a new program, amending an existing one, or any internal review. It defines the ordered stages, which committee or role is responsible at each stage, and which templates must be filled in along the way. Admins can start from the preset library and adapt it, or build their own from scratch.

Cases: stages, submissions, and decisions

A case is one running instance of a process type — for example, the proposal of a specific new program. When a case is created, it freezes a snapshot of the process definition, so mid-flight structural edits never change the rules of cases already in progress. At each stage, the responsible party completes the required submissions; reviewers approve, return for changes, or reject; and the case advances stage by stage until final approval.

Submission snapshots and stage decisions

Saving a draft keeps the stage editable and does not create history. When the responsible party submits the complete stage, ProgramsFlow freezes one immutable snapshot of every procedure value and attachment reference in that stage. The submitted content stays locked while it awaits a decision, so the reviewer always decides the exact material that was sent. A later resubmission creates a new numbered round without replacing the earlier one.

After the stage requirements — including any form or committee checklist — are submitted, the eligible stage reviewer sees one formal decision card. The reviewer can approve the stage, request changes in the current stage, return the request to a completed previous stage, or reject the request finally. Approval may include an optional note; every other decision requires a reason. Returning to an earlier stage reopens that stage and resets the later stages for review, while requesting changes reopens only the current stage.

The decision belongs to the role or committee responsible for the active stage and still respects organizational scope and any exclusive reviewer assignment. Each decision is permanently linked to the submitted round it reviewed, and the request history shows who submitted, who decided, when it happened, the reason, and the target stage when the request was returned. Rejection is terminal; final approval keeps the process type's existing program-creation or amendment outcome.

Deadlines, reminders, and escalation

Each stage carries an expected duration. As a stage approaches its deadline, the people responsible receive a reminder; once it is overdue, the platform escalates to administrators and the case owner. Notifications are batched into a single bilingual digest so inboxes stay quiet, and every alert deep-links straight to the case.

Amendment processes and outcome mapping

Process types that produce or amend programs declare an outcome mapping: which template field carries the courses, and which columns map to course attributes. On final approval, the mapped data replaces or creates the program content in one transaction. Amendments pre-fill the current program data so committees edit reality, not a blank form, and reviewers are warned before an amendment would blank out existing details.