Strkr connects to Google Drive, OneDrive, Dropbox, and Box so every proposal, SOW, signed PDF, and kickoff deck lands on the deal and the account. The CRM is the index, the storage provider holds the bytes, and the rep never guesses where the file went.
File storage is the silent killer of CRM hygiene. Reps attach a proposal to a one-off email, a contract gets dragged to someone's desktop, a kickoff deck lives in a Slack thread, and the renewal rep a year later cannot find any of it. Buyers come looking for a CRM file integration when the mess reaches a specific pain level, and the pain is almost always one of these shapes. The order below is roughly the order these come up on a discovery call, with the renewals problem showing up late and loud.
One rep saves the signed contract to their personal Google Drive. Another stashes the SOW in a Dropbox folder nobody else can see. A third keeps everything on their laptop. When the account manager inherits the relationship, the discovery mission takes a full week and still misses a pricing addendum. Strkr pins the storage location to the record so there is one place for every file on every deal, in a provider the whole team can read.
A rep emails a proposal PDF, the buyer asks for a revision, the rep updates the file in their drive, and the deal now has two versions floating in email history with no clue which is current. Strkr links to the live file in Google Drive, OneDrive, Dropbox, or Box so the deal always points at the current revision, not a frozen snapshot that was already outdated when it was sent.
Either a rep over-shares a drive folder and the sensitive pricing addendum is visible to anyone with the link, or the finance team cannot open the signed contract because the drive permissions never got updated. Strkr pushes access decisions through the provider's native permissions, scoped by workspace role and team membership, so sharing is deliberate rather than accidental.
There are four files named 'SOW-FINAL.docx' and three of them are drafts. The signed version exists but nobody is sure which. Native file platforms track version history; Strkr surfaces that history on the deal so the current version is obvious and the trail of edits is one click away. The signed artifact is tagged on the record so there is no ambiguity about which revision closed the deal.
A well-meaning drive cleanup moves last quarter's proposals to the trash. The CRM now shows broken links for every closed deal in Q2. Strkr handles deletion events from the file provider, flags the broken link on the deal, and keeps a soft-reference to the file's metadata so the record still shows what used to be there. Nothing silently disappears.
Twelve months after the deal closed, the renewal lands with a different rep. The buyer asks about a specific clause and the renewal rep spends two days hunting through drives, inboxes, and chat threads. If the signed PDF had been attached to the account record from day one, the clause would have been a two-click lookup. Files on the account surface are the single highest-leverage fix in a CRM file strategy.
Strkr covers the four file storage providers that enterprise and mid-market B2B teams actually use. Each one connects through its native OAuth, each one keeps the bytes on the provider side, and each one lets Strkr pin a file reference to a deal, an account, or a contact. The split roughly tracks what the team already pays for: Google Drive if the office runs on Workspace, OneDrive if it runs on Microsoft 365, Dropbox for creative-heavy workflows, and Box for regulated or legal-heavy accounts. The CRM experience is the same across all four.
The deal is more than a dollar figure and a stage. It is a trail of artifacts: the discovery doc, the proposal, the pricing addendum, the countersigned MSA, the kickoff deck, the implementation plan. If any of those live outside the CRM, the record is incomplete, and incomplete records lead to slow renewals, cold handoffs, and lost context. The sections below walk through why the files-on-the-record pattern pays off, how Strkr wires each provider in, and the operational realities of running a file-strategy inside a multi-tenant CRM.
When a deal transitions from sales to account management, the new owner needs the full history: what was pitched, what was signed, what was agreed in the kickoff. If every artifact is already pinned to the record, the handoff is a ten-minute read instead of a two-day scavenger hunt. The relationship starts informed rather than catching up.
Renewals go sideways when the renewal rep cannot find the original terms. Strkr pins the signed contract to the account, not just to the closed deal that produced it, so when a renewal opens on the same account the current terms are already surfaced. The quote is based on reality rather than guesswork.
When finance needs the signed order form for an audit, or legal needs the executed MSA for a dispute, the record is the first place to look. Strkr's file links are permissioned, timestamped, and tied to the user who attached them. The audit log says who added what, when, and under which account.
Every one of these providers runs a content index. Searching for a phrase inside a PDF returns results from the provider; Strkr surfaces those results linked back to the account or deal where the file is attached. A search for a specific clause can jump directly to the deal that negotiated it.
When a rep attaches the signed proposal to the deal, the attach event lands on the timeline. The manager pulling up the deal sees the chronology: proposal attached Tuesday, countersigned MSA attached Thursday, kickoff deck attached the following Monday. Nothing goes missing between stages.
Google Drive, OneDrive, Dropbox, and Box each carry their own compliance certifications: SOC 2, ISO 27001, HIPAA where applicable, and regional data residency controls. Strkr does not duplicate that work; it integrates with the posture the file provider already carries, so the storage decision does not change your audit scope.
Each of the four file integrations ships under a per-tenant OAuth, scoped to the workspace rather than the individual rep. The admin connects it once, every rep inside Strkr can read and attach, and no rep has to connect their own personal account. The provider holds the bytes, Strkr holds the reference, and both sides stay in sync when a file moves, renames, or gets revised.
Google Drive is the obvious fit for teams already running Google Workspace. Strkr's integration connects to a shared workspace drive, respects the native sharing rules, and resolves file references through the Drive API. The rep attaches a file by picker and the deal gets a live link; opening it hits Drive with the rep's own credentials under the provider's SSO.
OneDrive and SharePoint cover teams on Microsoft 365. Strkr's integration connects through the Microsoft Graph API, scoped to the tenant, and respects SharePoint site permissions. The rep attaches from a shared library or a personal OneDrive; the deal pins the file reference and resolves it through Graph on open.
Dropbox tends to win where the deal artifacts include creative assets, large video files, or shared pitch decks that need preview polish. Strkr's Dropbox integration pins team-folder files to the deal and surfaces Dropbox's preview rendering inline on the record. Delta sync means the file reference stays stable even when the underlying file is renamed or moved inside the Dropbox tree.
Box earns its keep in regulated industries: healthcare, financial services, legal, government. Granular folder-level permissions, retention policies, and legal hold are all first-class in Box. Strkr's integration respects the Box permission model when it resolves a file reference, so a rep without read access to a legal folder never sees a thumbnail they should not see.
All four integrations run under a tenant-scoped OAuth. One admin connects the integration under Admin > Integrations, picks the scope (specific team drives, shared libraries, or the whole workspace), and every rep gets the ability to attach from the picker. No per-rep connection required; no login prompt on every attach.
Regardless of which provider is connected, the attach experience on a Strkr record is the same: a file picker, a search box, a recent-files list, and a pinned-folders list. The reps who switch between accounts that live on different storage providers do not have to learn a new UI; the differences are plumbing on the admin side, not surface on the rep side.
Not every file wants the same treatment. Some artifacts should live as live links back to the source provider so edits propagate. Others should be snapshotted at a moment in time so the record is frozen. Strkr supports both patterns and lets the admin pick the default for each file type. The decision is less about the technology and more about what the file means on the record.
Proposals being iterated, kickoff decks being refined, SOWs still in negotiation: these artifacts want to stay linked. When the deal reference opens, it opens the current version from the provider. Reps and buyers see the same thing at the same time. No stale copies.
Once a contract is countersigned, the deal does not want the live link anymore. Strkr snapshots the countersigned PDF at the moment of signing and stores an immutable copy against the deal and the account. If someone later renames or deletes the source file, the record still holds the version that was legally binding.
Each provider carries a native version history. Strkr surfaces that history on the deal attachment so the version trail is visible from the record. The rep does not have to pivot to the file provider to see 'what changed between v3 and v4'. The audit trail stays on the surface where the question gets asked.
When a file is deleted at the provider, Strkr receives the event and flags the deal attachment with a deletion marker. The record still shows the filename, who attached it, when, and when it was deleted. The link resolves to a 'file no longer available' state rather than a broken link. Nothing disappears quietly.
The providers all expose stable file IDs under the hood. Strkr pins by that ID, not by path, so a rep who reorganizes a shared folder does not break every CRM reference. The link follows the file; the file does not have to stay in one place.
The admin configures the sync vs link default per file type: countersigned PDFs snapshot, proposals link, SOWs link until signed and then snapshot, kickoff decks always link. The policy is set once at the workspace level and every rep inherits it. No rep decision required on every attach.
File integrations go sideways when the CRM tries to invent its own permission layer on top of the provider's. Strkr does not do that. The CRM-side permissions decide who sees the attachment on the deal; the provider-side permissions decide who can open the actual file. Both layers have to say yes. The result is deliberate access control that does not silently over-share or silently lock out the people who need to see.
Seeing a file on a deal in Strkr requires both the right CRM permissions and the right provider-side ACL. If a rep can see the deal in Strkr but cannot see the file in Google Drive, they see the attachment card with a 'request access' prompt rather than silently resolving a file they should not read.
Strkr workspace roles map onto the provider's native groups when the integration is set up. A member of the Enterprise AE team inherits read access to the Enterprise AE shared drive. A member of Legal inherits read access to the Legal library. The sharing decision is deliberate, not accidental.
Box and OneDrive both support retention policies and legal hold at the folder level. When a deal attachment points at a file under retention, Strkr respects that: the attachment cannot be deleted from the CRM record while the provider holds the file under legal hold. The CRM is not the authority on compliance; the provider is.
Strkr's audit log captures every file attach, every open, every share-change on a deal attachment. The provider's audit log captures the same events on the file side. The two together give finance, legal, and security a complete trace of who touched what, when, and under which account.
Google Drive, OneDrive, Dropbox, and Box all offer regional data residency controls. If the account requires EU-only storage, the admin configures that at the provider level and Strkr respects it. The CRM does not try to duplicate region-specific storage; the file bytes stay with the provider under the provider's residency commitments.
Not every rep should see every attachment on every deal. A pricing addendum might be visible only to RevOps and the deal owner. Strkr's field-level visibility lets the admin tag specific attachment slots as role-restricted; the deal is still visible, the attachment card is still rendered, but the open action is gated.
File integrations fail more often on folder hygiene than on OAuth. The connection is a one-afternoon admin job. The folder structure, the sharing conventions, and the retention rules are the real work and the real risk. Here is the honest operational picture so a rollout can hit the ground running rather than scrambling in the second week over conventions nobody ever wrote down.
If the shared Drive, OneDrive, Dropbox, or Box tree is five years of ad-hoc folders, the integration will inherit that mess. Spend the week before go-live standardizing folder names, retiring stale shares, and documenting the convention for where new files belong. The best-case outcome is a short, curated top-level structure that reps can actually navigate.
A workspace admin connects the integration once. All four providers authenticate via OAuth 2.0, scoped to the tenant. The admin picks which drives, libraries, or team folders Strkr is allowed to see. No per-rep connection is required; every rep inherits the shared visibility under their own Strkr identity.
The attach picker on a Strkr record can be scoped to specific folders rather than the entire drive. For a sales workspace, that often means pinning the Proposals folder, the Contracts folder, and the Kickoff Decks folder. Reps browse the folders they actually use; they are not confronted with the entire company drive on every attach.
The one-time setup wires Strkr workspace roles to the provider's native groups. Enterprise AEs get the Enterprise shared drive. SMB AEs get the SMB shared drive. Legal gets the Legal library. This mapping is reviewed as teams grow, but the base map is a one-afternoon job at setup.
Running the integration against one sales segment for two weeks surfaces folder-structure gaps that nobody noticed in setup. Expand to the whole workspace once the first segment has used it on real deals through close. Rolling the whole org on day one usually produces a scramble around who-can-see-what edge cases that a pilot would have caught cheaply.
The team that implements this well puts RevOps in charge of the folder convention and the Strkr integration mapping, while IT owns the underlying file provider setup. Two roles with clear scope. RevOps knows what reps need to find; IT knows how to make it technically work. A single-owner model where IT guesses at the sales convention always drifts.
The admin picks what happens when a file is deleted at the provider. Default is a soft-flag on the deal attachment showing the file is no longer available. Some teams prefer a hard-remove, which clears the attachment card entirely once the provider confirms deletion. Both are supported; the policy ships workspace-wide, not per rep.
The real indicator of success is the share of closed deals that have the signed artifact actually attached. If the attach rate is below 90% after a month, something in the convention is still broken. Strkr surfaces attach rate on the pipeline reports so the admin can see whether reps are actually using the integration or still emailing attachments around.
Strkr does not try to be Google Drive. It does not try to be Box. It does not store bytes, it does not run a file preview engine, and it does not offer native collaborative editing. All four of those are solved problems with dedicated providers who have been iterating on them for a decade. Strkr's job is to make those providers feel native inside the CRM, not to replace them. This section exists so the planning stays honest and nothing gets procured expecting a capability that is not shipping.
Strkr does not store raw file bytes outside of small deal thumbnails and metadata. The file lives in Google Drive, OneDrive, Dropbox, or Box. The CRM holds a reference and a snapshot where the policy says so. If the provider goes away, the file goes with it; the CRM is not a backup target.
Collaborative editing is a hard problem that Google Docs, Word Online, and Dropbox Paper have each spent a decade on. Strkr does not try to compete with that. The attach-and-link pattern means a rep opens the file in the native tool, edits there, and the CRM reference stays current.
The CRM does not convert .docx to .pdf, does not render presentations to video, and does not try to be a file conversion engine. If a conversion is needed, it happens in the provider, in a dedicated tool, or on a workflow outside the CRM. Strkr pins whatever file the rep attached.
Google Drive, OneDrive, Dropbox, and Box each ship their own desktop and mobile clients. Strkr does not duplicate that work. The CRM experience is browser-first, with references into the provider's clients for the actual file access. Offline file access is the provider's problem to solve.
File storage is not the same as e-signature. Strkr integrates with DocuSign and PandaDoc for the signature workflow; the resulting signed PDF is then stored in whichever file provider the workspace uses, and the deal references it. Treating the file storage integration as a signature workflow is a scope error that bites in production.
Proposal authoring lives in PandaDoc, Google Docs, Word, or whichever authoring tool the sales team already uses. Strkr pins the resulting file to the deal and tracks it through to signed. Expecting the CRM to be a proposal builder is the wrong altitude; the CRM is the record, not the drafting surface.
Connect Google Drive, OneDrive, Dropbox, or Box so proposals and signed contracts live on the deal, the version history is one click away, and the renewal rep twelve months from now opens the account and finds the current terms without a two-day search. The CRM becomes the index for every artifact on every account.
Four: Google Drive, Microsoft OneDrive (including SharePoint libraries), Dropbox, and Box. Each one connects via per-tenant OAuth, each one keeps the file bytes on the provider side, and each one lets Strkr pin a file reference to a deal, an account, or a contact. The CRM experience is the same across all four providers; the differences are plumbing on the admin side.
Strkr stores small metadata and thumbnails for display, plus a snapshot of signed artifacts where the policy requires it (countersigned contracts, for example, which snapshot at the moment of signing to protect the audit trail). The underlying file bytes stay with the provider you connected. The CRM is a reference layer, not a storage product.
Strkr receives the deletion event and flags the deal attachment with a deletion marker. The record still shows the filename, who attached it, and when, so the audit trail stays intact. The link resolves to a 'file no longer available' state rather than a silent broken link. The admin can also configure a hard-remove policy if the workspace prefers that behavior.
Yes. A signed MSA, for example, typically gets attached to the deal that closed it and to the parent account record. Both references point at the same underlying file at the provider, so edits propagate (for linked files) and the version history is shared. The attach event lives on each record's timeline independently.
Yes. Strkr respects the provider-side ACL on every file resolution. If a rep can see the deal in Strkr but cannot see the file at the provider, the attachment card renders with a 'request access' prompt rather than silently resolving a file they should not read. The CRM does not override the provider's permission model.
The CRM-side plumbing for file attachments, timeline events, and version-history surfacing is in place. The per-provider OAuth plumbing for Google Drive, OneDrive, Dropbox, and Box is in active work and the status of each is tracked on the dedicated integration page for that provider. Current release status is visible from the integrations index.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
