Google shared tasks for a team: where sharing a task list runs out

Most people who search for google shared tasks have a picture in mind before they start: one list, several names on it, everyone looking at the same thing. Google Tasks does not work that way, and the distance between that picture and the product is exactly why the search happens.

What Google offers is narrower and more specific than list sharing, and it behaves in ways that matter once more than two people depend on it. The useful move is not to hunt for a hidden sharing button. It is to understand what unit Google actually shares, what that unit loses when it becomes shared, and at what point a list stops being the right shape for the work.

Sharing happens per task, not per list

Google's own documentation calls the feature shared tasks. Not shared lists. That wording is the whole story. A task list in Google Tasks belongs to one account and stays there. What can cross between accounts is an individual task with an assignee attached to it.

The practical consequence is that there is no single place where a team's work sits. There is one personal list per person, plus a surface where assignments were made. When a task is assigned, Google's help page on shared tasks states that it goes into the assignee's default list in Tasks, and that the task appears in their personal task list, in the shared surface such as a space or document, and in Google Calendar if the task has a date and time.

Note the direction of that flow. Work travels outward into individual lists. It does not gather into a shared one. Anyone trying to answer the question "what is outstanding across the team right now" has to reassemble it from the space or the document, because Tasks itself will only ever show one person's list.

Capacity is not the constraint here. Google documents that across all lists you can create up to 100,000 tasks, and up to 20,000 uncompleted tasks in any single list. Nobody hits those numbers. The ceiling that gets hit is structural, and it arrives at around the third person.

The two surfaces that can create a shared task

A shared task cannot be created inside Tasks. It has to be created somewhere else, and there are exactly two places.

A space in Google Chat. Open the space, use the Tasks tab, add a task and assign it to a member of that space. When someone creates or updates a task, a notification appears in the space, and if the task has a date and time, notifications arrive in Chat at those times. Google notes that on a work or school account, an administrator may have to turn the Tasks tab on before it appears at all.

A Google Doc. Typing @task in the document opens a small panel with an assignee field. The assignee has to be someone in the same domain. Google is explicit that this path is available only on eligible Google Workspace plans, which means a personal Gmail account cannot use it. The assignee receives an email notification that includes the assigner's email address.

	Chat space	Google Doc
Who can be assigned	A member of the space	A user in the same domain
Account requirement	Tasks tab may need an admin to enable it	An eligible Google Workspace plan
How the assignee hears about it	Notification in the space	Email notification
Where the task lands	Assignee's default Tasks list	Assignee's default Tasks list
Audit trail	Space history	Document version history

Both surfaces send notifications on the same set of events: a task created, assigned, reassigned or unassigned, completed or marked incomplete, and deleted without being completed. Changes a person makes themselves produce no notification for that person, which is sensible, and also means the assigner learns about progress only through the same feed everyone else reads.

What a shared task gives up

This is the part that surprises people, and it is stated plainly in Google's documentation: you can neither create a subtask nor repeat shared tasks.

Both of those are the features that make Google Tasks pleasant for one person. Breaking a large item into subtasks is how a vague task becomes a doable one. Recurrence is how routine work stops needing to be remembered. A shared task has neither.

That has a direct effect on the kind of work a team can put in there. Recurring operational work is the obvious casualty. A weekly report, a monthly invoice run, a quarterly access review: these are the tasks most worth assigning to a named person, and they are precisely the tasks that cannot be assigned as repeating items. The workaround is someone manually recreating them, which puts the reliability of the process back inside one person's memory.

The default list behaviour compounds it. Assigned tasks arrive in the assignee's default list, mixed in with their personal items. They can be moved afterwards, but that is a manual step each person has to remember to take. A team that has agreed on a tidy list structure will find that structure bypassed by every incoming assignment.

Who holds a shared task when something is deleted

Once tasks live in two places at once, the interesting question is what happens when one of those places goes away. Google documents the answers, and reading them is worth ten minutes before a team commits to this arrangement.

Deleting a shared task removes it from both the personal list and the shared surface. In Chat, related messages stay in the space until someone deletes them. In a Doc, the behaviour depends on permissions: with edit access, the task stops showing in the document while the checklist item and its text remain, and without edit access, the task shows as deleted next to the checklist item until a collaborator with edit access accepts the change.

If the whole space or document is deleted, the two surfaces diverge. In Chat, every task in that space is deleted, including from the assignees' personal lists. In Docs, the tasks stay on the personal list, but the linked document can no longer be opened because it is gone.

If a Google Account is deleted, tasks assigned to that person are unassigned in Chat but stay in the space, while in Docs they stay in the document and are shown as assigned to an unknown user. If someone loses access to the space or document, their tasks remain assigned to them and their changes still flow back into the shared surface.

Two things follow from all of this. First, the authoritative history of who completed what does not live in Tasks. Google's own guidance is that access to the space or document history is what lets you confirm who completed a task or changed an assignee. Second, a Chat space is a load-bearing container. Archiving or deleting one takes real work with it.

What third-party layers add, and what they cannot

A second search usually follows the first, and it leads to tools that sit on top of the Google Tasks API and add what the native product lacks. TasksBoard is the best known of them. It provides a full screen kanban view of Google Tasks lists and, unlike Google, shares lists rather than individual tasks.

The limits are published. On the free tier, TasksBoard's own support page states that you can share up to 5 lists with any TasksBoard account, and the paid tier lifts that to unlimited. One detail in that page is worth reading twice: the limit persists on free tier accounts, so a colleague on the free tier can only share a maximum of 5 lists back. Sharing capacity depends on both ends of the connection, not just on who is paying.

What a layer of this kind cannot add is anything the underlying data model does not hold. These tools read and write Google Tasks, so a task is still a title, notes, a date and a done flag. There is no concept of a stage between not started and finished, no dependency between two items, no way to express that one piece of work has to wait for another, and no view of who is carrying how much. Those are not gaps in the third-party app. They are properties of what it is built on.

When the list is the wrong shape, not the wrong tool

Google Tasks is genuinely good at one thing that most project tools are bad at: capturing an item in the two seconds after it appears, inside Gmail or Calendar, without leaving what you were doing. That is worth protecting, and it is the reason a team should not discard it lightly.

The signal that the shape has run out is usually one of these five, and one is enough:

• Somebody maintains a private map, in a spreadsheet or in their head, of who currently has what.
• Work has stages, but a task can only be done or not done, so status gets written into task titles.
• Order matters, and there is no way to say that one item has to finish before another starts.
• Load across people has to be visible before the next thing is handed out.
• The discussion about a task happens somewhere the task cannot see, so the decision and the item drift apart.

Each of those is a request for structure the list format does not have. At that point the question changes from how to share a list to what shape the work actually is. Work with stages wants a board. Work with sequence wants a timeline. Work with people and hours wants a view that shows both. A kanban board tool with several board types in one place answers a different question from the one Google Tasks answers, and that is the reason to look at it, not because the list is bad.

It is worth being honest about the cost of moving. Most board tools do not match the capture speed of a task typed into the Gmail side panel, and a team that adopts one without keeping some frictionless way to capture will start losing items at the front of the process rather than the middle. Check how a candidate handles that before anything else. For teams already comparing the obvious options, the comparison against Trello covers the board-only case, and how plans are priced matters more than feature counts once a team crosses about five people.

What to change first

Pick one list that more than two people depend on, and write down which of the five signals above it is showing. If none of them apply, stay where you are and use Chat space tasks for the handoffs. If two or more apply, move that one list onto a board and leave everything else in Tasks, so the comparison is real rather than theoretical. Pinateca is one place to run that test, with kanban, Gantt, calendar and timetable boards available from the start.

Q1. Can two people edit the same Google Tasks list?

No. A task list belongs to a single Google account and cannot be opened by another account. What Google supports is assigning an individual task to someone from a Chat space or a Google Doc, which places a copy of that task in the assignee's own default list.

Q2. Why can a shared task not repeat?

Google documents that shared tasks support neither subtasks nor recurrence. The limitation applies the moment a task has an assignee, which means routine recurring work has to be recreated by hand each cycle if it needs to sit with a named person.

Q3. Does assigning tasks in Google Docs work on a personal Gmail account?

No. Google states that task assignment from Docs requires an eligible Google Workspace plan, and the assignee has to be a user in the same domain. On a personal account the @task option is not available, so a Chat space is the only native route.

Q4. What happens to assigned tasks if the Chat space is deleted?

In Chat, deleting the space deletes every task in it, including from the personal task lists of the people they were assigned to. Google Docs behaves differently: the tasks stay on the personal list, but the link to the document no longer opens.

Q5. Is a third-party app enough, or is a different tool needed?

An app such as TasksBoard adds list sharing and a board view on top of Google Tasks, which solves visibility. It cannot add stages, dependencies or workload views, because the underlying task record does not hold them. If those are the missing pieces, the format is the constraint rather than the interface.