Ready to create your own group? Start here!
In summer of 2016, Carleton transitioned from our old email client Zimbra to Gmail. This article references the transition from Zimbra to Gmail and how some Zimbra features can be reproduced in Gmail using Google Groups.
This article provides a summary of Google Groups along with guidelines of how these groups are intended to be created, used, and retained at Carleton. While there is no exact mapping for every way a Zimbra resource account has been used to that of one in Google Apps for Education, Google Groups is the preferred application to fill these gaps in a variety of ways while offering increased functionality for the workflow aspects of these functions.
Google Groups - Roles
Google Groups have Owners, Managers, and Members by default. These roles distinguish permissions an individual may have within a specific group, and cannot be deleted.
The Owner role has the highest level of permissions and contains only the creator of the group when the group is created. Other characteristics of this role are:
- Owners have the most permissions of any member.
- Owners can add other roles and even delete the group itself.
- Permissions for the Owner role can’t be modified.
- Owners don’t have all of the permissions. If an owner needs more permissions, add the owner to an additional role with the needed permissions.
- You can add additional owners or remove owners from the Owner role.
- This role cannot be removed.
The Manager role contains all elected managers of the Google group. Managers generally have more permissions than members, but fewer permissions than owners. Other characteristics of this role are:
- Managers primarily have member and message management responsibilities.
- Managers can add or remove managers.
- This role cannot be removed.
All members of a group belong to the Member role by default. Other characteristics of this role are:
- Any permission set on the Member role is automatically set on all other roles.
- Permissions set in the Member role are selected and grayed out in the other roles.
- This role cannot be removed.
Populating Google Groups membership at Carleton
- Affiliation Groups (ITS Owned, ITS designated Manager, and ITS Populated) - Affiliation groups are created and owned by an ITS Google Administrator, Management is appointed by a designated individual on behalf of the affiliation group, Membership is controlled automatically based on the process of hire, termination, enrollment, and graduation, as designated in Colleague.
- Committees, Official Student Organizations (ITS Owned, Leadership (of the Committee or Org) Managed, Manually Populated) - Committees and Official Student Organizations are created and owned by an ITS Google Administrator, Management is committee or student organization chair, or appointed ex-officio committee member, or departmental coordinator/convener who serves as an active committee member. Management shall not source outside of the department responsible for coordination of any given committee. Membership is maintained manually by the group owner and manager(s) through the Google Apps interface. Committee 'Owners/Managers' and group membership can be maintained through Advance, the Carleton alumni database that is supported by Development Information Systems (DVIS). In order to populate these groups some programming to feed data from the source (Advance) into Google Groups needs to take place.
- Ad-Hoc Groups (User Owned, User Managed, User Populated) - Training recommended - This will be the preferred method of Google Group creation as it requires less intervention at a systems level. Training has been made available here: https://wiki.carleton.edu/x/WQgsAg Ad-Hoc Groups can be created by a Carleton faculty, staff, or student with the intention of using Google Groups to work on projects, convene unofficial student organizations, or another group where use of an Affiliation, Committee, or Official Student Organization group are not already used. At the time of group creation, it is recommended that the group owner set a reminder to revisit the group's purpose one year from the date of creation.
Google Groups Stipulations
- Use of Google Groups at Carleton falls under the Community Standards Policy.
- A Google Group's email address must closely match the Group Name and be appropriate to the Description.
- When an Ad-Hoc Google Group is created, the default naming convention will append ".group" to the group name in the email address. For example, a group titled "friendsoftoff" would be created as "email@example.com." Non-complying group names may be modified.
- Affiliation, Committee, and Official Student Organization Google Groups must have an associated Carleton user account as a Manager.
- Group Managers are responsible for maintaining accurate membership and permissions of their Google Group. It is recommended that Google Groups Managers conduct annual checkups for their groups.
- ITS may remove Ad-Hoc groups in which there is no longer a designated Owner or Manager who has an active Carleton Google Apps for Education account.
- The default for newly-created Google Groups at Carleton is that they are hidden from search and the "Browse All" list of Google Groups at Carleton. If the creator of a group wants it to be generally visible to Carleton users, the checkbox labeled "List this group in the directory" in Settings>Information>Directory must be ticked.
- When creating an Ad-Hoc group, it is vital that the creator of the Group review and adjust the 'Basic Permissions' in the creation dialogue as needed. Especially be aware that the default settings for posting and viewing posts includes "All organization members," which means every user at Carleton can both post to and read anything posted to that Group's web page - whether they are a member or not.
Use cases for Google Groups
Google Groups allow you to create online and email-based groups to:
- Engage in discussions about a specific subject.
- Create a question and answer customer support group for a product, such as a service your department provides at Carleton.
- Organize meetings, conferences, or social events among members of a group.
- Find people with similar hobbies, interests, or backgrounds.
- Read group posts through email, the online interface, or both.
Zimbra to Gmail migration
There are a number of use-cases for Google Groups at Carleton. The shift in tool-set from Zimbra to Gmail and the suite of Google Apps for Education requires detailed thought around how processes took place previously in Zimbra, and what the requirements are for carrying out those processes in Gmail. Some departments have historically used Zimbra 'resource' and 'location' accounts for a number of purposes. The table below lists a few suggested purposes of using Google Groups at Carleton that may fall in line with how 'resource' or 'location' accounts were used in Zimbra.
|Shared email InBox||A collaborative email inbox allowing the ability to distribute and track responsibility for topics among|
|Group email alias||An alternate email addresses for your group. For example, if your department has the group firstname.lastname@example.org, an ITS Google Administrator can add email@example.com as an alias for the group to make sure questions from clients reach the right person.|
|Using a group as a mailing list||A group with an email address that, when sent to, will distribute the message to members of the group|
|Web log of correspondence with up/down voting and "best answer" denoted||Web interface to emails and notifications posted to the group. Emails and notifications can be up/down voted based on how helpful the posting was, and when a question is answered, individuals may mark a "Best Answer."|
Limitations of Google Groups
There are limitations specifically related to:
- Message limits
- Group invitations and size
Google is a cloud-sourced provider of this service, so please refer to Groups policies and limits for details regarding these potentially changing limitations. These limitations are important to consider prior to selecting Google Groups as your designated tool.