Chat
Chat
This domain tests the messaging layer: channels, threads, contextual chat inside Spaces, and the boundary between conversation and task comments.
How Chat is structured
- Chat provides public channels anyone in the workspace can join, private invite-only channels, and direct messages. Threads and replies keep side discussions out of the main flow.
- A Chat view can be added to a Space, Folder, or List so conversation stays attached to the work it concerns.
- Channel membership is independent of task permissions. Being in a channel about a List does not grant access to that List, and losing task access does not remove you from the channel.
- Admins control who can create channels, who can DM whom, message editing and deletion, and retention.
- Comments are different: a comment belongs to a task, travels with it, appears in task activity, and is part of the record. Chat is a separate stream.
- Guests can participate only where they have been invited and shared.
Worked example
An agency gives each client a private channel with the account team, plus a Chat view inside the client Space for async standups. The client is added to that channel and to their project List, but not to internal channels. The reasoning: two separate grants are needed. Sharing the List gives access to the work; adding them to the channel gives access to the conversation, and neither implies the other.
Traps that cost marks
- Assuming channel members can open tasks linked in the channel. They may hit a permission wall.
- Assuming task comments appear in Chat, or that chat replies are recorded on the task.
- Believing deleting a message removes it everywhere. Retention and export policies apply.
- Assuming a private channel is invisible to workspace admins, who can manage channels.
- Inviting a guest to a channel and expecting that to share the underlying Lists.