I am writing to report a persistent bug in the Google Groups interface that is severely impacting the productivity of teams using groups as a Collaborative Inbox. Despite reporting this to Google Workspace support, the official response is that the feature is “working as designed,” which is incorrect and fails to address the core problem. Also they don’t understand the issue and they told me to use Gmail instead of Google Groups to manage Groups messages.
Problem Summary (TL;DR)
When a team member replies to a conversation from the Google Groups web interface (groups.google.com) and chooses to reply as the group (using the group’s email address instead of their personal one), the conversation never gets permanently marked as read. Upon refreshing the page, the thread reverts to “unread,” making it impossible to track which conversations have been handled.
It is only marked as read if, once the response is sent, if wait several minutes and then mark it as read manually.
Steps to Replicate the Bug
This behavior can be consistently reproduced with the following steps:
Set up a group with the “Collaborative Inbox” feature enabled.
Receive a new message in the group. The conversation will appear as unread.
Open the conversation in the Google Groups interface.
Click “Reply.” In the sender field, select the group’s email addressinstead of the author’s address.
Send the reply.
Return to the conversation list.
Refresh the browser page (F5 or Ctrl+R).
Result: The conversation, despite having been replied to, appears as unread again.
Manually mark the thread as “read” after it reverts to unread, it will revert to unread again after a few minutes and another refresh.
Only after manually marking it as read several times and waiting a considerable amount of time does the “read” status finally stick.
It is crucial to note that this problem does not occur if you reply using your personal email address. The bug is exclusively tied to the “Reply as group” action.
This is a Blocker for Organizations using Google Groups to manage clients, issues… Wasting time reviewing threads that have already been handled. A complete lack of reliability in a core collaboration tool.
I would like to specifically address the explanation provided by the support team, which claims that the “read/unread” status is designed to sync one-way from Gmail to Google Groups.
Based on my extensive testing, this explanation is flawed and does not accurately describe the functionality or the root cause of the bug I am reporting.
I wanted to provide a significant update on my ongoing support case regarding this bug. After providing more evidence, including HAR files and screen recordings showing the bug happening in one group but not a brand-new one, the support team returned with a new and perplexing explanation.
The Latest “Working as Designed” Theory
The support team’s latest theory is that this behavior is, once again, “working as designed.” According to them, a conversation you reply to will only be marked as “read” for you after another member of the group opens it first.
Their logic is that the system treats your own reply as a new message sent to others, and it won’t consider it “read” by you until it’s been viewed by another recipient. Their proposed “solution” was literally to add more members to the group.
Why This Explanation is Flawed
This explanation is demonstrably incorrect and contradicts both how Google Groups functions and the evidence I provided:
It Fails in Single-Member Groups: My video evidence, which support acknowledged, showed these tests being performed in groups where I am the sole member. For a brief period, a brand-new, single-member group actually worked correctly, which directly contradicts the theory that another member’s action is required.
“Read/Unread” is a Per-User Status: Fundamentally, the “read/unread” status in Google Groups is an individual attribute. Whether another member has read a conversation has never affected whether it appears as read or unread for me. The “Mark all as read” function is further proof of this per-user design.
It Doesn’t Explain the Erratic Behavior: If this were intended behavior, the conversation’s status wouldn’t erratically fix itself and finally become “read” after several minutes and multiple manual attempts to mark it as such. This inconsistency points to a bug, not a feature.
After I pointed out these logical flaws, the support case has reached its conclusion.
The agent confirmed they have escalated the issue internally three times but have reached the limit of what they can do. They are now closing the ticket
On a personal note, I want to add that I understand these processes can be lengthy. However, it has been incredibly disheartening to invest so much effort just to report an issue like this. I have been a Product Expert (PE) for YouTube and other Google products for over 12 years. I am familiar with how slow these processes can be, but it is deeply frustrating to have to be this persistent simply to get a bug that so clearly breaks the tool’s functionality acknowledged.
