SOURCE-BASED ANALYSIS · NO HANDS-ON RATING
Do not infer hierarchy inheritance
Todoist states that sharing a parent project does not automatically give a collaborator access to its sub-projects. Within a shared project, collaborators can see its tasks, comments and file attachments and can add, assign and complete work. Treat each project boundary as an independent access decision.
Create a hierarchy fixture
Build a fictional parent called Product launch with two sub-projects: Public checklist and Restricted finance. Invite a test collaborator only to the parent, then inspect each level before adding any further invitation.
| Location | Expected access | Evidence |
|---|---|---|
| Shared parent | Visible and editable | Task and comment test |
| Unshared public sub-project | No automatic access | Invitation state |
| Restricted sub-project | No access | Attachment remains unavailable |
| Explicitly shared sub-project | Full project collaboration | Assignment and completion |
Review the content exposed by one invitation
Project sharing includes tasks, comments and attachments. Remove real files and personal information from the fixture. If an invitation link is used, document where it was distributed and revoke or replace it when the collaboration period ends.
- Map the parent and every sub-project.
- Classify tasks, comments and attachments by audience.
- Invite the collaborator only to the parent.
- Confirm sub-projects remain unavailable.
- Share only the sub-projects needed for the role.
- Test assignment, comments and file access.
- Remove access and links during project closeout.
Accept deliberate project boundaries
Accept the structure when access at every level matches an explicit invitation and restricted attachments cannot be reached from shared work. Do not use visual nesting as evidence of inherited access.
Sources and verification
Official documentation checked on 2026-10-29. Worked examples are hypothetical planning exercises, not measured product benchmarks.