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.
- The statuses work moves through: New, Assigned, In progress, In review, Completed, 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, In progress or Reopened, and resumed or reassigned by someone who holds the assign permission.
- Rejected work returns as Reopened on the same task ID, with its whole history, rather than as a fresh task.
What you get
A review step before sign-off
Submitted work goes to In review and is approved or rejected by the task’s creator or someone holding the review permission. Who may review, and who may complete a task directly without review, are permissions on the role — so execution and approval are separated by how you configure roles. An admin can also let employees complete tasks they assigned to themselves without review; that setting is off by default.
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, tells the person who raised it, and waits to be resumed or reassigned.
- 4
Submit, review, approve
Finished work goes to In review. Approval completes it; rejection returns it as Reopened on the same task, ready to be worked and submitted again. A completed task can be reopened later the same way, by default by an Admin or Manager.
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 "revised vendor quote pending" typed as the reason, moves it to Blocked: the supervisor who raised it is notified and it shows on the dashboard as blocked instead of sitting quietly overdue.
- 4
Submitted
The quote arrives, work resumes, and the task is submitted for review.
- 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. Someone with the assign permission then reassigns or resumes it, or it is cancelled. 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 whose role holds the review permission. The creator exclusion is deliberate — someone who raised a task and then took it on cannot sign off their own submission unless their role holds the review permission. Reviewing is otherwise a permission like any other, so keeping approval separate from execution is a matter of which roles you grant it to.
Overdue is a date that has passed. Blocked is a deliberate statement by the assignee that they cannot proceed, with a recorded reason, which is counted on the dashboard, notified to the person who raised the task and written to the audit log.
No. The task is reopened on the same ID, 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.