Statuses in a SharePoint list should move in order: Not Started, then In Progress, then Completed, with no skipping ahead and no sliding back. SharePoint will not enforce that on its own, but Ultimate Forms will, using one hidden column that remembers the previous status and a few validation rules that compare it to the new one. Illegal transitions are refused at save, with a message that explains the rule. This guide builds the full mechanism step by step, and shows where it fits in a larger process. For that larger picture, routing, escalation, and the rest, see the complete guide to SharePoint approval workflows.
Why status order is worth enforcing
A status column with no rules is a suggestion, and suggestions lose to deadlines. The item that jumps from Not Started straight to Completed, with no work recorded in between, is how reports lie and audits fail quietly. The completed task that slides back to In Progress erases a decision someone already made. Each individual jump looks harmless; collectively they make the status column untrustworthy, and once a column is untrustworthy, every view, alert, and dashboard built on it inherits the doubt.
The requirement, as a real client stated it: tasks start as Not Started, move to In Progress, and only then transition to Completed. No skipping stages, no moving backward from a completed state. SharePoint offers no native validation logic for this; the mechanism below adds it without custom development, and the same logic works on any list or document library.
The trick: remember the previous status
Validation rules can compare columns to values and to each other, but a transition rule needs something extra: the value the status had before this edit. The whole build rests on capturing it.
Step 1: prepare the list. Create or identify the task list, with a Status choice column holding Not Started, In Progress, and Completed.
Step 2: add the hidden memory column. Create a single line of text column named Old Status. Keep it out of all views, and when you build the form in Form Designer, leave it off the form entirely so users can never edit it:
Step 3: capture the current value on every save. Configure Item ID to copy the value of Status into Old Status each time the form is saved (an action can do the same job). From now on, every edit silently records where the status stood before the user touched it:
That is the entire infrastructure: one invisible column, one copy rule. Everything else is validation.
The rules: three comparisons
With the previous value captured, each forbidden transition becomes one validation rule comparing Old Status to the new Status.
Rule 1: no skipping to the end. If Old Status is Not Started and the new Status is Completed, block the save with: "You must move the task to In Progress before marking it as Completed."
And this is how it's going to look when the form goes live:
Rule 2: no going backward. If Old Status is In Progress and the new Status is Not Started: "You cannot revert the task to Not Started once work has begun."
Rule 3: completed means completed. If Old Status is Completed and the new Status is anything else: "Completed tasks cannot be modified."
Notice what the error messages do beyond blocking: they teach. The user learns the process rule at the exact moment they tried to break it, which is the only moment the lesson is free. Write them as instructions, not as rejections.
The alternative: lock instead of validate
For the final state, permission rules offer a complementary approach: make the Status column read-only once its value is Completed. One rule allows editing while the status is anything else:
And its partner locks the column once Completed is reached:
One setting deserves attention here: Apply dynamically controls whether the rule takes effect the instant conditions change or only on the next form load. For this scenario, leave dynamic application off. If the column locks the moment the user selects Completed, a simple mis-click becomes uncorrectable before they even save. Locking on the next load gives the user their editing session to fix mistakes, and the protection thereafter.
Validation and permission rules solve slightly different problems, and mature builds often use both: validation guards the transitions, permissions seal the terminal state.
Leave a door for administrators
Strict rules need an exception path, or the first genuine mistake becomes a support ticket with no resolution. Add a condition to the rules that checks the current user: members of an Approvers or Admin group bypass the validation and can correct errors, reopen a wrongly completed task, or adjust historical records.
The exception does not weaken the process; it completes it. Regular users experience an enforced sequence, administrators retain the ability to repair, and both facts are part of the same auditable design.
Where this pattern fits
Sequential enforcement is a building block, and it combines with the rest of the approval machinery naturally.
In processes run by the Approval control, much of this comes built in: the control manages its status column internally, users cannot change it manually, and form locking guards items during and after approval. Reach for the hand-built enforcement when the status column is yours rather than the control's: operational trackers, task lists, and staged processes built from tabs and permission rules, where the status drives routing but no formal approval runs.
The pattern generalizes anywhere order matters. Project stages that must pass through review before closure. Help desk tickets that cannot close without a resolution stage. Manufacturing steps that follow a fixed sequence. Onboarding checklists where provisioning precedes access. In each case the recipe is identical: a memory column, a copy on save, and one validation rule per forbidden transition.
One design habit keeps the rule set small: enumerate the forbidden transitions, not the allowed ones. A three-status sequence needs only three rules, as above. Even a five-status process usually needs just a handful, because most transitions are either legal or already impossible in practice.
The quiet payoff
Once transitions are enforced, the status column becomes something it never was before: evidence. A Completed task provably passed through In Progress. A report counting items by status counts reality. Cycle-time measurements, stage-duration dashboards, and escalation rules watching for stuck items all stand on ground that cannot shift under them.
A process is only as real as the transitions it refuses, and refusing them costs one hidden column and a few readable rules. For how enforced statuses fit into the full approval picture, from routing patterns to audit, the complete guide to SharePoint approval workflows connects the pieces.
Frequently asked questions
Add your comment
