Work follows the same route every single time
A workflow is only real if the system refuses the steps that break it. Every task moves through one defined lifecycle — accepted, progressed, handed over, blocked, submitted, reviewed — and a transition that does not make sense is rejected rather than recorded.
No rule builder to configure. The lifecycle ships working.
The problem
A process that only exists in a document is not a process
Most teams have a written procedure and a real procedure, and the two diverge within a month. The written one says work is checked before it is closed; the real one says whoever finishes it marks it done.
- Anyone can mark anything complete, so "completed" means "someone said so".
- Steps are skipped under pressure and there is no record that they were skipped.
- Work that is stuck looks exactly like work that is progressing — both are simply open.
- Reviews happen when someone remembers to ask for one.
- When something goes wrong, nobody can reconstruct which step failed, because no step was ever recorded as having happened.
How TaskIt handles it
One transition table, applied by the server
The lifecycle is not a suggestion in the interface. It is a table of permitted transitions the API enforces, so the same rules apply however a request arrives.
- Twelve statuses: New, Assigned, Accepted, In progress, Handover, In review, Approved, Completed, Rejected, Reopened, Blocked and Cancelled.
- Accepting starts the task in one step — Assigned to In progress, stamping the start time — so there is no separate action to forget.
- A department task is created unowned and goes straight to In progress when someone claims it, skipping Assigned because nobody was assigned.
- Blocked is a real state with a recorded reason, reachable from Assigned, Accepted, In progress or Reopened, and resolved only by a manager action.
- Rejected work returns as Reopened on the same task ID, with the reviewer’s reason attached, rather than as a fresh task.
What you get
Done means reviewed
Submitted work goes to In review and is approved or rejected by the task’s creator or someone holding the review permission. A creator who is also the current assignee is excluded, so nobody signs off their own work.
Stuck work raises its hand
Unable to Complete moves a task to Blocked with a reason from a predefined list or the person’s own wording. It stops being indistinguishable from work that is simply taking a while.
The route is auditable afterwards
Each transition writes an activity entry with a timestamp, and the significant ones write audit entries too. Reconstructing what happened is reading a list, not interviewing people.
No workflow designer to maintain
There is nothing to draw and nothing to keep in sync with reality. The lifecycle is the same in every workspace, which is also why it cannot drift.
How it works
In the order a person using it meets them.
- 1
Raise and route
A task is created for a named person or for a department. Individual work starts at Assigned; department work starts unowned at New.
- 2
Accept
The assignee — or the first eligible department member — accepts, which moves the task to In progress and stamps the moment work actually began.
- 3
Progress, hand over, or block
Progress updates and comments build the activity trail. A handover moves ownership with a full record. Unable to Complete moves it to Blocked with a reason and waits for a manager.
- 4
Submit, review, approve
Finished work goes to In review. Approval takes it to Approved and then Completed; rejection returns it as Reopened with the reason recorded on the task.
A purchase approval, step by step
The same five-step process every time, without a document telling people what the five steps are.
- 1
Raised
A supervisor creates the request against the purchase task form, which captures vendor, amount and justification as real fields.
- 2
Accepted
Accounts accepts from the department queue. The task moves to In progress and the clock starts.
- 3
Blocked, briefly
The vendor has not sent a revised quote. Unable to Complete with "waiting for customer or vendor" moves it to Blocked, and it appears on the manager’s attention queue instead of sitting quietly overdue.
- 4
Submitted
The quote arrives, work resumes, and the task is submitted for review with the purchase order attached.
- 5
Approved
The supervisor who raised it approves. The task reaches Completed with every step and every timestamp in order.
The result
Nobody could have marked this complete without a review, and nobody had to check whether they had.
What the transition table refuses
The permitted moves are defined once and checked server-side, so an unexpected sequence cannot be written by a stale browser tab, a double click or a direct API call. Completed and cancelled tasks are terminal for editing — a rename against either is refused rather than silently ignored.
Review, one task or two hundred
Bulk review applies one decision to up to 200 tasks awaiting review in a single request, reusing exactly the same eligibility check and the same transition as the single-task path — so a task can never be reviewed differently depending on which route was used.
- Each task comes back individually as reviewed, skipped or failed
- A task another reviewer has already decided comes back skipped, not overwritten
- One failure never aborts the batch, and repeated ids are de-duplicated
Blocked work and who resolves it
Twelve predefined reasons cover the common causes — waiting for a customer, waiting for approval, material not available and so on — plus free text, which is remembered per person for reuse. A manager then reassigns, resumes, reopens or cancels. On a collaborative task, blocking stays owner-only: it speaks for the whole task, and one stuck collaborator should not halt everyone else.
Where TaskIt stops
This is a fixed lifecycle, not a configurable process engine. There is no visual workflow designer, no branching rule builder and no conditional routing between arbitrary stages. If your requirement is a diagram of stages you draw yourself, that is a different category of product — and it is worth knowing before a trial rather than after one.
Frequently asked questions
No. TaskIt ships one defined task lifecycle and enforces it; there is no visual workflow designer or rule builder. What you configure is who may do what, which task fields are captured, which departments work is routed to and which events send notifications.
The task’s creator, unless they are also the current assignee, or anyone holding the review permission. That exclusion is deliberate: nobody reviews their own submission.
Overdue is a date that has passed. Blocked is a deliberate statement by the assignee that they cannot proceed, with a recorded reason, which appears on the manager’s attention queue and in the audit log.
No. The task moves to Rejected and then Reopened on the same ID, with the reviewer’s reason attached, so the second attempt sits in the same history as the first.
Where to go next
The capabilities either side of this one, and the problems it is bought to solve.
Run your real process through it
Pick the process people most often skip a step in, and see what the record looks like when the system will not let them.