Skip to main content
Every task in TaskFlow Pro has a estado (state) field that tracks where it sits in the delivery process. Tasks move forward through four states, and different roles control which transitions they can trigger.

​
The four states

TODO

The task has been created and assigned but work has not started. This is the default state for all new tasks.

IN_PROGRESS

A developer is actively working on the task. The assigned developer or a PM/Admin has picked it up.

IN_REVIEW

Work is complete and the task is awaiting review or QA. Blocked until a PM or Admin marks it done.

DONE

The task has been reviewed and accepted. Only a Project Manager or Admin can set this final state.

​
State transition diagram

workflow
TODO  ──────────────────►  IN_PROGRESS  ──────────────────►  IN_REVIEW  ──────────────────►  DONE
        Dev (own task)                    Dev (own task)                   PM / Admin only
        PM / Admin (any)                  PM / Admin (any)
Transitions are one-directional. The API does not support moving a task backward (e.g., from IN_REVIEW back to IN_PROGRESS). If a task needs to be reworked, a PM or Admin must edit the task directly via PUT /tareas/actualizar.

​
Workflow step by step

1

Task created — TODO

Any authenticated user can create a task via POST /tareas. The creator specifies the title, description, priority, due date, project, and the user to assign the task to. The state is automatically set to TODO.The assigned developer can now see the task in their task list via GET /tareas.
2

Work begins — IN_PROGRESS

When the developer is ready to start, they call the developer-specific endpoint to move their own task forward:
developer endpoint
PUT /tareas/curso/dev
Developer The service validates that assigned_to matches the requesting user’s id. A developer cannot move a task assigned to someone else.A Project Manager or Admin can move any task to IN_PROGRESS without the ownership restriction:
pm and admin endpoint
PUT /tareas/curso
Project ManagerAdmin
3

Work complete — IN_REVIEW

When the developer has finished, they submit the task for review:
developer endpoint
PUT /tareas/review/dev
Developer Again, the service checks that the requesting user is the one assigned to the task.A PM or Admin can move any task to IN_REVIEW directly:
pm and admin endpoint
PUT /tareas/review
Project ManagerAdmin
4

Accepted — DONE

Only a Project Manager or Admin can close the loop and mark a task as done:
pm and admin endpoint
PUT /tareas/done
Project ManagerAdminOnce a task reaches DONE it is complete. The record remains in the database and is visible in task lists and project views.

​
Who can trigger each transition

TransitionDeveloper (own task)Developer (other’s task)PM / Admin
TODO → IN_PROGRESS✓—✓
IN_PROGRESS → IN_REVIEW✓—✓
IN_REVIEW → DONE——✓

​
Deleting a task

Tasks can be deleted before or after completion with DELETE /tarea. Only a Project Manager or Admin can delete tasks. Deleting a task also deletes all of its comments due to the ON DELETE CASCADE constraint on the comments table.
Task deletion is permanent. There is no soft delete on tasks — once removed, the task and all associated comments are gone from the database.

Build docs developers (and LLMs) love

Get started for freeTalk to us