📗 Google Drive Enterprise Manual

manual

#1

Content

1. Team Drives

2. Access control

3. Access your Team Drives

4. Security policies

5. Advanced topics


1. Team Drives

We are now using Google Drive Enterprise. This allows us better overview of access levels and a stronger degree of isolation between projects when that is desired. Unlike files in My Drive, files in a Team Drive belong to the team instead of an individual. Even if members leave, the files stay exactly where they are so your team can continue to share information and get work done. Work in Edgeryders is heavily project oriented, so this approach fits our way of working.

2. Access control

A team drive can have one or many managers that set the technical policy restrictions of the drive. For example, a Team Drive manager can restrict users from sharing documents in the drive with users who are not added to the drive, or restrict it so that documents can be shared, but only with other users with edgeryders.eu Drive accounts. A manager can also allow or prevent commenters and viewers from downloading, copying, and printing files in the Team Drive.

Read more about the difference between different access levels and sharing restrictions in the official Google Team Drive documentation.

3. Access your Team Drives

  1. Get an account on the Edgeryders Drive. Any director can make you an account, and @hugi can give support.

  2. If you already have another Google account, you can seamlessly switch between accounts by pressing your profile picture in the top right corner. Click “Add account” to add your Edgeryders Drive account to the menu.

  3. Go to drive.google.com and switch to the Edgeryders account.

  4. See the Team Drives you have been added to in the drop-down right under “My Drive”.

4. Security policies

Security policies and settings are different for different Edgeryders Team Drives. Every Team Drive should have a document named “§ Team Drive Policies” in the root folder of the drive. Read that to understand the purpose of each drive and what the security settings of it are.

5. Advanced topics

5.1. Making files accessible to the public

In their infinite wisdom, Google decided that files in Google Drive Enterprise and GSuite cannot be shared to everyone. For one, sharing settings are only available for files, not for files and directories as in normal Google Drive. And then, link sharing for files is available but here only means “share with everyone in the organization”, not “with everyone” as in normal Google Drive.

Options to solve this:

  1. Share with individual accounts. You can share individual files with up to 200 specific Google accounts inside and outside the organization. Everyone without access will see a screen where they can request access, and then you get an e-mail about it and can grant access. Since this is a hassle for both sides, this solution is only applicable if you know all or most of the people who will ever need access and can grant that upfront, or if only very few people will need access at all (and thus have to go through the “request access” process).

  2. Publish the document content in a view-only, web-optimized version. Instructions for that are here. Note that this will only publish the basically as a HTML export – it does not allow the viewer to do anything besides viewing it. So downloading it as PDF or in OpenOffice format, or adding it to ones own Google Drive “My Drive”, or making a copy and adding that to “My Drive” are not possible. If you want to allow any of these, choose the second option below.

  3. Create a public folder in “My Drive”. The folder will not be inside a team drive, but at least accessible under “My Drive” with Google Drive Enterprise accounts. Instructions:

    1. Create a folder using a “normal” Google Drive account. It will not work when using one of the Google Drive Enterprise “organization” accounts.
    2. Set the folder to “Everyone can: view”. Or “view and comment”, or “edit”, as you like.
    3. Share the folder with Google Drive Enterprise accounts. Include sending a note that explains they should add the folder to their “My Drive” to have it accessible comfortably. They will not be able to add it to any team drive.

We have used the third option from above to create a folder “Edgeryders Public”, containing some templates and other publications that we want to link to in file form from our platform. Anyone, but esp. Edgeryders OÜ directors using their …@edgeryders.eu Google Drive Enterprise accounts, can add it to their “My Drive” section.


#2

Thank you @hugi and @matthias, this is great!

How do I access my account?


#3

I think you should have gotten an email with login instructions?


#4

Sorry, sorry, I am an idiot.


#5

I am going to use this thread for general questions about organizing stuff in Team Drives. Here is the first one.

In the old Edgeryders Admin Drive folder, the top-level nodes of our hierarchy represented the state of a project in its lifecycle Projects: potential, current, finished, recyclable. But now, at the top of the hierarchy are teams; this is nice, as it meshes well with the team concept in Edgeryders. For now, some of the teams are permanent (Directors for legal/admin; Research Network) and some are transient, but fairly large by Edgeryders standard (POPREBEL, NGI Forward). I guess a natural step is for the Culture Squad to have its own team drive.

Question: what happens to a project that has both a lifecycle state and a team, for example a potential research project? I propose its root is still the team, so it would live in the Research Network drive. Should we reproduce the lifecycle distinction within each drive?

What I’m looking for here is a situation where people would, when adventuring into an unfamiliar team drive, find a more or less familiar layout. It’s no big deal if you guys want to be anarchic on this, but I kind of like the potential, current and recyclable (“finished” would probably be moved into the archive), and am up for maintaining it within the RezNet team drive. If you guys do the same, then we are left with drives with similar structure. We might also need a “residual” drive for projects that do not belong to any team.


#6

Since your drive policy is to allow sharing outside of the team and edgeryers.eu, I think it’s a good way to go to have potential research projects live in the research network drive.

I think that a useful way of thinking about it is how we think about categories on the platform:

  • Potential projects or even many small projects live inside parent categories, and inside parent team drives.
  • When a project becomes big, complex or starts involving a lot of people over time, it might get its own category and its own team drive.
  • When a project comes to an end, its category is archived and the content of its team drive is moved to the Finished projects folder in the team drive it was born in.

Since I think only directors should have access to the “main” archive, finished team projects should live in archives in team drives to stay accessible to team members.


#7

About folder structure: I said it before that I don’t like the “teams” concept, it places data (and even people) into arbitrary concepts where they don’t belong. For example when Anique structured data in both Dynalist and Google Drive below a “Research Network” top node instead of project based, the whole order broke down. It is no longer clear what level in the hierarchy has what role, where to find an overview of all existing projects, if all data of a project is in one folder or not, if project folders might contain other folders, if folders might contain themselves (I wouldn’t be surprised in Drive), and so on …

But we can’t have >50 team drives (“one per project”) either. And if we would apply the full four-state folder structure inside each team drive, some of these folders will often stay empty (means, “too much structure”). As a compromise, an example team drive folder layout might be:

Team Drive's root folder
│
├─── Team CVs etc.
│                
├┬── PROJECT ARCHIVE
│├──── Old project 1
│├──── Old project 2 (recyclable)
│└──── Old project 3          
│                
├─── Project: POPREBEL
│                
├─── Project: Transformations
│                
└─── ...

So recyclable projects would be marked with a tag in the name, but all inactive projects would go into a “PROJECT ARCHIVE” folder. All active projects would have a “Project: …” name prefix, keeping them apart from non-project folders without needing one more level of folders. We would not differentiate between potential current projects – there’s not much of a need as both are being worked on, or otherwise they’d move to the archive.

And I think we should not move finished projects out of team folders. Nobody likes having access to data taken away for no proper reason, and maybe they need the old data at some time.


#8

Why not? One benefit of the Team Drives is that you only see them if you are in the team. I personally don’t want to be cluttered with a lot of folders I have little to do with, and being able to just remove myself from a Team Drive and not having to worry about it if I disengage from a project that goes on without me sounds pretty appealing. You can still see and manage all the Team Drives in the organization from the admin console.

In practice though, I think that only major projects need their own Team Drives. But a project like POPREBEL should definitely have its own drive. Why? Because otherwise we are not achieving the sort of project insulation that allows us to set security levels according to the nature of the project. That was one of the major points of this whole restructuring. Now, we can give an external collaborating project leader full manager rights over the team drive of a project while still not letting her in to other projects.


#9

This is a very strong argument. Also quite elegant: instead of building a n-level hierarchy, you flatten everything and focus on managing who has access to what. Also very good in terms of security.

What happens with “orphan” projects, where the people involved all leave or were contracted one-off to begin with? (Not a major issue, I know)


#10

We can still access the Team Drive through the admin interface and can move the content to a folder in the main archive.


#11

Yes, I am not worried to lose access. More about having a “drive steward of last resort”. I guess that would be the admin, by default. Yes, ok, it works for me! Very well, actually. Thanks!


#12

[quote=“hugi, post:8, topic:9460”]

But we can’t have >50 team drives (“one per project”) either.

Why not?[/quote]

Does not seem ergonomic to me: >50 team drives without a way to group them by past / current / future projects is not nice to navigate (and if only for the superadmins). Also, potentially >50 different policies will get people wondering why they can’t do this or that in this or that team drive.

True, for example we should offer that to the POPREBEL collaborators. However, in their case I would not accept that, as “their files in our team drives” also means we could, if we want, cut their access to their own files. That’s the argument why we didn’t want to proceed with Google Drive for people we hire. In the ideal case, every organization has full control over the files they create.


#13

I suppose that could be a problem, though a compromise could be to name the team drives according to a convention, since they are automatically sorted alphabetically. That would at least allow for some grouping.

I also think that team drives could be archived some time (six months to a year?) after project completion. If people are given notice to backup anything they might want to their own drives, that seems reasonable.


#14

Agreed. Which is why I started to create the Culture Squad team drive, and that I think should include Trust in Play, and any other smaller projects which involve the same people who are in this team drive. For the sake of the confort of working together, it’s important the 2-3-4 members of a larger project automatically see the smaller projects in them. I.E. i dont want to have to decide every time a new lead comes in whether to offer a close collaborator access to a new folder.
Another issue is navigation: All Projects - > Current project -> Project name is too long a path when you’re on something daily.

I am in favor of the benefits of a process, but not all the projects are straightforward, so I would reserve the right to some judgement calls which might not exactly fit all purposes.


#15

@hugi ,

Great work for setting this up. We use Enterprises for our work at the venue in Bedford and i’m a big fan of the usability of the software. It’s not 100% flexible (i wish i could tag stuff as well as use a hierarchy tree - so things appear in more than 1 folder) but as long as there’s a clear technique for top level structures i think it works well. Not everyone is an archivist!

Wanted to ask if you’d explored the option of registering with Google for Non-profits?: https://www.google.com/nonprofits/offerings/apps-for-nonprofits.html
We’ve been paying for the services for a year and i only just realised that there was a possibility we can get all the software services for free! ER may need to register an account through something like TechSoup - https://estonia.techsoup.global/?ts_cs_selection=131

Happy to help with the set up if you think its worth exploring. (assuming you haven’t already!)


#16

I hadn’t. Non-profits get GSuite Basic for free, apparently. Unfortunately though, GSuite Basic, doesn’t support Team Drives.


#18

One more thing to integrate / document in the manual above, by whoever will take on that job eventually:

Cost optimization for Google Drive Enterprise

In the old Google Drive “Edgeryders Admin” folder we had >900 people who had access to at least one file or folder with their Google Account. We don’t want to pay for all of them, as that would quickly become expensive:

Drive Enterprise Pricing: $8.00 per active user per month. An “Active User” signs in to Drive Enterprise at least once during the month or has had data synchronized to/from Drive Enterprise at least once during the Fee Accrual Period*. (source)

So instead, there is a nice “loophole”. Actions on files (viewing, downloading, editing) are not charged when done by users outside of the Google Drive Enterprise domain (edgeryders.eu in our case):

Some user actions don’t trigger an active user charge. These uncharged activities include […] Accessing of files by users outside of your domain (source)

It is not clear from that what “accessing” means: only viewing, or also editing? Also, what about creating files by members outside of the organization which have been added as members to a Team Drive?

I made some quick tests by adding my non-edgeryders.eu Google Account and looked at “Billing” in the Admin console. Nothing changed. Also the “Activities in last 7 days: 6 Active users” counter on the Admin console sidebar did not change (and that’s probably using the same “active users” calculation as “monthly active users” in billing. So indeed it seems we’re only ever charged for activities with users having an …@edgeryders.eu Google Account. Also the “Reducing users and cancellation” instructions here at the bottom only talk about managing the …@edgeryders.eu Google Drive Enterprise users, confirming that users outside of the organization’s domain just don’t matter for billing.

And I could not yet find a drawback of adding people with Google Accounts outside our domain (means, not ending in …@edgeryders.eu) to the Team Drives. According to my tests, they can be given all the permissions as other members, and files they create can be removed by Team Drive admin users, and they will lose access to their own files when their Team Drive member status is removed. That’s all the control we need to prevent people from doing damage to our files. (I did not yet test if their files can be transferred to other owners, but probably yes. And if not, we can still copy them and delete the original, while the original owner can’t do damage if we exclude their access first.)

So an economic proposal for account management will be this:

  • Give Edgeryders Directors a Google Drive Enterprise account (means, a Google account for an address ending in …@edgeryders.eu). This is needed because they will be or should be able to become superadmins of our Google Drive Enterprise.

  • Add everyone else to Edgeryders Team Drives using their personal Google Accounts. This also means that people don’t have to switch their Google Account to access their Edgeryders Team Drive files.

As @hugi noted elsewhere, sharing settings for individual files and folders are more limited in Team Drives compared to the normal “My Drive”: “Only documents can be shared outside of the organization, not folders.” For our case, this means simple to structure our Team Drives so that we’re ok with all members getting access to all files in them. Access type can be varied though: view, also comment, also edit, also create and delete, also manage members.

(I think this is relevant for @alberto when setting up the Team Drives for our H2020 projects.)


Using edgeryders.eu e-mail addresses
#19

I thought that was the case too, but our GSuite for non-profits was just introduced and i’ve actually had Team Drives introduced to our account (without asking for it)


#20

Agreed! Easy and cheap. Plus it removes the stress of adding more users - if all control is from the individual team drives, then easier to keep track of all collaborators over the course of a project or team effort.
Unless asked specifically, I think I’m going to use that function rather than new Users, if thats okay.