Tasks & projects

Why two tools and not one?

Most CRMs bolt a task list onto the lead record and stop. Most project tools start from a board and never learn what a lead is. Sales teams live in between: the work before the signature is a stream of small dated promises, and the work after it is a delivery with stages, owners and a checklist nobody wants to keep in their head.

Forcing both into one shape makes both worse. A kanban card is the wrong place for "call back at 14:00", and a flat task list is the wrong place for a three-week onboarding with eleven steps across four people. So there are two tools, deliberately different, sharing the same people, permissions, notifications and the same link back to the lead or deal.

The rule of thumb that works for most teams: a task is something one person does by a date; a project is something a team finishes in stages. When a task grows sub-tasks and stages, it has become a project and should move to a board.

What a task is here

Title, description, deadline

The obvious three. The deadline is what sorts the personal queue and what turns a task red when it passes.

Assignee, or several

A task has a primary owner and can carry additional assignees. The owner gets the assignment e-mail (if that notification is switched on) and the in-app bell.

Linked contact and deal

A task created from a lead card or a deal keeps that link, so it appears in the lead's timeline and the deal's activity, and the salesperson opens the right record in one click.

Sub-tasks

A task can have child tasks. This is the pressure valve before something becomes a project: "prepare proposal" with three children is still a task; when the children need stages, it is a board.

Order

The list is drag-sortable, so the order you work in is the order you see, not the order things were created.

Completing a one-off task marks it done; completing a recurring task logs this period as done and leaves the task alive for the next one — see below.

Recurring tasks and period history

A great deal of sales work repeats: the Monday pipeline review, the weekly check-in with a key account, the monthly statement to a distributor. Recurring tasks exist so that these are not re-created by hand every week and quietly forgotten one week in three.

The important design choice is that a recurring task is never closed. Each completion writes a row for the current period — who completed it and when — and the task shows a badge for the period: pending, or done this period. Uncompleting removes the period row. That gives you two things a simple checkbox cannot: a task that comes back on its own, and a history you can open to see that the weekly review was skipped in weeks 32 and 35.

Recurrence works identically on standalone tasks and on cards inside project boards, and the same history modal is available in both places.

What a project board is

A project is a kanban board: columns you name and reorder, cards that move between them, members who can see it. There are no prescribed columns — a clinic might use Booked → Prepared → Treated → Follow-up, an agency Brief → Draft → Client review → Live.

Cards are dragged between columns; the move is saved immediately. Columns can be added, renamed and reordered per board. Project membership decides who sees the board at all, and the standard permission model (view / create / edit / delete on projects) decides what they can do on it.

Checklists and the activity trail

The checklist inside a card is where delivery actually happens. Each item is a one-click toggle and the card shows done-over-total, so a board read from across the room already tells you how far each piece of work has got.

Every toggle is logged. The card's activity view lists who ticked what and when, and period completions of recurring cards land in the same log, labelled with the period ("Weekly — 2026-W38"). This is a small feature with a large effect on arguments: "I did that on Tuesday" is either in the log or it is not.

Tasks that create themselves

The tasks that matter most are usually the ones nobody remembers to create. The automation module can create a task as an action — when a lead enters a stage, when a form is submitted, when a deal has been idle for N days — and assign it to the owner or a specific person with a relative due date.

It also works in the other direction: task completed is a trigger. Completing "send the proposal" can move the deal to the next stage, notify a manager, or start a follow-up sequence. A task created by an automation remembers which one created it, so you can trace a mysterious to-do back to its rule.

Flow Boards

Next to projects sits a whiteboard: an infinite canvas with shapes, sticky notes, text, freehand drawing and arrows that stay attached to the shapes they connect. It exists for the part of work that is not yet a task list — the sales process you are redesigning, the onboarding flow you are explaining to a new hire, the decision tree for qualifying a lead.

Boards autosave, support undo/redo, copy and paste across boards, PNG export, and per-board permissions (owner, editor, viewer). A decision-box element has option chips with their own arrow ports, which is the piece most whiteboards lack when you try to draw a real qualification flow. No external service is involved; the board lives in your workspace.

What you can measure

Tasks are a dataset in the pivot report builder, alongside leads, deals, calls and products. Reports that tend to matter:

• Open and overdue tasks per person — the load view, and the earliest sign someone is under water.
• Completed tasks per week per person — throughput, useful against pipeline movement.
• Recurring-task compliance — from the period history: which routines are actually being done.
• Tasks by linked deal stage — where in the pipeline the work piles up.
• Automation-created versus manual tasks — how much of the follow-up the system is generating on its own.

Overdue tasks also stand out in each person's own list and in the live notification bell, so the report is the second place you learn about them, not the first.

When work goes missing

How tasks connect to the rest

Task → lead and deal

Tasks are created from the lead card and the deal, keep the link, and appear in both timelines.

Automation → task → automation

A rule can create a task; completing a task can fire a rule. Together they make the pipeline advance on real work, not on drag-and-drop.

Task → notifications and e-mail

Assignment rings the live bell and, if enabled, sends an e-mail using your chosen template.

Task → reports

Tasks are a pivot dataset; period history makes recurring compliance measurable.

Project → permissions and departments

Board visibility follows membership and the projects permission set; department scope applies the same way as everywhere else.

Task → activity log

Task actions are written to the workspace activity log, so an admin can answer who changed what.

Which plan includes what?

Tasks with deadlines, assignees, sub-tasks, deal and lead links, recurrence and period history are on every plan. Flow Boards arrive with Growth, together with the automation module. Project boards are a Business feature. See the pricing page for the full comparison and automations for the rules that create and react to tasks.