Groups and departments

What you will learn What each of groups and departments groups, how to layer them, and why per-person permission management collapses.

The names are confusing. Start here. A thread group groups conversations. Not people. A department groups people. So you layer them, as in "only Sales can see this thread group."

Each group can carry a colour, which is what distinguishes them at a glance in the sidebar. Note that the screen describes it as organising chats into groups — chats, not people.

Per-person management collapses

With five members, configuring each person is fine. At thirty it becomes this:

You reach the point where nobody can describe the current state. That is why you need groupings.

Two groupings — they group different things

graph TD
  W["Workspace"] --> D["Department<br/>groups people"]
  W --> G["Thread group<br/>groups conversations"]
  D --> M["member · member · member"]
  G --> T["thread · thread · thread"]
  D -.->|"only this department can see it"| G

The dotted line is the key. Set a thread group to "selected members only" and you can designate who sees it by department.

The departments screen. Mirror your org chart here and a staff move is just a change of membership.

Departments — grouping people by the org chart

Build it to match your actual org chart.

When to use it: when default permissions follow organisational structure. When someone transfers, you change only their department.

Thread groups — grouping conversations by topic

Drawers that hold conversations by topic or project, so your sidebar does not scatter. Each group can have a colour and an order.

On top of that you layer who can see it.

Under "selected members only," designate departments rather than individuals. Designate individuals and every departure or transfer means editing groups one by one, and when that slips, someone who left keeps seeing them. Designate departments and changing their membership carries everything with it.

Thread groups can also carry their own set of usable agents — you choose whether to inherit the workspace setting or differ for this group.

Grant permissions to departments, not people

This is the core of the chapter.

Thread group visibility works the same way.

Granting permission to a new joiner becomes one action: "add to department." Nothing gets missed.

How to start

There is no need for complexity at the start.

Create them when you need them. Creating them in advance only adds things to manage.

The sidebar shows only the groups you joined

If every visible group were in the sidebar, someone joining a workspace with thirty groups would get thirty rows on day one. So the sidebar draws joined groups only.

For the rest, go in through browse groups.

The list contains only what you may see. Leaking even the name of a selectively-visible group is a disclosure, so without access it does not exist as far as the screen is concerned.

Groups you have already joined are shown too — half the people who open this screen came to check "am I in that one?". Leaving is also done here.

Tidying the sidebar — sections, favourites, mute

Sidebars get long as groups accumulate. There are three tools.

All three are personal. Tidying yours leaves your teammates' sidebars untouched. Sections can be reordered by dragging and collapsed.

Practical tips

Put the purpose in thread group names

You have to be able to recognise a finished group to tidy up.

Give temporary groups an end date

When a project ends and the group remains, your sidebar just gets longer. Note "until when" as you create it.

Match departments to the real org chart

Invent your own and every transfer causes confusion. Copying the org chart from the HR system is easier to maintain.

Periodic review

Check yourself

1. What do departments and thread groups each group?

2. Why grant permissions to groupings rather than individuals?

3. At ten people, what should you create first?

Now how to see the cost → Usage and credits