The ecosystem

Clio integrations: how they actually attach

Firms shop for integrations by name — an accounting sync, an inbox connector, an e-signature tool — and end up surprised by how differently each one behaves once it's connected. The reason is that three unrelated things all get called an integration: a feature Clio builds and supports itself, a third-party listing in the Clio App Directory, and a custom connection somebody wired through Clio's API or a general automation platform. This guide separates those three, walks the categories most firms actually shop in, and sets out the questions worth asking before you connect anything to a system that holds client files. Product details change, so confirm current specifics in Clio's help center and in each vendor's own documentation.

By Lucas Barnes, Founder · Last updated October 7, 2026

Start with the category error

Three different things get called an integration

The word covers three arrangements with almost nothing in common except the outcome. Some connections are features Clio built into Clio Manage and supports itself. Some are third-party products listed in the Clio App Directory that talk to Clio through its API. And some are one-off bridges a firm builds with a general automation platform or by writing against the API directly. A firm evaluating "Clio integrations" as a single category will compare a supported native feature against a two-person startup's app against something their IT consultant wired together on a Friday. Then it's genuinely puzzling when the three behave differently.

The distinction isn't academic. It determines who you call when the connection stops working, whose release schedule can break it, whether it costs a second subscription, and how much of your client data the other party can reach. Those four answers are what you're actually choosing between — the feature list is the easy part.

This page is a map rather than a ranking. It's deliberately not a list of the best apps, because the directory changes, vendors get acquired, and the right answer depends far more on how your firm works than on any app's feature grid. Confirm current behavior in Clio's help center and in each vendor's own documentation before you build a workflow on it.

Attachment points

Where the connection actually lives

Native feature

Built into Clio Manage and supported by Clio. Turned on in settings rather than installed. One vendor, one bill, one support queue — and it moves when Clio's roadmap moves, not when you want it to.

App Directory listing

A separate company's product, authorized against your Clio account through Clio's API. Their code, their updates, their pricing, their support. Listing means it connects — not that Clio operates it for you. See one concrete example of a listing.

API or automation platform

A bridge your firm builds — a Power Automate or Zapier rule, or custom code against Clio's API. Maximum fit, and you own it entirely, including the day the person who built it leaves.

The authorization model is the same in the second and third cases, and it's worth understanding once. Integrations built on Clio's API connect through OAuth: you approve the connection from inside Clio and the app gets a token it can use on your behalf, which you can revoke later without changing your password. That's the correct shape, and its corollary is a hard rule — any tool that asks you to type your Clio username and password into its own screen should be disqualified on the spot. However good the demo was.

Native features generally need a firm administrator to enable them, and several are plan-dependent, which is the quiet reason two firms describe the same product differently. Before a rollout, confirm both the plan requirement and who in your firm has the rights to turn it on. Discovering mid-project that the connection needs an admin who's on vacation is an avoidable delay.

By category

The seven categories firms actually shop in

Almost every integration conversation in a law firm falls into one of seven buckets. Each one below gets the same three questions: what the bucket is for, which end of it Clio already covers natively, and where the remaining gap usually sits.

Email and inbox

Usually the busiest category, because most documents arrive as attachments. Clio publishes add-ins for both dominant clients — Clio for Outlook and Clio for Gmail — which file an email and its attachments to a matter from inside the mail client. The add-in is an envelope tool. It's designed to file the correspondence, and the attachment rides along inside it.

That makes the mechanics worth checking per client rather than assuming. Whether attachments file separately or only as part of the envelope has varied by Outlook version, and the filename the attachment arrives under is whatever the sender chose. The per-client detail is in Outlook attachments and Gmail attachments; confirm the current behavior in the App Directory listing for your client before standardizing a firm workflow on it. On the Outlook side that check starts earlier than most firms expect, because installation, the account-scoping quirk that hides the button on half your mail, and the mailbox types it will never appear on together decide whether the option exists for your firm at all — a mailbox on an on-premises Exchange server is documented as out of scope, and no amount of reinstalling changes that.

Cloud storage and document sources

Clio Manage connects a fixed short list of cloud stores natively as document sources — Dropbox, Box, Google Drive, NetDocuments, and OneDrive for Business — so files kept there surface in the matter without a separate upload. The category trap is that "supported" is narrower than the provider's name suggests, and the exclusions are provider-specific rather than a single rule. The Dropbox and Google Drive sources connect one ordinary account and don't cover shared or team drives; the Microsoft source is OneDrive for Business only; SharePoint libraries aren't a Clio Manage document source at all. Check the exclusion list for your provider, not the logo. Account type isn't the only gate on the Microsoft side either — a tenant configured to require administrator consent before anyone authorizes a third-party app is a common reason why a Microsoft connection refuses to complete even when the account type is right and the person clicking has Clio administrator rights.

Per-provider detail, including setup paths and the folder-structure rules that bite: Dropbox, Google Drive, OneDrive and SharePoint, NetDocuments, and — for a store that has no native source — ShareFile. Worth separating from all of these is Clio Drive, which isn't an integration with an outside store at all. It's Clio's own desktop client mounting Clio's storage.

Accounting and billing

Here the native-versus-third-party question gets decided before the connector question. Clio Manage handles time, billing, and trust accounting itself, and Clio sells a built-in accounting product on its higher tiers; the integration only arises if the firm keeps a general ledger elsewhere. Where it does, QuickBooks Online and Xero are the two names that come up. Further accounting products appear in the App Directory. A firm sitting on a legal-specific ledger is answering a different question entirely: PCLaw, Tabs3, and CosmoLex hold documents alongside the numbers, so coming off one of them isn't a connector decision at all. It's a document move, and the ledger is only half of what has to travel.

It's also the category where the setup decisions are hardest to reverse — how accounts map, what level of detail syncs, whether trust activity flows at all. Involve whoever actually does your bookkeeping in the configuration rather than handing them the result. And confirm current supported editions, sync direction, and setup steps in Clio's help center, because accounting connectors change on both vendors' schedules.

CRM and client intake

Intake is a different job from matter management. That's why it's a separate product almost everywhere — including inside Clio, where the intake product (Clio Grow) is a separate subscription rather than a feature of Clio Manage. The FAQ below covers the three connection shapes. The thing to settle first is which system owns the client record, because whichever one captures the lead should be the source of truth and two systems that both think they own the contact will drift.

The category-specific trap is that intake integrations are built to move fields — name, matter type, referral source. Firms discover late that the intake conversation also produced documents nobody routed anywhere. Practice areas with document-heavy intake, immigration being the clearest case, need the document-collection workflow solved alongside the CRM question rather than after it. It's also the argument for a practice-area intake product rather than a general CRM where one exists for your area: when the forms and the file collection are the same conversation, splitting them across two systems is precisely what leaves the documents behind.

E-signature

The category where native and third-party most often run side by side rather than one replacing the other. Clio's built-in option — Clio e-Signature, powered by Dropbox Sign — sends from the matter and is designed to return the executed copy to it. What it carries is a monthly signature cap on the lower plans, which is the usual reason a firm adds something else. The App Directory also carries an active "Sign with DocuSign" integration, which works against the firm's own DocuSign account. That's a second subscription, not an add-on.

The document-management test for any signing tool is the same regardless of which you pick: does the executed copy end up in the matter without someone remembering to put it there. The e-signature guide covers the round trip and the current per-plan limits, and DocuSign to Clio covers the paths for closing that gap when signing happens elsewhere.

Courts and e-filing

The only category where the answer depends on your address. Both shapes exist: Clio File as native e-filing inside Clio Manage, InfoTrack File & Serve as an App Directory integration. But the native route covers Texas, California (excluding San Francisco), and Georgia only, so the same question gets a different answer in two neighboring states. Confirm coverage for your jurisdiction before planning around it; the court documents guide has the comparison in full.

Filing is also only half the traffic. Everything you receive — opposing filings, orders, notices, stamped copies you download — arrives through a portal that has no integration model at all, and makes the trip into the matter by hand. That long tail is covered by portal: PACER and CM/ECF, Tyler Odyssey and File & Serve, and state court systems generally.

Tasks, projects, and everything else

This is the residual bucket. It's where the third attachment type — the automation-platform bridge — does most of its work, because the tools in it are general-purpose products with no reason to build a legal-specific connector. Clio has its own tasks and calendar, so board tools like Trello and Asana usually sit alongside it rather than inside it, and a Zapier or Power Automate rule is the usual seam. Whether any specific tool has its own directory listing changes over time; check the App Directory rather than trusting a secondhand list.

Bridges built here are the ones most likely to become orphaned. They're configured by one person, documented nowhere, and dependent on a platform subscription somebody else renews. Write down what the rule does and who owns it on the day you build it, not the day it breaks.

One arrangement gets shopped as an integration and isn't one: the practice-management system you're leaving. That's the fourth confusion, and it's the costliest, because a connector implies two systems running side by side indefinitely and a firm coming off MyCase, Filevine, Smokeball, PracticePanther, Rocket Matter, or LEAP wants the opposite. A one-way trip with an end date, after which the old subscription gets cancelled and nobody logs in again. Nothing about a standing connection's rules — who owns it, what breaks it, what survives disconnection — applies to the shape of the move.

And once a firm accepts that it's planning a migration rather than a connection, the next question arrives immediately: which records actually travel. What the outgoing vendor's export contains, what happens to version history, and what has to be re-created by hand on the other side are where a migration is won or lost — and none of them are visible from a feature comparison.

If you want names

Eight integrations worth setting up

The map above is deliberately not a ranking. If you'd rather start from a shortlist, this video picks one integration for each job most firms still do by hand: what it does inside Clio, who it fits, and one limitation worth knowing. It also names the four jobs where Clio's own product already does the work. Prices and sources are in the video's description on YouTube, with the date they were checked.

Due diligence

What to check before you connect anything

The general vendor-security questions — how it authenticates, where files travel, what's retained, which agreements exist — are the same for any outside tool touching client documents, and they have their own checklist. The shorter list below only applies because this is a standing connection rather than a one-time transfer.

ASK BEFORE CONNECTING

Which Clio records does it read, and which does it write? Read-only and read-write are different risks.
Is it one firm-wide connection, or does every user authorize their own? That changes onboarding and offboarding.
Who administers the connection, and who can revoke it if that person leaves?
What survives disconnection, and what disappears from the matter view?
Is it plan-gated on either side, and what does the second subscription cost per seat?
What's the fallback workflow for the week it's down, and can the team actually run it?

RECONSIDER IF

Nobody can name who would own the connection once it's live.
The vendor can't describe what the matter looks like after you disconnect.
It only pays off if every user adopts it, and you already know two won't.
It duplicates a record Clio already holds instead of feeding the one that exists.
The only evidence it works is a demo on a clean, tidy example file.

Test against your messy cases, not the demo. Every vendor's walkthrough uses a well-named PDF from a cooperative source. Your firm's actual inflow is a scanned exhibit with no text layer, a production from an evidence portal behind an expiring link, and an attachment whose filename is a camera timestamp. Run those through the integration during evaluation, on a matter that doesn't matter, before anyone depends on it.

And budget the whole cost. The subscription is usually the smallest line: the real spend is configuration time, the training hours to get a team using it consistently, and the ongoing tax of an extra system to keep signed in and up to date. An integration used by two of five paralegals is worse than none, because now the matter file is half-populated by one route and half by another.

The honest limits

What integrations don't cover

Integrations connect systems that both want to be connected. That covers a real share of a firm's document flow — email, the supported cloud stores, accounting, signing, e-filing in covered jurisdictions. It doesn't cover the long tail, and the long tail is where paralegal hours actually go: a county portal with no API, opposing counsel's one-off share link, an insurance carrier's download page, an evidence portal whose link expires in seventy-two hours, a file living in a cloud store Clio doesn't accept as a document source. No amount of shopping in the directory closes that gap. There's no counterparty on the other side to build against. Two shapes recur often enough to deserve a decided workflow rather than a connector search: an evidence platform's expiring links, and an incoming production set from opposing counsel. Both are high enough volume that how they get handled is worth settling once, in writing, rather than per matter.

The second limit is directional. Many connections are designed to bring a system's records into Clio on that system's terms, which isn't the same as putting a specific document in a specific matter folder with a name your firm can read six months later. A synced source that surfaces a provider's folder tree inside the matter has solved visibility, not organization — and the naming and folder conventions covered in the document management guide still have to be applied by someone. Underneath the directional question sits one no connector answers: which venue the client file should live in at all, and what holding it there obligates. An integration decides how records move between two systems. It doesn't decide which of them is the custodian.

None of this is an argument against integrations. It's an argument for sizing them honestly: connect the flows that repeat, accept that the irregular ones stay manual, and be deliberate about which tool handles the manual remainder rather than letting it default to whatever each person happens to do.

Putting it together

Build the stack around the matter, not the app list

The useful test for any integration is whether the matter file gets more complete or just more automated. A connection that files correspondence into the matter earns its place. A connection that creates a second copy of the client record somewhere else doesn't, however elegant the sync. Start from what a colleague picking up the matter cold needs to find, and add integrations that make that likelier — in that order, not the reverse.

A workable sequence for most firms: turn on the native pieces first, because they cost nothing extra and have one support queue; add a directory app only where a native gap is costing measurable hours; and reach for an automation platform last, when the pattern is repetitive enough that a rule will hold. Re-check the arrangement once a year. Plans, listings, and vendors all move.

Whatever the stack looks like, the last mile is usually still a person moving a file from a portal or an inbox into the right matter. Options there run from Clio's own web uploader — which takes multiple files and whole folders — and its desktop app, through to browser extensions such as Send to Case, weighed side by side in the tools for uploading guide. Pick that one as deliberately as the rest, because it's the part of the stack that carries whatever the integrations don't.

Clio integrations FAQ

Got more? Email [email protected].

Q.01

What is the Clio App Directory?

The App Directory is Clio's marketplace of third-party applications that connect to Clio Manage. Each listing describes what the app does, what it syncs, and how to enable it, and enabling one generally means authorizing the app against your Clio account so it can read or write the specific records it needs. What matters is that a directory listing isn't the same as a Clio-built feature: the third party writes the app, ships its updates, sets its pricing, and answers its support tickets. Clio provides the platform and the listing. Which apps are listed changes over time as vendors come and go, so check the directory itself rather than a blog post before you plan a workflow around a specific app.

Q.02

What is the difference between a native Clio feature and an App Directory integration?

A native feature is built into Clio Manage and supported by Clio — the connected document sources, the email add-ins, the built-in e-signature, and native e-filing are examples. An App Directory integration is a separate product from a separate company that talks to Clio through Clio's API. The practical differences show up when something breaks or changes: with a native feature you have one vendor, one support queue, and one bill, and the feature moves when Clio's release schedule moves. With a third-party app you have two vendors who can each ship a change that breaks the other, two support queues, and usually a second subscription. Neither is better in the abstract. But the ownership question is worth answering before rollout rather than during an outage.

Q.03

Does Clio integrate with QuickBooks?

Yes. Clio Manage integrates with QuickBooks Online for firms that keep their general ledger outside Clio, and Xero is the other commonly paired option. Worth knowing before you shop: Clio also sells its own built-in accounting product on its higher tiers, so the first question is whether you need an external ledger at all rather than which connector to pick. The point of any of these connections is that billing records don't get re-keyed by hand into a second system. Which records sync, in which direction, and which editions are supported all change over time, so confirm the current details in Clio's help center before planning a month-end close around it — and involve whoever actually does your bookkeeping in the setup, because the mapping decisions made on day one are painful to unwind later.

Q.04

Does Clio have a Gmail integration?

Yes. Clio publishes add-ins for both of the dominant email clients — Clio for Gmail and Clio for Outlook — that let you file an email, and its attachments, to a matter from inside the mail client. They're the right tool when the email envelope itself is the record you need: the headers, the body, the timestamp, and the signature block preserved alongside the file. They're a heavier tool when all you actually want is a clean copy of the attachment as a matter document, because the email context comes along for the ride. Firms with heavy inbound email often end up splitting those two jobs: the add-in when the correspondence itself is the record, a simpler save-the-attachment route when only the file matters.

Q.05

Can I connect Clio to Trello or another task board?

Sometimes, but usually not through a dedicated first-party connector. Clio has its own tasks and calendar, so board tools like Trello and Asana tend to sit alongside Clio rather than inside it, and the usual bridge is a general automation platform such as Zapier or Microsoft Power Automate — you build a rule that creates a card when a matter opens, or creates a Clio task when a card moves. Whether a given board tool has its own App Directory listing changes over time, so check the directory before assuming either way. Before building the bridge, ask whether the board is genuinely doing work Clio's own task features can't, because two task systems that disagree is worse than one that's merely adequate.

Q.06

How do CRM and intake tools connect to Clio?

Three ways, and firms often mix them. Clio's own intake and client-relationship product is Clio Grow, which pairs with Clio Manage but is a separate subscription with its own setup fee and its own form configuration — budget it as a second product, not a feature toggle. Third-party intake and CRM products connect through the App Directory using Clio's API, typically pushing a contact and a matter into Clio once a lead converts. And some firms build a lighter path with an automation platform, turning a web form submission into a Clio contact. The question that decides between them isn't features. It's where the client record is born: whichever system captures the lead first should own the intake data, with the others reading from it rather than maintaining a competing copy.

Q.07

Does connecting an integration give the vendor access to all our client data?

Not necessarily, and this is the question to actually ask rather than assume. Integrations built on Clio's API authorize through OAuth, which means you approve the connection inside Clio and the app receives a revocable token rather than your password — no reputable integration should ever ask for your Clio login credentials. What that token can reach depends on what the app requests and what Clio grants it, so read the authorization screen instead of clicking through it, and ask the vendor plainly what they store on their own servers versus what they only pass through. For anything that touches client documents, treat the vendor review as seriously as you would a cloud storage provider. Functionally that's what it is.

Q.08

What happens to our data if we disconnect an integration?

It depends entirely on which direction the data was flowing, which is why it's worth knowing before you connect. Records the integration copied into Clio — a filed email, an uploaded document, a synced invoice — are Clio records now and generally stay after the connection is removed. Records that only lived in the other system, or that Clio was displaying by reference rather than storing, can disappear from view when the link is cut; connected cloud storage is the classic example, because the matter was showing you someone else's files. Ask the vendor the disconnect question during evaluation, and if the answer is vague, run a small test connection on a throwaway matter and disconnect it before you commit the firm.

Related guides