topic Re: Email Groups - Would love someone to hold my hand... in Peer-Peer Topics

Email Groups - Would love someone to hold my hand...

Justin_W — Tue, 14 May 2024 18:21:58 GMT

I'm not sure why, but every time I've dabbled in the world of Google Groups/Email groups/Groups for Workspace etc etc, I've always felt like Google made it waay more complicated than it need be. And as such, I'm never fully convinced I've got it setup properly.

I've tried multiple times, followed a few guides, and still am not confident in it.

Would anyone be willing to hold my hand through this?

Here's our basic setup and wants:

Mostly, I just want what any other platform may call a "distribution list". A group of people from our directory.

Now, we've got a bunch of groups already. We've got a bunch of OUs - as we use AD on prem and GCDS/GAPS to get setup in our Google Workspace.

Our goal would be to get it dialed in so that specified people/groups can utilize these distribution groups as part of normal business/school interactions. So there would be some limits/restrictions.

Students shouldn't be able to send to the groups
No external emails can be sent to groups (without first making an exception)
Not all groups need be listed in directory (or restricted - again, students don't need to see them)
Must account for nested groups
No users in groups (receiving emails) they don't otherwise belong to.
Not looking to have to manually add/remove normal users from multiple groups anytime we have turnover - hence the nested groups. As it *should* be now, we just manually add the user to a single group and that group already exist within the "allstaff" group.

In an effort to maintain efficiency, we use nested groups.

So, here's an example scenario of how I'd like it to work:

Our head of school wants to get an email to all staff. So, he should be able to simply send an email to the "allstaff@ourdomain.com" address (which is already created as a "group") and All staff would get it. The "allstaff" group consist almost exclusively of other groups - facilitates, accounting, teachers, etc. Not individuals. Those groups each contain the people from their appropriate department. Everyone gets the email - it doesn't go to anyone's "spam" or "social" tabs or whatever. Because the Head of School has permissions to send to the Allstaff group, the email go through properly. Everyone is happy.

If an Jan from the kitchen tries to send an email to allstaff - it gets bounced -she doesn't have permission to send to the allstaff group. If a student tries - same thing (but hopefully they don't even see the group in the directory in the first place)

Part of the issue I'm having is understanding the nested groups part - as it relates to permissions.

If HOS has full permissions to send to the ALLSTAFF group - but that group consists of other groups - does that mean I'd also have to go to each of those groups and add him there too? And at what level?

Sorry if I'm not explaining it well.

It just seems so clunky. I don't want those users in each group because they don't *need* to be in that group for any other reason - and the certainly don't need the emails that are specifically targeted to those groups.

I;ve also got a user that says she gets duplicates of "allstaff" emails every time - presumably because she's in 2 groups? Is that right? Does it not account for that? She's rightfully in 2 groups (for example - "Library" and "Instructional") and since those are both in the "allstaff" group she gets the email twice?

It makes my head spin. And it baffles me how a thing that been around for so long (email groups) is implemented in a such (seemingly) convoluted manner.

Tell me I'm missing something and it's actually really way to do what I want. Please.

Thanks!

Re: Email Groups - Would love someone to hold my hand...

icrew — Tue, 14 May 2024 18:33:43 GMT

FWIW, I wrote up a thing that at least attempts to explain how Groups within Groups work a few years ago, and how to work within Google system. It's at https://docs.google.com/document/d/1DfTbCOml3mv2CM4NoaKUyBr3tx8P8tHxPv6nhssYxYU/

It was originally written internally for folks here at UC Berkeley, and it's a little outdated these days, but the concepts still hold. One translation from Berkeley-speak that is important to understanding the document: "CalGroups" is Berkeley's implementation of the InCommon Grouper group management system. My guess is that AD might be able to do similar things, but I'm very much not familiar with AD....

Hope that helps, at least a little,

Ian

Re: Email Groups - Would love someone to hold my hand...

Justin_W — Tue, 14 May 2024 18:50:04 GMT

Thanks!

So...the takeaway is that it really is as clunky as it seems?

Not using subgroups sounds like a step backwards and makes a more manual work and housekeeping.

Setting to "all organization" or "public" is bad because it allows outside and/or students to use the groups. Or it means more manual work of moderation. Both are undesirable.

So perhaps option 3 from your doc is worth a look. But creating an "allowed senders" group would really mean creating multiple of these groups ,correct? Since different groups have different permissions, I'd have to create an "allowed senders" group for each one (or at least for each one that has unique senders).

The doc seems to be targeted towards end-users whish to make lists. How are you handling it at a higher /larger scale?

It baffles me that this is Google's solutions to this. I'm a bit curious how everyone else has made peace with this.

Are ya'll just manually adding and removing users from all the appropriate groups every time there's turnover? Doesn't that seem very... 2000's?

And that's without the noise of "posts" and "owners" etc. verbiage

Re: Email Groups - Would love someone to hold my hand...

icrew — Tue, 14 May 2024 20:10:33 GMT

Yeah, pretty much. Google has severely under-invested in Groups for a decade or more at this point. They're probably not going to kill it, but it's also clear that they really don't care about it at all....

Perhaps a better way to handle it is to do all the group management in Active Directory, and sync over from there, as described at https://support.google.com/a/answer/167105, essentially the same as "option 2" in my document?

Re: Email Groups - Would love someone to hold my hand...

Justin_W — Tue, 14 May 2024 20:30:01 GMT

Man, that's crazy.

I wasn't looking to solely use AD for groups as that'd mean creating a whole lot of extra glut in my AD that simply doesn't need to exist there because it's Google-Only (and vice-versa).

Also, it's still not clear to me how it actually handles permissions in that way.

I do already have a lot of groups in AD (from prior to our Google Workspace days and for GPO purposes/local file shares mostly)

How does it overcome the issue you present in your "Standard behaviour" illustration?

If it ignores access/permission from AD (because they aren't the same as whatever Google is trying to do) then I assume it leaves them set to some "default" setting. I assume we'd have to go change the permissions for each group to actually get them how we need them? The sync doesn't reset that? So really AD would just be setting membership, then I'd have to go to Workspace to set permissions?

I think we started with using AD for groups, but moved away from it years ago because there was some other compelling reason to use Google Groups for that instead.

In a future that may not even include AD for us, how is this not better for folks that are just 100% Google Workspace?

It's a basic, core functionality that's been around for decades with any platform that has existed in this market.

Our Groupwise used to handle it in a way that seemed lightyears ahead of this...

Re: Email Groups - Would love someone to hold my hand...

YERKO — Thu, 16 May 2024 12:03:28 GMT

Solo a modo de consulta, estimado @Justin_W entiendo la importancia de hacer grupos para envío masivo de información, entiendo que estudiantes no utilicen sus cuentas para escribir o suscribirse fuera del ambiente educativo, pero siguiendo tu ejemplo, porque el Sheff o encargado de biblioteca no podría escribir a otros o enviar correos masivos? es politica de la unidad educativa? cual es el objetivo? o que esperan evitar en ese contexto?

por ejemplo en mi unidad educativa, si cualquier usuario (docente o adulto) desea escribir a todoelpersonal@colegio.com lo puede hacer, y si la encargada de biblioteca recibe correo de una apoderada preguntando por un libro, puede responder sin limitación alguna. Lo que si informamos a toda la comunidad educativa (adulta) fueron los parametros como pie de correo, tipo de lenguaje, importancia y tiempo de respuesta, forma e incluso tipografía y colores de las mismas. Y desde luego el que se desvía o comete error se le informa del error, se corrije y se sigue adelante. De lo contrario no le veo sentido a que todos tengan sus correos pero no pueden comunicarse entre ellos.

éxito en resolver tu problema

Re: Email Groups - Would love someone to hold my hand...

Kim_Nilsson — Tue, 21 May 2024 11:14:36 GMT

Just commenting on a single thing.

Users should not receive duplicates of the same email, regardless of how many groups you are in.

Each email has a unique Message-ID created when the person sent it, and you should only receive one.

I just tested and verified this, with a user who is member of two subgroups. One email received.

However, if people are added with aliases to certain groups, I'm not sure that is taken into account, and a duplicate may be produced. Gmail's magic should take care of it. Just like it does for the user sending the email, not also receiving one, because their copy is in their Sent.

Re: Email Groups - Would love someone to hold my hand...

Kim_Nilsson — Tue, 21 May 2024 11:17:54 GMT

On other topics...

I have all our largest groups set to where anyone, even external, can send to them, in Groups settings, but where I have Compliance and/or Routing rules blocking everyone from sending to them, unless they are member of my Exclusion List in admin (not a regular group, but a list in admin).

So only those I want, can actually send to them, regardless if they can see the group or not.

Now, what you can't do... is restrict sharing to such a restricted list, so perhaps try to minimise visibility a little bit.