# BYOS Folder Layout — Where Each File Lands

_Other Tools_

When you connect Google Drive, OneDrive, or Dropbox, CRMown creates a top-level /CRMown folder in your account and routes every file CRMown writes into a deterministic sub-path under it. The path encodes the folder's scope (org-shared / team / user-private / contact-record) and the suite it belongs to (Operations, Comm Pro, Web Studio, etc.). Use this article when you can't find a file in your provider — once you know the rules, you can navigate straight to it.

## Steps
1. Open your connected provider (Drive / OneDrive / Dropbox) and navigate to the /CRMown folder. That is your org's root vault.
2. Inside /CRMown there are four top-level scope folders: _org/ (everyone in the org), _users/{userId}/ (private to one user), _teams/{teamId}/ (shared with a team), and _org/contacts/{contactId}/ (record-scoped).
3. Inside _org/, files are grouped by suite: cal_pro, comm_pro, web_studio, marketing, automation, education, finance, growth, client_hub, plus a general bucket for ad-hoc Documents Vault uploads.
4. Each suite has a fixed set of sub-folders (registered in packages/shared/src/suites.ts). E.g. cal_pro has events / invitations / recordings; web_studio has sites / forms / surveys / quizzes / chat_widgets / etc.
5. Within those sub-folders, the actual structure depends on the feature. Examples below show what's shipping today versus what the registry reserves for future use.

## Tips
- TODAY'S LAYOUT (what you'll see in your provider as of 2026-05-08):
-   /CRMown/                                       ← org root (one folder per provider)
-   ├── Calendar/                                  ← human-readable, NOT under _org/cal_pro yet
-   │   └── Meetings/                              ← Phase 1 of meeting recording archive
-   │       └── 2026-05-08/                        ← UTC date (not local tz)
-   │           └── 14-32-Discovery Call-mt1abc/   ← per-meeting subfolder, owner-tagged
-   │               ├── audio.webm  (or .mp4 / .mp3)
-   │               ├── transcript.txt
-   │               └── segments.json
-   ├── _org/                                      ← shared, org-wide artifacts
-   │   ├── web_studio/forms/{formId}/...          ← form attachments (wired)
-   │   ├── growth/reviews/...                     ← review request artifacts (wired)
-   │   ├── general/default/...                    ← Documents Vault root uploads
-   │   └── contacts/{contactId}/...               ← contact-scoped attachments
-   ├── _users/{userId}/...                        ← private docs (e.g. drafts)
-   └── _teams/{teamId}/...                        ← team-shared docs
- REGISTRY-RESERVED (defined in suites.ts but not yet wired to actually create files):
-   /CRMown/_org/
-   ├── cal_pro/{events,invitations,recordings}/   ← meetings will move here in a future phase
-   ├── comm_pro/channels/{channelId}/...          ← chat file uploads + JSONL transcripts
-   ├── web_studio/{sites,funnels,stores,blogs,quizzes,chat_widgets}/...
-   ├── marketing/{campaigns,emails,sms,social}/...
-   ├── automation/{workflows,triggers,templates}/...
-   ├── education/{courses,lessons,resources}/...
-   ├── finance/{invoices,proposals,expenses,reports}/...
-   └── client_hub/clients/...
- Slugification: user-supplied folder names get slugged (lowercased, non-[a-z0-9-] replaced with -, leading/trailing dashes stripped) before being used as path segments. Suite IDs and sub-folder names are passed through verbatim from the registry.
- Per-meeting subfolder ownerUserId tagging is what makes Org.visibilityMode work at the BYOS layer — under owned/brokerage modes, non-admins only see meeting subfolders they own. Other suites' folders are still org-wide-visible.
- Auto-recovery: if you trash /CRMown manually in your provider, the next upload re-creates a fresh /CRMown root (a warning is logged server-side). Files that were in the trashed folder stay in your provider's trash — recover them from there if needed.

## Example
An office manager wants to find the audio recording from a Tuesday discovery call with a vendor. They open Google Drive → /CRMown → Calendar → Meetings → 2026-05-08 → 14-32-Discovery Call-mt1abc — three nested folders later they have audio.webm, transcript.txt, and segments.json side by side. Months from now when the vendor follows up, they can replay the call directly from Drive without going back into CRMown.

## Troubleshooting
- **Recordings I uploaded today don't show up in Calendar/Meetings/<date>/** — Either (a) the org is still on local storage (Settings → Communications → File Storage), (b) the meeting summary worker hasn't finished — it runs after the AI extraction pipeline, so figure ~30s after /end fires, or (c) the BYOS provider is having a temporary outage (the chunks stay buffered on EFS and re-upload on retry). Fix: Settings → Communications → File Storage to confirm a cloud provider is selected. If it is, wait 60 seconds and refresh the provider — the worker logs failures with [meeting-audio] prefixes.
- **I can see /CRMown in my provider but the date folder is empty even though meetings happened** — Date folders use UTC (2026-05-08 = the meeting's UTC date). A meeting at 7pm Pacific lands in the next-day folder. This avoids surprise tz-shift collisions across a multi-region org. Fix: Check the adjacent date folder — the meeting's UTC date is likely off by one from your local view.
- **Forms / Surveys / Marketing assets aren't using the canonical _org/{suite}/{subfolder}/ path** — Only some suites are wired to the registry today (Web Studio forms, Growth reviews, and the new per-meeting subfolders). Other suites are still org-shared without suite tagging — files land in the provider root with whatever filename the upload uses. Fix: Future phases will route every suite through the registry. For now, the file is still in your /CRMown vault — just at the root, not under _org/{suite}/. Search by filename.
- **I can see another rep's _users/{userId}/ folder** — OWNER and ADMIN have an audit override and can see the Members' Private filter on the in-app Folders page. From the provider side, every file in /CRMown is visible to whoever owns the connected provider account (the storage authority). Fix: If non-admins are seeing each other's _users folders inside CRMown, that's a bug — file an issue. Provider-side visibility is intentional for the storage authority.
