Per task embedded whiteboards with freeform paths, shapes, text, and images. Real time collaborative drawing via Pusher. Fullscreen mode, data persistence, and task level access control.
Every TARO task has a whiteboard tab. Open it, draw anything, and every collaborator on the task sees every stroke in real time with the canvas persisted exactly as you left it every time you return.
Draw
TARO's whiteboard toolbar provides four drawing tool types covering every kind of content a team puts on a canvas during task planning or design review. Freeform paths let you annotate freely circle something, draw an arrow, sketch a rough layout. Shapes give you precision rectangles, circles, and lines for architecture diagrams and flow charts. Text blocks for labels and annotations. Image upload for dropping in a screenshot, a mockup, or a reference directly onto the canvas where it's needed.
Collaborate
TARO's whiteboard runs on a dedicated Pusher WebSocket channel per board the same infrastructure that powers the Kanban board and task event stream. Every drawing operation fires an event on the channel: stroke start, stroke path updates, stroke end, shape placement, text edits, image drops, and element moves. All collaborators on the task who have the whiteboard open receive every event in real time, with cursor positions tracked per participant so you see exactly where each person is drawing. The session is genuinely shared not a screen share of one person's canvas.
Focus & Persist
When a whiteboard session needs full focus a design review, an architecture session, a sprint planning diagram fullscreen mode expands the canvas to fill the entire browser window with just the toolbar visible. The task panel, sidebar, and navigation disappear. The canvas is the session. When fullscreen closes, TARO returns to the task exactly where it was. Every stroke, shape, text block, and image placed on the canvas is persisted automatically to the database no save button, no export required. Opening the whiteboard tab on any subsequent visit returns the canvas to its exact saved state.
Access
Whiteboard access is not a separate permission to configure. It inherits directly from the task's existing access control whoever can view or edit the task can view or edit the whiteboard. Task owners and contributors can draw and modify the canvas. Task viewers see the whiteboard in read only mode they can open the canvas, pan, zoom, and see all content, but cannot draw, erase, or move elements. This means the whiteboard needs zero additional access configuration: the task already defines who gets in.
A whiteboard that lives inside the task it belongs to never goes stale. A diagram that's three Figma links removed from the task it annotates gets forgotten in a week.
The whiteboard lives inside the task it belongs to in a dedicated tab alongside the description, comments, and files. A diagram sketched during a planning discussion is still there the next time anyone opens the task. No external link to follow. No Figma board to remember. No Miro frame to find.
Every stroke appears on every collaborator's canvas the instant it's drawn. The whiteboard session is not a screen share where one person drives it's a shared surface where every participant draws simultaneously and sees every other participant's cursor in real time.
Architecture sessions and design reviews need space not a 400px panel embedded inside a task sidebar. Fullscreen expands the canvas to the full browser window with one click. Every collaborator sees the same expanded canvas whether they're in fullscreen or embedded mode.
Every stroke is persisted immediately. There is no save button, no unsaved state, and no "do you want to save before closing?" prompt. A mid session crash, an accidental tab close, a network hiccup none of them lose a single element from the canvas.
Whiteboard access is inherited from the task's permission model no separate share link to generate, no whiteboard specific permissions to manage. Adding someone to the task automatically gives them the right level of access to the whiteboard without any additional action.
Every session is snapshotted. A design that was sketched during sprint planning and progressively annotated over three sprints has a full history of every state it passed through. Restoring any previous version takes one click turning the whiteboard into a visual record of how thinking evolved, not just where it landed.
No Figma. No Miro. No extra link. The canvas is already in the task.
Engineering teams sketching system architecture and design teams annotating mockups both need the same thing: a canvas that lives next to the work it describes, not three tools away in a separate application.
800+ product teams
already using TARO
Drawing tool types
Canvas per task
Save actions needed
Engineering teams open the whiteboard tab on a task to sketch the system design before implementation begins. The lead draws the initial architecture in fullscreen with the backend team drawing annotations and raising questions in real time. When the session ends, the canvas is automatically saved. Every subsequent engineer who opens the task sees the exact diagram that was agreed upon with version history showing how it evolved from the initial sketch to the final design.
The architecture sketched on the whiteboard becomes the task structure, the dependencies, the sprint commitment, and eventually the completed delivery all in the same platform.
The task that contains the whiteboard is also where subtasks, assignees, due dates, dependencies, and time tracking live turning a whiteboard session directly into a structured delivery plan without switching tools.
The same Pusher WebSocket infrastructure that powers the whiteboard also pushes task assignments, status changes, and comments so the entire task collaboration layer shares the same live sync.
Comments on the task live alongside the whiteboard so the text discussion and the visual diagram are in the same panel. No switching between the whiteboard and a Slack thread to track what was said about what was drawn.
Architecture diagrams sketched on the whiteboard often reveal the dependency structure of the work. Task Dependencies lets you formalise those relationships directly on the tasks the whiteboard was embedded in.
The task that contains the whiteboard is also where subtasks, assignees, due dates, dependencies, and time tracking live turning a whiteboard session directly into a structured delivery plan without switching tools.
The same Pusher WebSocket infrastructure that powers the whiteboard also pushes task assignments, status changes, and comments so the entire task collaboration layer shares the same live sync.
Comments on the task live alongside the whiteboard so the text discussion and the visual diagram are in the same panel. No switching between the whiteboard and a Slack thread to track what was said about what was drawn.
Architecture diagrams sketched on the whiteboard often reveal the dependency structure of the work. Task Dependencies lets you formalise those relationships directly on the tasks the whiteboard was embedded in.
Common questions from engineering leads, designers, and product managers evaluating TARO's whiteboard.
TARO uses a last write wins approach for element modifications when two collaborators move or resize the same element simultaneously, the most recent operation wins and is broadcast to all clients. This is appropriate for whiteboard use because conflicting simultaneous edits of the same element are rare in practice: cursors are visible, users naturally work in different areas of the canvas, and a slight position override is a trivially correctable situation. Freeform paths are never subject to conflict each path belongs entirely to the user who drew it and cannot be modified by another user while being drawn. After a path is complete, any collaborator can select and move it, with the same last write wins resolution.
It lives in the task now. Auto saved. Collaboratively drawn. Always there when you come back.