Integration of a file storage space
A stable reference, not a copied Drive link
We link Drive, SharePoint, Box or Dropbox to the business file. Permissions, retention periods, access renewal: the file stays with your host.
- File connectors in production
- reference vs copy decided
- tokens tracked
What is file-storage integration and when should you have it built?
Integrating a storage space means depositing, finding and sharing a document from your application, while leaving Drive, SharePoint, Box or Dropbox to hold the file. Links pasted in a text field break. You have the connector built when the business file must list documents, when an upload must respect the tree and permissions, or when a temporary link must no longer expire behind the user's back. This category is a mesh node more than a generic keyword target: document-management API and file-storage API have no volume of their own.
The file spaces we integrate
What makes a file look empty
The drive stores. Until the application holds more than a pasted URL, the link dies, rights diverge, the token expires.
The Drive link is dead, the file is empty
We store a file identifier, not a copied URL. The link is rebuilt, permissions are rechecked.
We do not know who is allowed to see the document
The upload maps your business rules (account, role) onto the drive. A customer document is no longer in a “shared with everyone” folder.
Each team files its own way
A tree set at scoping: customer folder, document type, year. The connector creates the path, it does not guess it.
The Microsoft token expired, nothing uploads any more
Refresh, alert, reconnection journey. A deaf drive is visible before the file is closed.
What each file space actually involves
Box
Enterprise DMSA DMS often already governed. The integration is judged on upload from the business, search in the file, and respect for policies already in place. We do not invent API quotas here.
- Upload from the application
- Document policy respected
- Scope settled at scoping
Dropbox
File sharingA sharing space still common in SMEs. A Dropbox link pasted in a field is not a connector: identifier, expiry, permissions. Scoping fixes what is stored with you (metadata) and what stays at Dropbox (the binary).
- Stable link, not a copied URL
- Metadata in the file
- Binary at the provider
Google Drive
Drive and SheetsDrive for files, sometimes Sheets for a living table. Drive and Sheets API volume exists; the category page meshes toward the file need. File identifier, parent folders, sharing: scoped before the first upload.
- File attached to the business record
- Sharing scoped
- Sheets only if the table is a deliverable
Microsoft 365
SharePoint, OneDriveSharePoint and OneDrive via Microsoft Graph. Useful when the company is already on Microsoft 365. No invented routes: scoping fixes sites, libraries, permissions and the same token topic as the Outlook calendar. A dump of “the whole tenant” is not an integration.
- Document in the file's library
- Permissions aligned with the business
- Graph scoped, not the whole tenant
Four ways to make the document live in the file
The file lists its documents
The file id sits in the business record. Opening the file means seeing documents, not a Drive on the side.
Upload at workflow start
Upload creates the document in the right place, with the account's rights. Not a folk drag-and-drop.
Time-boxed share
Link with a lifetime, account perimeter. The world-open “editor link” leaves the ritual.
Search in the account perimeter
Search in what the role may see. Not a crawl of the whole tenant.
Business, IT, security: who maps the rights
We do not “plug Drive in”. We put the document id in the product and map the roles.
The business opens a complete file
The documents are there. No more “the link is dead” in a client meeting.
IT stops being the token firefighter
Expiry, revocation, rotation: a runbook. Microsoft and Google revoke; this is not a rare bug.
Security maps business roles and drive ACLs
Drive rights are not your roles. We make them correspond, explicitly.
The archive is not a second silo
We duplicate the binary only if compliance requires it. Otherwise, a reference.
What we have shipped, and why it transfers here
The method a file space forces
Reference vs copy
File id in the business, binary in the drive, unless archive is required.
Deliverable: reference / copy choiceRights mapping
Role / ACL matrix, share, revocation.
Deliverable: rights matrixRetention policy
Durations, deletion, hold, owner.
Deliverable: retention policyToken rotation
Refresh, expiry alert, re-consent journey.
Deliverable: token runbookWhat nobody tells you before you sign
A copied URL is not a reference
Links expire, files move. We store the provider identifier, we rebuild access.
Drive permissions are not your business roles
Without mapping, an “editor share” opens too much. Scoping aligns the application account and the drive ACL.
The binary does not have to live twice
Unless there is an archive constraint, the file stays at the provider. Your database holds metadata and the stable link.
The Microsoft or Google token gets revoked
Without a reconnection journey, upload dies on a Monday. Microsoft and Google revoke tokens: refresh, alert and re-consent are a deliverable, not a late polish.
What we measure on a files project
File space integration: your questions
Three steps. First freeze the tree, permissions and what you store (metadata vs binary). Then wire OAuth with minimal scopes, set the file identifier as the reference, and an upload queue with retry. Finally test sharing, revocation and a moved file. The difficulty is not sending a byte, it is finding it six months later with the right permissions.
Listing documents in a file costs far less than a multi-site tree sync with permission mapping. Cleaning the existing drive weighs as much as the connector. We scope the perimeter up front and give a firm estimate.
Almost never. The drive stays the storage, the application stays the file. Duplicating binaries is expensive and creates a freshness problem. We only migrate what archive or compliance requires, and we say so at scoping.
The one your teams already use. The integration does not justify changing office suite. Both wire in; tokens and permissions are scoped in each ecosystem. Sheets and SharePoint are treated as cases, not as “all of Google” or “all of Microsoft”.
By storing the document id on the ERP record, and leaving the binary in Drive, SharePoint or the DMS. The ERP is not a disk. We map who may see the record to drive ACLs, and we accept the moved file, the dead link and the revoked token. The ERP page covers document types; here the point is that the reference survives time. A comment with a Drive URL is not an integration.
Reference in the file, or a copy of the binary?
30 minutes to decide Drive vs SharePoint, rights mapping and what you refuse to duplicate.
Discuss my files project