Although it is welcomed to have a new user interface for users to follow when administrators allow Google Groups to be accessed in the forum view, most schools are not leveraging the groups.google.com interface and are only utilizing Google Groups for the distribution group aspect. This means that groups are used for delivering mail, sharing files, or Shared Drives with dynamic groups of users. With this in mind, some of the main settings were made easier to configure with the Admin console redesign in 2019, but several settings remain buried in the Group management page or only available via an API. Not only that but some of the most common use-case scenarios also are not addressed at all in the Group settings, leaving administrators to come up with workarounds to accomplish the desired results. We’re going to look at some of those situations, what is commonly done, and alternate solutions.
Allowing only non-group members to post to a Group
The top challenge with the current group settings is limiting who can post to a Group. Google has provided roles of Owner and Manager along with the standard Member to differentiate users associated with the Google Group. For a traditional forum situation, this is an adequate solution since all interactions are taking place from within the website. However, from a distribution list perspective, this can cause complications. A group may be designed to be for student communication from staff. With the current limitations of group posting permissions, a choice has to be made whether to include staff members in the group or to permit students to post to the group.
The traditional solution is to add staff to the group as managers and set their mail delivery setting to None. This prevents any mail sent to the group to not be delivered to staff members. There are a handful of issues with this method. It requires manually updating every staff member for every group that this is desired to be the behavior. It cannot be controlled by using another group’s membership or having it set dynamically. Recently, Google blocked the ability of a Google Group to be a manager or owner of another group.
Similarly, groups for human resources, IT departments, principals, board of trustees, all meet a similar challenge – stopping unauthorized individuals from posting to the group. The traditional method for these special groups falls short in its flexibility, and we have to look at some alternative solutions.
Another issue with this solution is that staff are still a part of the group. All items that are shared with the group, all Shared Drives, all Calendar invites, also get shared with the staff members. Groups are not only used for mail distribution anymore.
Posting to a nested group
One improvement that we have found is that posting to nested groups is now behaving better. Previously, if a nested group blocked posting to the group from members, managers, or owners, and the individual sent to the parent group did not have access to post to sub-groups, the message would bounce. This situation seems to have been resolved, and messages are now delivered to any sub group’s members.
This issue would typically go unnoticed until an important message is missed by a large portion of the staff. Even when the problematic behavior is noticed, there is typically a fair amount of investigation that takes place before tracking down the problem.
Alternate solution to group settings
When thinking about the ability to post to a group, there is more than one criteria that is being met before a message is getting distributed to the group. The obvious one is what we’ve been looking at up to this point – the individual group’s setting. However, another criteria which is by default being met is the mail compliance rules. Administrators have far greater control over compliance rules within the Gmail settings of the Admin console, and these rules can be used to affect whether or not an email from an individual is delivered to the Group or its members.
Mail compliance and routing rules can be configured on an organizational unit basis, or can even be filtered to use Google Group membership as a filter. As an example, an administrator wants to block users within a given organizational unit from posting to any Group. A footer or naming convention cannot reliably identify a message originating from users within that OU. You'd create a routing rule to add a custom email header can be added to the OU and later looked for to block a message to groups. You'd commonly set this up to block students from posting to any Google Group within the organization.
Similar logic can be used to prevent non-approved staff from posting to the all staff group or to permit members of a Group the ability to post to all groups. If the group settings are configured to allow anyone in the domain to post, relying wholly on Gmail settings to control group posting.
Additional tools for managing group settings
Regardless of whether Group settings or Gmail settings are being utilized to manage who can post to Google Groups, knowing what each group’s setting is set to is vital to understanding who can post to a group, and this is not very visible within the Admin console without drilling into each group individually. With this in mind, CDW Amplified for Education developed Gopher for Groups to provide a place where group settings can be viewed and updated within a single location. The Addon interface is similar to other Gopher Pack tools like Gopher for Chrome and lets you manage each group’s settings. There is also a reference sheet that is added to help administrators understand what each setting does and how it impacts the Google Groups behavior.
Understanding what can be done with Google Groups helps you outline a plan for managing Google Groups. Whether the desired outcome is to limit posting to sensitive groups to just a handful of users, or blocking students from posting to any google group, or even use a Google Group as an access control group to limit who can email users, we have a team ready to support your needs. Connect with the account manager for your state to set up some time to work with our technical support team.
About the Author
|Stephen Gale, Technical Support Analyst|
|Stephen lives in Utah and enjoys the puzzle of investigating users’ problems and finding potential solutions. A recovering/reformed Gamer, Stephen throws himself into his passion for staying on top of all things Chrome OS and Chromebook related. Prior to joining CDW Amplified for Education, Stephen served as a Network Admin in a Therapeutic Boarding School and an IT director, where he implemented Google Workspace for Education. Stephen has studied computer science and security at Weber State University, Western Governors University. A self-anointed honor, Stephen likes Chromebooks more than almost anyone else in the world.|