Skip to main content

Agency File Collaboration Model

Purpose​

This document defines how file collaboration should work in the product from the start.

Detailed source-of-truth docs now live here:

It answers the planning question: should this behave like a client-specific drive, a request workflow, or both?

Recommendation​

It should be both, but with a tighter ownership rule:

  • the base model is a client-root collaboration system
  • Drive is the advanced file-centric operational view for general shared files, uploads, and retrieval
  • feature-specific artifacts remain owned by their feature context
  • upload requests are a lightweight coordination layer on top of the right destination

The product foundation is not "everything is Drive."

The product foundation is "the client owns the work, and files can be contributed from the context that already owns them."

Why This Is The Right Shape​

If the product starts with requests only, the workspace feels rigid and transactional.

If the product starts with uploads only and no structured request concept, agencies lose a useful way to ask for assets, content, approvals, or missing materials.

The right model is:

  • every client gets a collaboration surface by default
  • both sides can exchange files in the context that already owns the work
  • agencies can create explicit requests when needed
  • agencies and clients can generate a scoped upload link when a one-off outside contributor should send files into one exact destination without becoming a full portal user, but client-created links must stay inside destinations that client can already access
  • the same upload/storage infrastructure can serve Drive, projects, contracts, billing, and future client-owned features without making Drive the owner of all artifacts

Default Drive Model​

The moment a client account is active and portal access is live, that client should effectively have a shared collaboration workspace.

Drive is the file-centric view into that collaboration workspace, not the only place where uploads may start.

At minimum this drive should support:

  • agency uploads
  • client uploads
  • account-wide files
  • optional project-linked files
  • uploader/source visibility
  • categories and filtering

Do not overbuild folders and permissions too early.

The first good model is likely:

  • shared files
  • client uploads
  • deliverables

Important ownership rule:

  • project files should be uploadable from the project flow
  • contract attachments should be attachable from the contract flow
  • billing attachments should be attachable from the billing flow
  • Drive should remain the primary surface for general shared client material, ad hoc collection, and file-first retrieval across contexts

Internal-only agency files should stay outside the portal-facing drive model.

Upload Permission Model​

Recommended default:

  • client uploads are enabled in the shared workspace model

Recommended agency-side visibility default:

  • uploaded files are visible to agency members who already have access to that client workspace

Recommended control:

  • the agency can disable or restrict client uploads at the account level if needed later

Recommended non-goal for the starting model:

  • do not require agencies to decide per-file which internal staff can see a normal client upload

External Contributors​

Some uploads will come from people who are not yet part of the client portal grant set.

Recommended model:

  • keep portal login as the default for recurring collaboration
  • add a scoped upload-link path for one-off outside contributors
  • make that link destination-specific and upload-only
  • let authenticated portal clients mint and manage contributor links only within already-visible shared destinations
  • preserve uploader provenance so the agency can see who submitted what and through which link

This solves the real handoff problem without turning the drive into a public file drop.

Public Sharing​

Do not treat “public” as the default answer for outside contributors.

Recommended rule:

  • no general public browsing of client drive folders
  • no anonymous uploads into shared client workspaces
  • if later needed, public read links for specific deliverables should be a separate capability from upload links and portal access

Important product rule:

Do not make client uploads a rare exception. Back-and-forth exchange is part of the core value of the workspace.

File Requests​

File requests should exist from the start, but lightly.

They should let the agency ask for:

  • logos and brand assets
  • content documents
  • approvals or signed materials
  • files needed for project execution

Recommended statuses:

  • requested
  • submitted
  • reviewed
  • closed

This is enough structure without turning the feature into a helpdesk or BPM engine.

Relationship To Docs​

Files and docs are not the same thing.

  • files are uploaded assets
  • docs are structured readable content

The shared drive is primarily for file exchange.

Structured docs can sit beside it, but should not replace it.

Product Rule​

If a client logs into the portal and cannot easily find where to upload a requested file or share something back with the agency, the workspace model is incomplete.

Additional product rule:

Do not force users to go to Drive just because a file is involved.

If the owning business context is already known, the upload action should exist there.

  • project page: upload project files there
  • contract flow: attach contract files there
  • billing flow: attach billing files there
  • Drive: use it for general shared client material, ad hoc collection, file requests, contributor links, and cross-client operational retrieval

Route Fit​

Org​

The agency should manage:

  • account drive
  • project files
  • upload requests
  • visibility and categorization

The org Drive workspace should be treated as the advanced file operations surface across one or many clients, not the sole place where staff can start file work.

Portal​

The client should access:

  • shared drive
  • upload actions
  • request list
  • request fulfillment status

Portal users should also upload from the context they are already in when that context is clearer than the Drive itself.

Final Planning Rule​

The product should start as a real collaborative workspace with a drive mentality.

Upload requests should refine that collaboration, not stand in for it.

And on the agency side, the simplest sensible rule is the right starting rule:

  • if you can access the client account, you can access the client's shared files by default