SharePoint & OneDrive to Clio: moving M365 files into matter folders

For a law firm on Microsoft 365, OneDrive and SharePoint are where most of the firm's day-to-day files live. OneDrive holds personal working storage: drafts in progress, downloads from email, the working set an attorney has open during the day. SharePoint holds shared team libraries: client folders for active matters drafted collaboratively, firm templates, knowledge base content, operational documents.

Clio is the system of record for the matter file. When a document goes final — a signed retainer, an executed agreement, a filed pleading, a closing-day deed — it belongs in the matter, not in OneDrive or SharePoint. The hand-off between "this file is in SharePoint" and "this file is in the Clio matter" is the workflow problem.

The hand-off is harder than it sounds. The two systems have different folder structures (SharePoint sites vs. Clio matters), different permission models (M365 groups vs. Clio matter access lists), different version-history semantics, and different naming conventions. Moving a file from one to the other is almost never just a copy — it's a copy plus a permission decision plus a filename decision plus, sometimes, a version-history decision.

One thing to settle first: Clio has a native OneDrive sync, but it covers only part of M365 (next section). For everything it doesn't cover — SharePoint, personal OneDrive — the four workflows below are how most firms close the gap. None of them is universally best; the right one depends on volume, what stage of drafting the file is at, and how much M365 tooling your firm already pays for.

Open OneDrive or SharePoint in the browser, navigate to the file, click Download, then upload to Clio. The same shape as Option 1 but skips the desktop sync intermediate step. Useful when you're working from a device that doesn't have your firm's M365 account synced (a borrowed laptop, the desktop in a conference room) or when sync would take longer than the round-trip browser workflow.

What it's good at. Independence from desktop sync state. The browser always shows the latest version of the file as it exists in M365 — you don't have to worry about local sync being stale. For occasional uploads from devices that aren't your primary workstation, this is the simpler path.

Where it doesn't shine. It's still a download-then-upload round-trip. Per-file cost is roughly the same as Option 1 — two minutes per document including the browser-to-browser switch and filename cleanup. For high-volume migrations or recurring patterns, the per-file overhead adds up the same way as Option 1.

Browser extensions that intercept the OneDrive or SharePoint download action and send the bytes directly to Clio's API instead. Right-click a file in the browser, pick the matter, the file lands in Clio without ever touching your local disk. Examples in this category include Send to Case and similar browser extensions; coverage of SharePoint surfaces varies by tool (some handle personal OneDrive but not team SharePoint libraries; some handle both).

What this category is good at. Mid-volume work that doesn't justify Power Automate. The single-click workflow is faster than browser download (Option 2) without the build cost of Power Automate (Option 3). Especially useful when your day mixes M365 sources with other browser-served documents — court portals, email attachments, evidence sites — because one extension covers all of them. Documents that arrive as ShareFile links from opposing counsel or clients are the same shape of problem from the receiving side.

Where it doesn't shine. SharePoint coverage is the trickiest part. M365 surfaces are notoriously varied — personal OneDrive at onedrive.live.com, business OneDrive at *-my.sharepoint.com, team SharePoint sites at *.sharepoint.com, and the configuration variants within each. A tool that works perfectly in personal OneDrive may need configuration for team SharePoint, and vice versa. Verify against your firm's specific tenancy structure before promising the tool to a partner. Browser tools also don't reach desktop apps (the Office 365 desktop client opening a SharePoint-stored file directly), so heavy desktop-Office workflows pass them by.

The permissions question is the one most firms underestimate when planning SharePoint-to-Clio workflows. M365 controls access through Azure AD groups, Microsoft 365 groups, and SharePoint site-level permissions; Clio controls access at the matter level with its own role-based system. The two are completely separate authorization layers — moving a file between them is moving it between two trust domains.

The most common gotcha. Files drafted collaboratively in a SharePoint site visible to the whole firm get uploaded to a Clio matter whose access is restricted to the partner, an associate, and a specific paralegal. After the upload, the firm-wide SharePoint copy still exists. If someone outside the matter access list opens the SharePoint version, they're seeing content the matter access list was designed to prevent. The Clio matter restriction is real; the SharePoint copy is a back-channel. Most firms don't audit for this until a partner asks "wait, who else can see this?"

The two clean patterns. Pattern A: archive the SharePoint copy as soon as the file lands in Clio. The clean break removes the back-channel; the matter is the only place the file exists. Pattern B: structure SharePoint sites to mirror the Clio matter access list — one site per matter, populated only with the same people who have Clio matter access. More overhead at site creation, fewer surprises later. Most firms run a hybrid: pattern B for sensitive matters (privileged work product, sealed proceedings, M&A target work), pattern A for everything else.

External sharing adds another layer. SharePoint can be configured to allow guest access for clients or co-counsel; Clio matter access can include client read-only roles. The two don't coordinate. If the same person needs access in both systems, you're managing two access lists — and any change has to be made twice. Most firms standardize on "Clio is the matter-collaboration surface for external parties; SharePoint stays internal." That avoids the double-bookkeeping but limits SharePoint's usefulness for outside collaboration. There isn't a clean answer; the right balance depends on whether your matters typically involve outside parties as document collaborators.

Time to first file uploaded. Sync-based and browser-based are instant — your existing M365 access plus the existing Clio web UI is all you need. Browser tools add a 5-15 minute install and authorize. Power Automate is half a day to a day for the first flow that handles your specific folder-to-matter mapping logic.

Cost per file uploaded. Sync + upload and browser download both run about two minutes per file. Browser tools cut that to closer to 30 seconds if the routing is configured. Power Automate, once running, is effectively zero per file — the cost is in the rare cases where matter mapping fails and the file needs human triage.

Permissions discipline. All four options share the same permission gotcha: the file moves between two independent access-control systems. The SharePoint version is governed by M365 groups; the Clio version is governed by matter access. Decide which group should see the file in Clio before uploading, not after. For sensitive matters, the cleanest workflow is "draft in SharePoint where the team can collaborate, file final to Clio with the matter-specific access list applied, and archive the SharePoint copy once final" — that way no working draft sits in a higher-access location than the final document.

What firms actually do. Most firms use sync + upload as the default for ad-hoc moves and add either browser tools or Power Automate for the high-volume slice. The choice between the two usually comes down to how predictable the patterns are: if you can write a sentence like "every file added to this SharePoint library belongs in matter X," you're a Power Automate candidate. If every file is a different decision a human needs to make, a browser tool is the better fit.