# Google Workspace Drive Setup: Recommendation for El Paraiso Golf Club

**Date:** March 2025  
**Context:** Business workspace with role-based emails (e.g. secretary@elparaisogolfclub.com as main admin; secretary@, finance@, chairman@, members@elparaisogolf.com as role accounts for e.g. Webmail). Goal: one company-owned Drive structure with **control at company and role level**—share folders with the **individual's email** of the person currently in each role so when they leave the admin can remove that email and add the next person. Do **not** have individuals log into role accounts for Drive (that ties control to the individual and you lose it when they leave). Plesk Event Register (members.elparaisogolfclub.com) shows "My Google Drive Directory" so authorised members open their role folder while logged into Google as their own email.

---

## Summary

**Recommendation:** Use **one shared Drive and a dedicated directory (folder) per role/area**, with access controlled by **sharing folders with the individual's email** (e.g. barry@scala4.com) of the person who currently holds that role—**not** by having individuals log into a role account (e.g. secretary@elparaisogolf.com). That way the company retains full control: when someone leaves, remove their email from the folder and add the new person. Do **not** give individuals the role account password or have them "connect" to the role account for Drive; that ties control to the individual and you lose it when they leave.

---

## Your Current Setup

- **Main admin / moderator:** secretary@elparaisogolfclub.com (Workspace owner; shares folders and manages access).
- **Role accounts:** secretary@, finance@, chairman@, members@, admin@elparaisogolf.com (for access only, not personal ownership).
- **Plesk Event Register:** https://member.elparaisogolfclub.com/ — members log in with member ID (e.g. 200002) and see "My Role" with Webmail and **My Google Drive Directory**.
- **Constraint:** Company retains ownership and control. Only authorised roles get access; personal emails (e.g. barry@scala4.com) must not gain access when someone clicks a shared folder link.

---

## Control at Company and Role Level (Not Individual)

**The problem with role-account logins**

- To use Drive as "Secretary", Barry has to log into Google as **secretary@elparaisogolf.com**—so Barry must have (or "set up a connection" to) that role account.
- Control then sits with **Barry**: he knows the password, he's the one using the role account. The workspace is effectively tied to him.
- When **Barry leaves**, the administrator has lost control: they cannot simply reassign the Secretary role to a new volunteer. They must reset the role account password, hand it to the next person, and hope nothing was left in Barry's hands. The company does **not** retain control at a **role** level; it has slipped to the **individual** level.

**What you want**

- **Company-level control:** The company (secretary@elparaisogolfclub.com) owns all folders and decides who has access.
- **Role-level assignment:** "The Secretary role is held by Barry" and later "The Secretary role is held by Jane" without losing the workspace or fighting a role account tied to one person.
- **No individual "ownership" of the role:** When someone leaves, the admin removes their access and adds the new person. No role account password to recover or reassign.

**Solution: Share folders with the individual's email, not the role account**

- **Do not** share Drive folders with **role accounts** (secretary@elparaisogolf.com, finance@elparaisogolf.com) and then have people log into those accounts. That ties control to whoever has the password.
- **Do** share each **role folder** (e.g. EPGC Root / Secretary) with the **individual's email** of the person who currently holds that role—e.g. **barry@scala4.com** while Barry is Secretary, **jane@example.com** when Jane takes over.
- The **company** (secretary@elparaisogolfclub.com) adds or removes people from the folder share when they take up or leave the role. No one needs the role account password for Drive. Control stays with the company.
- In **Plesk ER**, "My Google Drive Directory" still points to the same folder URL (e.g. EPGC Root / Secretary). When Barry logs into member.elparaisogolfclub.com and clicks the link while **logged into Google as barry@scala4.com**, he gets access because the folder is **shared with barry@scala4.com**. When Barry leaves, the admin **removes barry@scala4.com** from the folder and **adds jane@example.com**. Jane then has access when she clicks the same link from Plesk. The company has reassigned the role without losing control.

**Role accounts (secretary@, finance@, …) can still be used for e.g. Webmail** (a shared mailbox), but **Drive access should be by direct share to the individual's email** of the person currently in that role. That way control remains at company and role level, not at individual level.

---

## EPGC Root Structure and Permissions (Scenarios)

Use a **single Workspace Drive** with one master directory and subfolders. All documents live under it; permissions are set per folder. **Share each folder with the individual's email** of the person who currently holds that role (e.g. barry@scala4.com for Secretary), not with the role account. When someone leaves, remove their email and add the new person. Example structure:

| Directory | Edit access | Read access | Notes |
|-----------|-------------|-------------|--------|
| **EPGC Root** | secretary@elparaisogolfclub.com (admin) | As needed | Master directory; all other folders under this. |
| **EPGC Root / Board** | Individual emails for Chairman & Secretary roles | Individual email for Finance role | Board-only content. |
| **EPGC Root / Strategy** | Individual emails for Chairman, Finance, Secretary | As needed | Strategy docs. |
| **EPGC Root / Finance** (member 200002) | Individual email of person in Finance role | As needed | Role's own directory. |
| **EPGC Root / Chairman** (member 200003) | Individual email of person in Chairman role | As needed | Role's own directory. |
| **EPGC Root / Secretary** (member 200004) | Individual email of person in Secretary role | As needed | Role's own directory. |
| **EPGC Root / Policies** | Individual emails for Chairman, Secretary, Members, Admin roles | Individual emails for Finance + all members (read-only) | For read-only display on elparaisogolfclub.com. |
| **EPGC Root / [Other]** | Set per folder | Set per folder | Share with the **individual emails** of people in the relevant roles. |

**Best practice:** Share folders with the **individual's email** of the person currently in each role (e.g. barry@scala4.com while Barry is Secretary). Do **not** share with role accounts (secretary@elparaisogolf.com) and have people log in as those accounts—that ties control to the individual. Keep ownership with secretary@elparaisogolfclub.com. When someone leaves, remove their email from the folder and add the new person; the company keeps full control.

---

## The "Request Access" Problem (What to Avoid)

**What happens:**  
1. secretary@elparaisogolfclub.com shares a folder (e.g. **EPGC Root / Test**) with **secretary@elparaisogolf.com** (role account).  
2. The role account receives the share email in **Webmail** (accessed via Plesk ER).  
3. Someone (e.g. Barry) is logged into **Chrome** as **barry@scala4.com**.  
4. Barry opens member.elparaisogolfclub.com, goes to Webmail, opens secretary@elparaisogolf.com, and clicks **Open** on the shared folder link.  
5. Google sees the click from **barry@scala4.com** and sends "Share a folder? Barry is requesting access" to secretary@elparaisogolfclub.com.  
6. If the admin clicks **OK**, **barry@scala4.com** is granted access.

**Why this is bad:** A **personal email** gets access, not only the role. You lose control over who can access the folder. (Worse: if you instead have Barry log into Google as secretary@elparaisogolf.com, control ties to Barry—when he leaves, the company loses control of that role. See **Control at Company and Role Level** above.)

**Best practice – do not:** Open **folder share links** ("Open" in the share invitation email) from the **role's Webmail** when your **browser is logged into Google as a personal account**. Prefer **not** sharing with role accounts at all for Drive; share directly with the **individual's email** (barry@scala4.com) so the company can add/remove people when roles change.

---

## How to Provide Access via Plesk Event Register

**Goal:** Members (e.g. 200002 Finance) see a link that takes them to **their role's** Google Drive folder with edit (or read) access. Control stays with the company: the folder is shared with **their individual email** (e.g. barry@scala4.com), so when they leave the admin removes that email and adds the next person—no role account password to lose.

**How it works:** In **Volunteer Management**, each role has **My Google Drive directory URL** (the direct link to that role's folder). The **company** (secretary@elparaisogolfclub.com) shares that folder with the **individual's email** of the person currently in that role (e.g. barry@scala4.com for Secretary). When a member logs into member.elparaisogolfclub.com with their member ID, the dashboard shows **My Role** → **My Google Drive Directory**. That link uses the URL stored for their role.

**Recommended flow:** (1) Member logs into Google as **their own email** (e.g. barry@scala4.com)—the same email the admin has shared the role folder with. (2) Log into member.elparaisogolfclub.com with member ID. (3) Click **My Role** → **My Google Drive Directory**. The folder opens because it is shared with their email. No need to log into a role account; the company retains control by adding/removing that email when the role changes hands.

### One link vs several: role with multiple folders

**Example:** Secretary (member 200003) has three folders shared with barry@scala4.com: **Board** (edit), **Strategy** (edit), **Test** (read). Should the dashboard show one shortcut per directory or one link to the club workspace?

| Approach | Pros | Cons |
|----------|------|------|
| **One link to the club workspace** (e.g. EPGC Root or a “Secretary” home folder) | One URL to maintain per role. Member opens one link and sees all folders they have access to in Drive. When the role gets more/less access, only Google sharing changes; the dashboard link stays the same. | Member may need to navigate inside Drive to find Board / Strategy / Test if the root is shared; or use a single “Secretary” folder that contains shortcuts to Board, Strategy, Test. |
| **One shortcut link per directory** (Board, Strategy, Test) | Direct access to each area; no navigation. | More URLs to maintain in Volunteer Management. If the role’s access changes (e.g. Secretary loses “Test”), the admin must update or remove that link. |

**Recommendation:** Prefer **one link per role** to a single “role workspace” (e.g. **EPGC Root / Secretary** or a folder that contains shortcuts to Board, Strategy, Test). The admin shares that folder (and/or the underlying folders) with the role holder’s email. Fewer links to manage; when the role changes hands (Barry → Jane), the same link still works for the new person. If you need direct one-click access to several distinct areas, you can add **multiple links** per role in the dashboard (e.g. “Board”, “Strategy”, “Test”) and accept the extra maintenance.

### How to create the one link (administrator steps)

You already have three directories shared with Barry for Secretary (e.g. Board, Strategy, Test). To give the dashboard **one** link that opens a single place where Barry sees all three:

1. **In Google Drive** (logged in as secretary@elparaisogolfclub.com), create **one folder** that will be the "Secretary workspace" — e.g. under EPGC Root, create a folder named **Secretary** (or "Secretary – links" if you prefer).

2. **Put the three directories in one place**, using either:
   - **Option A – Shortcuts:** Keep Board, Strategy, and Test where they are. Open your new **Secretary** folder. Right‑click → **Add shortcut to Drive** (or use **File → Add shortcut to Drive**), then choose **Board**, **Strategy**, and **Test**. Now this folder contains three shortcuts to those folders.
   - **Option B – Subfolders:** If Board, Strategy, and Test can live inside one parent, move them (or create copies) so they are **subfolders** of this **Secretary** folder. Then you only share this one parent folder with barry@scala4.com (and remove the old separate shares for Board, Strategy, Test if you no longer need them).

3. **Share this one folder** (the "Secretary" folder) with **barry@scala4.com** with the appropriate access (e.g. Editor). If you used Option A (shortcuts), Barry must already have access to Board, Strategy, and Test — the shared folder just gives him one opening view with the three shortcuts inside.

4. **Get the folder URL:** Open that **Secretary** folder in Drive in your browser. Copy the URL from the address bar (e.g. `https://drive.google.com/drive/folders/xxxxxxxxxxxxx`).

5. **Add the link in Volunteer Management:** In member.elparaisogolfclub.com go to **Volunteer Management** → edit the **Secretary** role → paste that URL into **My Google Drive directory URL** → save.

When Barry (logged into Google as barry@scala4.com) clicks **My Role** → **My Google Drive Directory** on the dashboard, he opens that one folder and from there can open Board, Strategy, and Test (via shortcuts or subfolders). You maintain a single link per role; when the role changes to Jane, remove barry@scala4.com from that folder and add jane@example.com — the URL in Volunteer Management stays the same.

### Who updates the link(s) in the dashboard

**The administrator** (e.g. secretary@elparaisogolfclub.com or whoever manages Volunteer Management) should create and update the “My Google Drive directory” link(s) for each role—**not** the volunteer who holds the role.

- **Why:** Control stays at **company level**. The company decides which folder(s) the role sees. If the role holder (e.g. Barry) could edit the link, they could point it to a personal Drive or wrong folder. The same link applies regardless of who currently holds the role (Barry today, Jane tomorrow); only **Google Drive sharing** (who has access) is updated when the role changes hands.
- **Where:** In member.elparaisogolfclub.com → **Volunteer Management** → edit the role → set **My Google Drive directory URL** (and any extra directory links if your dashboard supports multiple per role). Restrict Volunteer Management to administrators only.

---

## Policies: Read-Only on the Public Website

**EPGC Root / Policies** has edit for the individual emails of people in Chairman, Secretary, Members, Admin roles and **read** for the individual emails of Finance and all members. For **elparaisogolfclub.com** (where members log in with **personal emails**), you want Policies as **read-only**. Keep the source of truth in Drive (company-owned). On the website, either embed/link to a **published** version of the folder or key files ("Anyone with the link can view"), or use an app that reads from Drive with a service account and displays content read-only to logged-in members. That way the public site does not create new Drive permissions for personal emails beyond the ones the company explicitly grants for role folders.

---

## Do's and Don'ts (Summary)

**Do:**  
- Use **one** company-owned structure under **EPGC Root**; all documents under it.  
- Share folders with the **individual's email** of the person who currently holds each role (e.g. barry@scala4.com for Secretary)—**not** with role accounts that people log into. That keeps control at company/role level: when someone leaves, remove their email and add the new person.  
- Set **My Google Drive directory URL** per role in Volunteer Management so **My Role** → **My Google Drive Directory** opens the correct folder. The **administrator** (not the role holder) should maintain these links.  
- Have members open that link while **logged into Google as their own email** (the one the admin has shared the folder with).  
- Use **secretary@elparaisogolfclub.com** as the single main admin for creating folders and adding/removing individual emails from shares.

**Don't:**  
- **Don't** give individuals the **role account password** or have them log into secretary@elparaisogolf.com (or other role accounts) for Drive—that ties control to the individual; when they leave, the company loses control.  
- Don't open **share invitation links** ("Open" in the role's Webmail) when your browser is logged into Google as a **personal account** (if you still use role-account shares).  
- Don't give **ownership** of drives or top-level workspaces to role accounts or individuals; keep ownership with the Workspace admin.  
- Don't create **separate Google Drives** for each person that they "own"; use **folders** under EPGC Root and control access by sharing with individual emails, adding/removing as roles change.

---

## The Two Approaches (Reference)

### Option A: One Shared Space + One Folder per Employee (Recommended)

**How it works**

- Use **one** Shared drive (or the main organisation Drive) for the business.
- Create a **folder per employee**, for example:
  - `Employees / Secretary`
  - `Employees / Finance`
  - `Employees / Members`
- Grant each person:
  - Access to the **main/shared areas** they need (e.g. shared club drive, common folders).
  - **Editor** or **Content manager** (as appropriate) on **their own folder** only.

**Benefits**

- **Ownership:** Everything stays under the company account or Shared drive. The company owns all files.
- **Control:** You decide who can see and edit which folders. No handover of “ownership” to individuals.
- **Simplicity:** One place to manage, back up, and search. Clear structure.
- **When someone leaves:** Remove their permissions (and optionally move or archive their folder). No risk of them “taking” a whole Drive.
- **No conflict with Google’s rules:** You are not trying to give individuals ownership of a Drive; you are only sharing folders.

**What you give up**

- You must maintain folder permissions (who can access which folder). This is a small, one-time setup and occasional maintenance.

---

### Option B: Separate “Drive” per Employee

**What it can mean**

1. **Separate Workspace user per employee** (e.g. secretary@, finance@, members@)  
   - Each user has their own **My Drive**, but it is still part of **your organisation**.  
   - You keep control via Google Admin (transfer ownership, delete user, reset access, etc.).  
   - **Benefit:** Strong isolation per person. **Cost:** More user accounts, more licenses, more to manage.

2. **Separate Drive owned by a personal/external account**  
   - If you create a Drive (or transfer ownership) to a personal Gmail or external account, **that account owns it**.  
   - The company loses ownership and control. **Not recommended** if you want to retain control.

**Conclusion on Option B**

- There is **no extra benefit in ownership** from giving each employee a “separate Drive” compared to giving them a **folder** in a shared space.
- Separate Workspace users (and thus separate Drives) are only worth it if you need strict separation (e.g. compliance, very different roles) and are willing to manage more users and licenses.

---

## Recommendation in Practice

**Use Option A:** One shared space and one directory per employee, with permissions.

- **Sufficient for:**  
  - Access to the main Google Drive  
  - A dedicated directory per employee  
  - Full company ownership and control  

- **Avoid:**  
  - Creating separate Drives that are owned by personal or external accounts (you lose control).  

- **Consider separate Workspace users (and thus separate “Drives” per employee) only if:**  
  - You need strict isolation (e.g. compliance, confidentiality by role), and  
  - You are willing to manage more user accounts and licenses.

---

## Suggested Folder Structure (Example)

```
EPGC Root (owner: secretary@elparaisogolfclub.com)
├── Board          (edit: chairman@, secretary@; read: finance@)
├── Strategy       (edit: chairman@, finance@, secretary@)
├── Finance        (member 200002 – edit: finance@)
├── Chairman       (member 200003 – edit: chairman@)
├── Secretary      (member 200004 – edit: secretary@)
├── Policies       (edit: chairman@, secretary@, members@, admin@; read: finance@ + all members)
└── [Other]        (set permissions per folder)
```

- **Permissions:** Share each folder with the **individual emails** of the people currently in each role (add/remove when roles change). Do **not** share with role accounts and have people log in as those accounts—that ties control to the individual.  
- **Ownership:** All content remains under the company Workspace; secretary@elparaisogolfclub.com creates folders and manages who (by individual email) has access.

---

## Summary Table

| Aspect              | One shared space + folder per employee | Separate Drive per employee (org user) |
|---------------------|----------------------------------------|----------------------------------------|
| Company ownership   | Yes                                    | Yes (if org user)                      |
| Simplicity          | High                                   | Lower (more accounts)                  |
| Control & revoke    | Straightforward (permissions)           | Via Admin (user/Drive)                 |
| Best when           | Small/medium team, clear structure     | Strong isolation per person required  |

**Bottom line:** Use **one shared space (EPGC Root) and one directory per role/area**. Share each folder with the **individual's email** of the person currently in that role—**not** with role accounts that people log into—so the company retains control: when someone leaves, remove their email and add the new person. Use the **Plesk ER "My Google Drive Directory"** link; members open it while logged into Google as **their own email** (the one the admin has shared with). **Do not** give individuals the role account password or have them "connect" to the role account for Drive; that would tie control to the individual and you lose it when they leave.

---

*This document reflects the recommendation as of March 2025. Google Workspace features and policies may change; refer to Google’s current documentation and your Workspace admin settings when implementing.*
