Delegation of Contacts - Groups within Contacts - The New Interface (9 dots)
Post date: Aug 29, 2018 11:2:23 PM
In general, Google Apps, and most everything Google is pretty cool.
.............But I'm going to be scratching my head on what happened here on this one for a while...
In the enterprise, you are used to a certain configuration for your email, contacts and contact groups. You have your contacts, and within contacts you have groups. Those groups may be board members, committees, internal and external employees, or what-have-you. You open an email, and you send a message to firstname.lastname@example.org and all your board members that are in that group receive the email. Clean and easy - Everything managed from one contact manager interface.
In an enterprise setup, you also have assistants that help manage contacts and groups on behalf of their managers.
These are Delegates to the owner of the account, be that the CEO, Director, or Manager.
Within Google Apps, it used to be, that you would assign a delegate (assistant) within settings on behalf of a master account (ie manager/owner/CEO), and the delegate would manage the contacts and members of the groups within, from their own account under it's own contact interface.
It Was really straight forward once delegation was configured.
But it's all changed with the new Google Apps Mail interface.
The contacts were moved from:
Within the new contacts(Preview), you were, up until not long ago(the last couple of months?), very limited to what you were able to do (import, export, delegate, merge, were all functions you had to drop out of preview to do); so you would be forced to go back to the old interface in order to get full functionality. Note: as I update this post, I'm noticing a lot of changes. So this post is changing along with it....
When you reverted back to the classic "old version" of the interface these functions like import / export would work. So you would tend to stay in the Classic interface... Under the Classic Contact interface, you will even now still see your Groups listed that were pulled from the old Contacts during the change over. However, the Groups listed here are only email addresses associated with the Group names from your contact group objects that were created in Contacts. You can't add/edit/delete contacts to these group names from within a contact email address now, as they are simply an email address now. You might as well go through and purge them. They are pretty much useless the way things have changed.
While playing with this, since the migration/changes.... I figured out a few things.
Your contact groups from the migration are not totally gone per se. They have been split, in to an email address within contacts, and a group migrated to a new location of the same name.
Groups are now also within the 9 dots, but under the Groups icon within (they are now "email list groups". Contact Groups are now like the very old "Listserv" System Groups from yesteryear and treated much the same way, with members, permissions, posts, notifications of membership and opt-out options.
The new contact group, now, not only has members of it, like it did before, under contacts, but now requires many new permissions to be set up, including changes to the way your delegate has to be defined. See the "Roles" area. See snip below with permissions/changes.
Note to Google Dev's:
Contact Groups were a very simple set up, you had contacts, and groups within contacts. You had a delegate that could make changes for you.
Now you have a mess of details to hash through; email list membership, permissions(what is and isn't allowed), and managers/owners that have to be defined, along with various restrictions that just aren't necessary in this particular type of group.
I can understand using "Groups" as you have for "listserv-like" functionality, where you have posts and topics, and the like. But a listserv is completely different to an enterprise setup of members of a contact group that can be managed by an assistant.
This new way of doing groups is truly broken. Someone at Google needs to revisit the way contacts are configured, managed, and delegated.
Another downside to this new way of handling members of the group, is that your delegate needs to be added and be part of the group in order to be able to have them assigned/listed as a 'manager' of it.
It muddies the make up and membership in the various groups, and makes it more than a bit strange.
Imagine if you will, your board of directors as the members of the "Board@domain.com" group; and your assistant listed in there too as a "member" of the group - just so you can identify him/her as the the manager/delegate in a different section.
... I'm really baffled by whomever thought all of this was a good idea.
Anyway, this post is just so others can figure this out, and make sense of what and where everything went...
------------- - -----------------------
***Old Contact Interface*** After the migration to the Nine dots; under the Classic Contacts interface, you will still see the option to create a new group (see below), and you can still add members to the group, much the same way you used to, and it will create the group under contacts under a heading, that indicates 'groups' by indenting them under your 'My Contacts'. You can click the group and see it's members.
These groups are not the same as they were, when you direct an email to them, they auto-populate the members of the group and the group name just goes away. The email address just vanishes. It's more like an alias now, than a group name with a specific email address associated with it...
Further; These new group names created here will not automatically migrate into the "Groups" icon under the 9 dots. You will not be able to manage the members and permissions. It is now completely separate, and just makes all the changes seem a bit more confusing.
After playing with this, and learning that the new Preview interface has been updated to include Import/Export/Merge of contacts, I really see no reason to still be using the "classic" interface. It's now just a broken shell of it's former function.
-- - -------------------------------
So, now, dropping the old, and only working with the new... Stuff changes, you just get over it, and move on... right?
The biggest problem that I can see with this "new" Group method, is that it's changed the Contact Group object into a Listserv style Group Object; now making a host of options/permissions necessary to configure a group.
Also; when you invite members to the group, either as "Invite members" or as "Direct add members", an email goes out to each member of your group. There is no way around it. So, while you are organizing your next board leadership group, and each committee group for the new year, you will be sending out emails to each member letting them know they are being added to a group name, possibly emailing the same individuals multiple times while you work through your list of committees, and other member groups. Do you really want your board members to be flooded with emails showing your work flow as you add them to the various lists you use in your org?
Check out what the simple contact group object has become:
The above is just insane and wholly not necessary.
Contact groups should be very simple: (like this:)
Master Account Name: CEO@domain.com (example)
Contact Group Name: Board Members 2018
Members: Board Member Email 1, Board Member Email 2, Board Member Email 3
Delegate: Assistant email address (assigned and given "full access to edit"-Nothing more).
Assistant on their Computer:
Assistant on their account, and in their Email Interface, Opens Contacts, selects delegated CEO Contacts/Groups as the manager of those contacts.
Selects Group Name (Board Members 2018), then manages the contact members under that group, makes a change. Pushes SAVE. Then, it's Done.
(There is no division of a contacts icon and groups icon, no special permissions, it's plain and simple.)
As indicated above; I think Google needs to revisit this. A Contact Group is very much different than a Listserv Group.
They both need to be managed, they both need to have a delegate option, but they both don't need to be managed or handled the same way.
Lumping the types of groups together like this is needlessly complicated and pointless.