đź“— Google Drive Enterprise Manual

Documentation & Support Collaboration
,
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.

1 Like
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!

1 Like
12

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.

1 Like
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.

1 Like
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?: Google Workspace: Nonprofit Resource Center - Google for Nonprofits
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!)

2 Likes
16

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

1 Like
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.)

3 Likes
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)

2 Likes
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.

1 Like
21

hallo - is there any way we can have the password reset be a reset password link sent to our email addresses? I reset mine very often and want to not bother @matthias all the time

22

Haven’t seen that option yet, but it could be somewhere.

Anyway, I have reset your Google Drive account password for now :slight_smile: You should have an e-mail with a link to set a new password for yourself. (P.S.: It’s not a shame to write passwords down. Just keep them secure.)