Does adding someone to a Google Group give them access to files already shared with the group?

Yes. Google documents that a member added later can immediately open previously shared content through the file URL, and loses that permission when you remove them from the group. The catch is that the content does not appear in their Shared with me view in Drive unless the files are reshared with the group or shared with the person individually, so "I cannot find it" is usually not an access problem. Team content belongs in a shared drive, where it appears because the person is a member.

What is the difference between an access group and a configuration group in Google Workspace?

An access group turns a service on for people whose organizational unit has it off. It can only add access, never remove it, and the group setting overrides the unit. A configuration group changes settings rather than access, and a user gets the setting of the highest priority group they belong to, with no merging across their groups. Two-step verification is the exception: a 2SV policy set on a child organizational unit takes precedence over a configuration group setting.

How many people can reach a shared drive through groups?

One shared drive accepts up to 100 groups and up to 600 members counting groups and individual people together. Added one by one you stop at 600 people, while through groups the same drive reaches up to 50,000. Joining a group also adds the person to every shared drive that group is a member of, and leaving it removes that access, which is the whole reason to grant access by group.

Google Groups permissions: what a group grants, and when

Say a twelve-person architecture studio. The drawings for every project live in Drive, and access grew the way access usually grows: somebody shared a project folder with four people, then with two more, then with an outside engineer for one week in March. Two years later nobody can answer a plain question. Who can open the Riverside folder? The only honest way to find out is to open every folder's sharing dialog and read it.

A group fixes that, which is why groups get designed before we touch a single folder on a client project. One place answers who is on this, and every door that trusts the group answers the same way. What catches people is that a group does four different jobs in Google Workspace, the rules are not the same for each, and two of them behave differently from what the sharing dialog leads you to expect.

The four jobs one group can do

Same object, four uses. Worth naming, because the limits differ.

An address. Mail sent to the group reaches its members. That is the shared inbox case, and the four ways to build one are a separate decision.
Access to content. Share a folder, a shared drive or a calendar with the group instead of with people. This is the job that pays for itself.
An access group. A service is off for an organizational unit and you need it on for five people inside that unit. Access groups do exactly that and only that: they can add access to a service, never take it away, and the group setting overrides the organizational unit. Membership is not tied to your structure, so people from different units can sit in the same access group.
A configuration group. Not access, settings, for people spread across units. A user gets the setting of the highest priority group they belong to, and settings are not added across a user's groups, so two groups with different answers do not meet in the middle. One of them wins.

Two traps live in that list. A group created in Google Groups by a user, rather than in the Admin console, may not be selectable as an access group at all, which is usually the answer when the group you want does not appear in the list. And two-step verification does not follow the configuration group rule: a 2SV policy set on a child organizational unit takes precedence over a configuration group setting, so if you are managing enrolment, check the unit too.

A group doing two jobs at once is where confusion starts: a mailing list that has also become a permission boundary hands the folders to every new subscriber, and whoever adds them is thinking about mail.

What we check first in a client's Drive

Before designing anything, we count the direct shares. Google's description of group sharing is exact and it is the whole argument for doing this: add a member to a group and that person gains permission to access the files and folders the group has, remove them and they lose it. A file shared with someone personally has no such lever. It is a line item that has to be found by hand, usually on the day they leave.

So the first pass is an inventory of folders shared with named individuals outside a group. That list is the real access map, and it runs longer than anyone expects.

The support ticket this always generates

You add the new designer to the project group and she writes back that she cannot find anything. Nothing is broken. Google's documentation is precise here: members you add to a group later can immediately open previously shared content through the file URL, but that content does not appear in their Shared with me view in Drive. For it to show up there you would have to reshare the files with the group, or share them with the new member individually, which is the thing you were trying to stop doing.

The fix is structural rather than clever. Content a team works on belongs in a shared drive, where it appears because the person is a member, not because a share event happened to them. For loose folders in someone's My Drive, the answer is a link in the project thread, not a second share.

Shared drives change the arithmetic

One shared drive accepts up to 100 groups, and up to 600 members counting groups and individual people together. Add people one by one and 600 is your ceiling. Add them through groups and the same drive reaches up to 50,000. A twelve-person studio never sees those numbers, and the mechanism still matters: when a user joins a group, they are added to every shared drive that group is a member of, with nobody opening Drive. Departures run the same way in reverse. Google's own line for a team member leaving is to remove that person from the group, after which they cannot reach previously shared group content.

One detail to settle while you plan it: Content manager is the default level for a new shared drive member and it can delete files, so choose the level per group rather than accepting it.

The naming convention we leave behind on client projects, so the job a group does is readable from its address:

team-studio@example.com      everyone who works here
proj-riverside@example.com   one project, one lifetime
ext-riverside@example.com    outside people on that project
cfg-drive-sync@example.com   a settings override, not a mailbox

Calendar plays by different rules

Sharing a calendar with a group works, and the behaviour around it is not the behaviour of Drive. Two documented points are worth knowing before you promise a client that the team calendar is handled.

New members are told about the calendars shared with the group by email, typically within an hour of joining. That notification is not sent at all if the group has more than 100 calendars shared to it, which is rare in a small company and looks exactly like broken access.

The second point is stranger and more useful. Whether an event created for the group lands on members' calendars automatically depends on the group's Who can view members permission. With it, the event appears. Without it, members have to add the event themselves. A permission that reads like a privacy setting is also controlling whether your team sees the meeting, so when a client reports that half the team missed a recurring site visit, that setting is the second thing we open.

Who is allowed into the group

A group is only a dependable boundary if you control who can join it. Three layers decide that, and they stack from the organization down.

The organization default. Group owners cannot allow members from outside your organization unless an admin turns that on; the option is off by default. It does not stop an admin from allowing external members on a specific group in the Admin console or through the Groups Settings API.
The group itself. Per group, you choose whether admins, users, or both can add external members.
Member restrictions. On a single group you can restrict membership by member type, meaning a user, a group or a service account, or by customer ID. The clause that matters in practice: a restriction stops anyone adding a non-compliant member from that point on, and it does not remove the non-compliant members already in the group. Setting it is not an audit.

Switching a group that has outside people in it to internal members only is the one irreversible move in this area. Google's documented behaviour, from the membership classification change it announced on 23 February 2026 and rolled out from June 2026, is that setting Allow external members to no permanently removes the external members from the group, while indirect members stay in their child groups and are filtered out of the parent. Checked 9 October 2026. Read the member list before you flip it; there is no undo.

If the group carries access to anything sensitive, the other setting to know is the Security label. Adding it makes the group a security group, which is what lets it be used for access control, and that change is permanent: it adds security features without removing anything the group already did, and it cannot be taken back off. It also constrains nesting, since only a security group from the same organization can be a member of a security group. We apply it to the small set of groups that gate client data and leave ordinary mailing lists alone.

The mail side of a group you set up for access

Every group has an address, including the ones you created purely as a permission boundary. If that address can receive mail from outside, the group re-sends each message to its members, and re-sending is forwarding. The hop breaks SPF, because the message now arrives from Google rather than from the sender's authorized hosts, while a DKIM signature survives as long as nothing rewrites the message. That is why a group address sometimes looks like a deliverability problem when the underlying setup is fine, and why the forwarding rules are worth a read before anyone changes DNS over it.

A message that went to spam through a group: the headers settle it in a minute.

What we leave behind

One group per decision, named for the decision rather than the team's current shape, so a reorganisation does not invalidate every share.
Outside people in their own groups, never mixed into an internal one, which keeps the external members setting from becoming a dilemma later.
Access granted at the shared drive and the group, with individual shares treated as exceptions that someone has to justify.
A quarterly read of folders shared with named people. It is fifteen minutes and it is the only way the direct shares do not creep back.
The departure test. Removing one person from one group should remove their access to everything that job involved. If it does not, the structure is not finished, and that is exactly what the offboarding checklist depends on.

How Guanacos Tech helps

We design the group and organizational unit structure once for small and mid-sized teams across North America and Latin America, move team content into shared drives the groups already reach, apply the Security label where client data is involved, and hand over the naming convention so later additions need no decision. Then the direct shares get cleaned up, which is the slow part and the one that makes departures safe. How we work fits on one page. If you would rather have this designed than researched, we are Google Workspace consultants, and half an hour is enough to map your groups against what they are actually protecting.

Use a group, not twelve email addresses: what Google Groups permissions really control