Document Storage Without Handing Over Your Cloud Account
On this page
The problem: files scattered across personal drives
Most organizations' "document management" is really just a collection of personal drives — one person's Dropbox, another's local folder, a shared drive that only half the team has access to. There's no single, shared source of truth for where a given file actually lives, which means finding it depends on knowing who has it, not on knowing where to look.
SAVHN's Documents module addresses this with a secure document vault and asset library — a real shared home for files, instead of a patchwork of individual drives. And it does this with a specific, deliberate approach to cloud storage: bring-your-own-provider (BYOP). You connect your own storage — Dropbox and others — using your own token. SAVHN never operates a shared OAuth app on your behalf. That's not a minor implementation detail; it's a real difference in who controls access to your files.
What the Documents module actually does
- Document vault — a secure, central place for documents, rather than scattered personal storage.
- Asset library — a shared home for assets your organization uses repeatedly.
- Bring-your-own-provider (BYOP) cloud storage — you connect your own cloud storage account (Dropbox and others) using your own authentication token. SAVHN doesn't run a shared OAuth application that sits between you and your provider.
That BYOP detail is worth sitting with. Plenty of platforms integrate with cloud storage by running their own OAuth app — meaning the platform itself becomes an intermediary with standing access to your storage account, under an app registration you don't control and can't fully audit. SAVHN's approach is different: the token is yours, connected directly, and SAVHN isn't the thing standing between you and your own provider account.
Scattered personal drives vs. a shared vault
| Files scattered across personal drives | SAVHN Documents module |
|---|---|
| No shared source of truth for where a file lives | Central document vault and asset library |
| Finding a file depends on knowing who has it | Shared, structured storage anyone with access can search |
| Cloud storage integration runs through a shared vendor OAuth app | Bring-your-own-provider — your token, your account, directly connected |
| Access control is informal (whoever has the folder link) | Access lives inside the platform's own permission model |
How it works
- Documents and assets are stored in the platform's vault and asset library, giving the organization one place to look instead of many.
- If cloud storage is connected — Dropbox and others — it's connected with your own token. You authorize the connection directly with your provider; SAVHN isn't running a shared app that intermediates it.
- Because it's BYOP, the relationship is between you and your storage provider, not between your organization and a shared credential SAVHN manages centrally.
- Documents stored this way are available in context wherever they're relevant elsewhere on the platform — attached to a client, a project, or other records that need them.
Who uses this
- Anyone who needs a shared, findable place for organizational documents, instead of relying on knowing which colleague has the file.
- IT and security-conscious administrators, who care specifically about how cloud storage access is granted and want to avoid a shared third-party OAuth app holding standing access to company files.
- Teams already using Dropbox or similar providers, who want to keep using their own account and token rather than migrating everything into a new, closed storage system.
Common mistakes and misconceptions
A common misconception is assuming BYOP means SAVHN doesn't support cloud storage at all, or that it's a lesser integration than a "native" one. It's the opposite of a limitation — it means the access boundary is under your control, tied to a token you connected, rather than a shared app registration the platform maintains centrally.
Another mistake is treating the document vault and a personal cloud drive as interchangeable. The vault and asset library are meant to be the organization's shared, structured source of truth; a personal drive connected via BYOP extends storage capacity and lets people keep working with tools they already use, but it isn't a replacement for having documents actually organized in the shared vault where they're findable by anyone with access.
Why BYOP is a real design decision, not a limitation
It's worth spelling out what a shared OAuth app actually means in practice, because it's easy to skip past. When a platform runs its own shared OAuth application for a storage provider, every organization on that platform authorizes access through the platform's app registration — meaning the platform vendor has a standing, centrally managed credential relationship with every connected storage account across every customer. That's a meaningful amount of trust concentrated in one place, and it's also a meaningful amount of surface area if that shared app is ever compromised or misconfigured.
BYOP sidesteps that entirely. Your organization connects its own token, directly, to its own provider account. There's no shared app sitting in the middle accumulating access across every SAVHN customer. If you ever want to revoke that access, you do it the same way you'd revoke any other third-party token from your provider's own settings — not by asking a vendor to do it on your behalf.
Where it fits in SAVHN
Documents connects to the rest of the platform by being available wherever files are relevant — attached to client records in CRM, to project work in projects, or referenced in chat discussions. The BYOP approach to cloud storage reflects the same honest-software posture that runs through the rest of the platform: real functionality, described accurately, without quietly expanding what SAVHN itself has standing access to.
For details on connecting a storage provider and configuring vault permissions, see the documentation. Related topics are covered in the Knowledge Center.