In this article
Topics turn one group into a set of separate conversations that share a membership. Each has its own unread count, its own notification setting, its own pinned messages and its own link.
The feature is good. The mistake people make with it is uniform and predictable: they switch it on early, create eleven topics, and produce eleven quiet rooms where there used to be one busy one. This step is what topics actually solve and how to tell whether that is your problem.
What you will be able to do after this step
- check_circle Say what changes for members the moment topics are switched on.
- check_circle Judge whether your group has the problem topics address.
- check_circle Start with the right number of topics, which is very small.
- check_circle Mute one conversation without leaving the community.
view_kanban What actually changes
Switching topics on in a large group's settings changes the room for everybody at once. Instead of opening to a stream of messages, members open to a list of topics and choose one.
Everything that came before is preserved in a general topic, which also collects the system messages about people joining and leaving. Nothing is lost and nobody is removed.
The properties that follow are the reason to do it. Each topic has its own unread badge, so a busy corner stops making the whole room look unread. Each can be muted separately, which is the single most valuable consequence. Each has its own pinned messages, so an announcement sits above the conversation it concerns rather than competing with three others in one bar. And each has a link, which means you can point somebody at a discussion rather than at a room.
There is also a view that flattens everything back into one chronological stream with labels, for members who preferred it that way. It is worth mentioning when you announce the change, because some people strongly prefer the flat view and will otherwise assume the group has become unusable.
Four groups, and whether topics help
The question is not size. It is whether separate conversations are currently damaging each other.
Two conversations keep interrupting each other
People discussing a release while somebody else is asking for help, and both sides scrolling past things meant for them. Members have started apologising for changing the subject. This is the situation topics were built for, and it is the only one where switching them on reliably improves things.
The signal to look for is not volume but interleaving: two exchanges that are each coherent and are being read as one incoherent stream. If you can name both strands in a sentence, you have the case.
Create exactly those two topics, leave everything else in the general one, and see what happens over a fortnight. The strands that need their own space will announce themselves.
Two named conversations damaging each other is the situation topics solve. Create two topics, not seven.
One conversation, and it is a lot of messages
Busy is not the same as tangled. A room where four hundred people are all discussing the same thing is working — loudly, but working. Splitting it produces several rooms each with a quarter of the activity, and conversation does not survive division well.
The tools for volume are different ones. Muting with the mention exception from Step 055 lets members stay without being interrupted. A posting interval, from Step 060, slows a flood without breaking it up. And the archive in Step 042 lets people keep the room without it sitting at the top of their list.
If you split a busy room and the topics go quiet, that is not a configuration problem. It is evidence there was one conversation, and the correct response is to turn topics off again and apologise for the week.
Volume is not disorder. Splitting a lively room produces several dead ones — use muting and rate limits instead.
Announcements keep getting buried in the chat
A real problem, and topics are the second-best answer to it. A topic for announcements works, and members can mute the discussion while keeping it — but anybody with posting rights can still write in it, and the separation is a convention rather than a rule.
The stronger arrangement is a channel with a discussion group attached, from Step 075. In that shape only administrators can publish, every post automatically has its own comment thread, and readers who want the announcements without the conversation simply do not join the group.
Choose topics if the community is genuinely conversational and announcements are occasional. Choose the channel arrangement if you are publishing regularly to an audience that mostly reads.
Topics separate announcements by convention; a channel separates them by permission. Pick according to how much publishing you actually do.
You are setting up something new and want it organised
This is where the feature does the most damage, and the instinct behind it is entirely reasonable. Somebody starts a community, thinks ahead, and builds the structure a thriving version of it would need: introductions, support, off-topic, resources, announcements, feedback.
Then thirty people arrive to find six empty rooms and no conversation anywhere. Emptiness reads as abandonment, and nobody wants to be the first to speak into a room labelled with somebody else's plan.
Start flat. One room, all of it in one place, until a strand appears that is genuinely getting in the way of another. Structure that follows an actual conversation is structure people use, because it was named after something they were already doing.
Do not build the rooms before the conversation exists. An empty topic is worse than no topic, and a new community cannot afford to look deserted.
construction If you do switch it on
Four things make the transition go well, and they are mostly about people rather than settings.
Announce it before, not after. Members open the app to find a familiar room replaced by a list, and without a sentence of explanation a proportion of them conclude something is broken. Say what is happening, why, and that the flat view still exists.
Start with two or three topics. You can add more in a minute at any time. You cannot easily recover from a wall of empty rooms, because the first impression it makes is the one that sticks.
Name them after what people say, not after categories. "Help" beats "Support & Troubleshooting". Short names also matter practically, because the list is read at a glance and long ones are truncated.
Put the map in the general topic and pin it. One message saying what each topic is for. Step 047's approach of a single pinned index applies directly here, and it is the difference between members choosing a topic and members guessing.
touch_app Try it now — five minutes
Four steps, and the first is the test that decides whether to do anything at all.
- Read a busy day in your group and name the strands If you can write down two conversations that were interleaved, topics will help. If everything was one conversation, they will not.
- Join a community that already uses topics Look at how many there are and how many are active. The ratio is usually instructive, and it is a cheaper lesson than learning it in your own room.
- Mute a single topic somewhere you are a member This is the member-side benefit, and experiencing it is more persuasive than reading about it.
- If you switch it on, write the announcement first Two sentences: what is changing and that the flat view still exists. Post it, then make the change.
link Every topic has an address
A topic can be linked to directly, which is a small feature with three genuinely useful applications.
Onboarding. Instead of telling a new member that there is a help topic somewhere, send the link. In a community with a dozen topics, the difference between naming a place and pointing at it is most of whether somebody arrives.
The pinned map. The index described in Step 047 works especially well here: one pinned message in the general topic, each line a labelled link to a topic. A member reads the list rather than tapping through names, and you maintain one message instead of a structure.
Answering outside the group. When somebody asks you a question elsewhere that the community has already discussed, a link to the topic sends them to the conversation rather than to a room they then have to search.
Two practical limits. A link into a private group only opens for members, which is usually what you want — it is not a way of showing a topic to somebody outside. And it points at the topic rather than at a moment in it, so for a specific exchange the message link from Step 047 is the more precise tool.
help Common questions at this stage
What happens to the existing conversation when topics are enabled?
It stays, in the general topic, which becomes one topic among the others. Nothing is deleted, search still reaches all of it, and the media tabs from Step 045 continue to cover the whole group. Members do not lose anything — the change is to how new messages are organised, not to what exists.
Can members create topics?
That depends on the permissions you set, and the default is worth thinking about. Allowing anybody to create one suits a community where people organise themselves; it also produces topics for single questions that then sit empty forever. A middle path used by many rooms is to keep creation with administrators and invite people to ask, which takes a minute and keeps the list short.
Do topics work in channels?
No — they are a group feature, because they organise conversation. A channel is one stream by design. The equivalent for a channel is the discussion group in Step 075, where each post gets its own comment thread, or simply a second channel if the material is genuinely separate.
Can I turn topics off again?
The setting can be changed back, and doing so returns the group to a single stream. Treat it as a decision to announce either way rather than something to experiment with quietly, because both directions change what members see the moment they open the app. If you are unsure, the cheaper experiment is to create one topic and leave the rest of the conversation where it is.
How many topics is too many?
The practical limit is the one your members can see without scrolling, which on a phone is not many. Beyond that, the list stops being a map and becomes a menu nobody reads. A good test is whether every topic had a message in it this week; the ones that did not are either misnamed or were never separate conversations to begin with.
Does this make my group like other community platforms?
Structurally it looks similar, and the comparison is worth resisting a little. Those platforms assume people sit in a persistent window all day; Telegram assumes a phone in a pocket and a notification budget measured in single digits. That is why the muting behaviour in this step matters more than the organisation, and why a structure that would be modest elsewhere is heavy here.
At a glance
- 1What topics change
The group becomes a list of threads that members can mute one by one.
- 2When it helps
Only when separate conversations keep interrupting each other.
- 3Start small
Open two or three topics; empty ones look abandoned.
Updated
