There's a structure that keeps showing up in modern legal practice: a network of independent lawyers, each running their own files, sharing a common brand and a common tech stack, but never sharing client data. Think four to fifteen solo practitioners under one banner, each on the same practice-management platform, each siloed by design.
That structure breaks most automation advice. The standard answer to "automate across the firm" is to build a central platform that indexes everyone's matters. For an independent network that's exactly wrong. You cannot pool privileged files into one searchable index without creating the cross-contamination the silo was built to prevent.
So how do you route incoming matters to the right lawyer, and run a real conflict check across the whole network, without ever merging the data? The pattern is per-user isolation. We learned the shape of it the hard way, building open-source Clio and MyCase MCP connectors and hitting every API edge in the process. This is the recipe, plus the traps that cost us real time.
What does per-user isolation actually mean?
Per-user isolation means every lawyer keeps their own practice-management instance, their own OAuth credential, and their own local automation. Nothing about the architecture assumes a shared database. When you need a network-wide answer, you fan out to each lawyer's data under that lawyer's own token, compute the answer in memory, and return only the minimum result. No persistent central copy of anyone's matters.
Contrast the two designs:
Central platform vs. per-user isolation
| Question | Central platform | Per-user isolation |
|---|---|---|
| Where data lives | Pooled central index | Each lawyer's own instance |
| Conflict check input | Query one shared DB | Fan out per token, in memory |
| What gets returned | Full matching records | Yes/no + responsible lawyer only |
| Failure blast radius | Whole network exposed | One lawyer at most |
| Right for | One firm, shared matters | Independent lawyers, siloed files |
If the lawyers in your network genuinely share matters and supervise each other, a central platform may be correct, and the audit trail it produces is a feature. If they're independent practitioners who only share a brand, per-user isolation is the honest match. Pick based on the relationship, not on what's easier to build.
The recipe, step by step
Step 1: One credential per lawyer, never a shared login
Clio Manage and MyCase both use OAuth 2.0. Each lawyer authorizes the automation against their own account and gets their own token. Store those tokens encrypted at rest. In our connectors we use AES-256-GCM local token storage so the credential never sits in plaintext on disk. The practical effect: a compromised install leaks one lawyer's session, not the network's.
This is also where you decide local versus hosted. For a small network, a packaged local agent per lawyer is usually right. Each agent runs on the lawyer's machine and holds only that lawyer's token. You don't need a server to coordinate them.
Step 2: Route the incoming matter
Routing is the easy half. A new inquiry comes in, you classify it (practice area, jurisdiction, language, availability) and decide which lawyer owns it. The decision can be a simple rule table or an LLM call over the intake text. Either way, routing reads metadata, not privileged file contents, so it carries low risk.
The one piece of glue worth nailing in a pilot is matching an inbound event to the right matter or lawyer. A topic-naming convention, an intake-form field, or a one-line "which lawyer?" confirmation step all work. Don't over-engineer it. A confirm step that a human approves is faster to ship and easier to trust than a clever classifier that's right 92% of the time.
Step 3: Run the conflict check without pooling data
This is the part that makes people reach for a central database. Resist it. A network-wide conflict check under per-user isolation looks like this:
- A new party name (and related parties) arrives with the inquiry.
- The coordinator queries each lawyer's contacts and matters under that lawyer's own token, one at a time.
- Matches are computed in memory. The party name is normalized (case, punctuation, common entity suffixes) so "Smith Holdings" and "Smith Holdings, Inc." collide on purpose.
- The result returned to the intake desk is a flag plus the responsible lawyer's name, not the underlying matter records.
The contact and matter list endpoints in Clio Manage and MyCase support this read pattern directly. You never persist a combined index, so there's no honeypot of everyone's clients sitting in one table waiting to be breached. The conflict desk learns "this party conflicts with a matter held by Lawyer C," and Lawyer C handles it from there.
The honest tradeoff: fan-out conflict checks are slower than a single indexed query, because you pay one round of API calls per lawyer. For a 15-lawyer network that's fine. For 500 it isn't. If you're truly heading toward hundreds of practitioners with shared supervision, the central-platform model and its audit trail become the right answer. Match the design to the real headcount, not the imagined one.
Step 4: Normalize the data you write back
Routing and conflict matching both get more reliable when the underlying data is consistent. That usually means normalizing custom fields, the same address typed five different ways, party names entered with and without suffixes. Here Clio's API is generous and the traps are specific.
You read custom field values with GET matter using a custom_field_values field selector, and you write them with PATCH matter carrying a nested custom_field_values array. There's no practical cap on field count; we've worked with matters carrying well over a hundred custom fields without issue.
The single biggest gotcha, the one that cost us an afternoon: the id inside the custom_field_values array is the value-instance id, not the field-definition id. If you send the field-definition id (the custom_field:{id} you used on read), the write silently misbehaves. You have to track the per-matter value instance.
Field type is the other constraint. Free-text fields normalize cleanly. Picklist fields only accept their predefined options and those options cap around 55 characters. Currency fields reject decimals. Date fields demand valid dates. So before you promise blanket normalization, inventory every field by type. "Normalize every field" is a different scope than "normalize the free-text fields and map the picklists separately."
Step 5: Close the loop with a document write-back
If your workflow produces an output document, a consult memo, a routing summary, a conflict-clearance note, write it straight back into the right matter. In Clio that's a two-step presigned-S3 upload: POST /documents to get a put URL, PUT the bytes to that URL, then PATCH to mark the document fully_uploaded. Miss the final patch and the document hangs in limbo. Our connector's upload_document tool handles the full multipart flow.
One thing to know going in: Clio has no document webhook, and its built-in document automation is UI-only with no API to trigger it. If your trigger is "a document was generated," there's no clean hook. You detect it by polling or by listening to the matter updated webhook (a stage change is usually the real cause of generation, so trigger on that instead).
Rate limits and the failure modes that actually bite
The fan-out design lives or dies on respecting limits. Clio's API runs conservatively, plan around roughly 3 requests per second per app (the docs also reference a legacy 50-per-minute figure). So throttle deliberately, honor the X-RateLimit-* headers, back off cleanly on a 429, and paginate at 200 records per page.
Two more that will surprise you:
- Webhooks expire. Clio webhooks auto-expire (3 days by default, 31 max). If you rely on them, build renewal in or they go quiet without an error.
- Write access is per-token. A normalization batch only touches matters the authorizing lawyer can write. In a per-user model that's the point, but it means each lawyer's batch is scoped to their own files. Run a dry-run preview and a per-matter rollback before any write hits production data.
If you're choosing between practice-management platforms, the read and write surface area matters here. Clio Manage and MyCase both expose the matter, contact, and document endpoints this recipe needs. PracticePanther has an API too, though we've built and open-sourced connectors specifically for Clio and MyCase. Tools like n8n can orchestrate the polling and fan-out glue if you'd rather wire it visually than write a service.
Data residency: the part lawyers ask about first
For privileged work, especially family law and other practice areas with strict confidentiality duties, where the data sits is a gating question, not a footnote. Canadian practitioners under PIPEDA often need data kept in Canada or the US only. Here's the honest map.
Practice data: Clio runs a Canadian region at ca.app.clio.com. Confirm the account is on the CA server and point every API call at the Canadian base URL. Your matters and contacts stay in Canada.
The LLM step: this is where the residual sits. Anthropic has no Canadian data region, so Claude processes in the US. Zero-data-retention is not available on the Team chat plan, that's a product limitation, not a small-firm rejection. ZDR is available on the Anthropic API at the organization level, and a small firm can obtain it. The workable shape: route the automation through the plain Messages API under a ZDR arrangement with US-pinned inference, so privileged content isn't stored at rest after the response. Keep the pipeline off the non-ZDR surfaces (Files API, Batch, code execution) and document the cross-border step for your bar's confidentiality obligations.
Don't reach for an Enterprise plan to solve this. Enterprise carries a seat minimum (roughly 20 self-serve, 50 sales-assisted) that a small network will overpay for. Org-level API ZDR gives the same retention posture without the seat floor.
If a consult call feeds the workflow, the same caution applies to the meeting platform. Zoom runs a Canadian data center, but AI-generated content residency isn't guaranteed Canada-only, so pull transcripts out fast and store them in your Canadian systems. A reliable backbone here is the cloud-recording VTT transcript (requires cloud recording on, and expect it about two times meeting length after the call). Treat the AI Companion summary as best-effort: its read scope is blocked in Server-to-Server OAuth and summaries auto-delete at 30 days, so if it's unavailable, summarize the VTT yourself.
The human-review gate is not optional
Whatever this pipeline drafts, a routing decision, a conflict flag, a consult memo, a human lawyer reviews and finalizes it. That isn't us being cautious. The Law Society of Ontario's 2024 guidance and ABA Formal Opinion 512 both point the same way: lawyers carry duties of competence and supervision over AI output, must verify what the tool produces, and can't bill AI time as lawyer hours.
So bake the gate into the architecture. The automation drafts and routes; it never files, sends, or clears a conflict on its own. The output lands in the matter marked for review, and a lawyer signs off. In a per-user model this is clean: the responsible lawyer is already the one who owns the file and the token.
A reference architecture for a small network
Putting it together for a network of 10 to 15 independent lawyers:
- Per lawyer, local: a packaged install holding only that lawyer's encrypted OAuth token, polling its data sources every 10 to 15 minutes.
- Shared, not pooled: one firm-level ZDR-enabled Anthropic API organization. It's just a shared credential, so every local install can call it. You get local execution and the ZDR guarantee with no hosted middle tier.
- Conflict check: a coordinator routine that fans out read-only queries per token, computes matches in memory, returns a flag plus responsible lawyer.
- Write-back: outputs uploaded straight into the right matter via the presigned-S3 flow.
- Human gate: every output marked for lawyer review before anything is final.
A hosted middle tier earns its place only if the network later wants a central audit log across all lawyers, or genuine real-time webhook delivery. For most small networks, polling and per-user isolation cover it. Build for the headcount you have.
This is also why "build vs. configure" matters. Off-the-shelf connectors get you reads and basic writes. The network-aware conflict fan-out, the value-instance-id handling on custom fields, the meeting-to-matter matching, the ZDR routing, those are the parts you assemble for the specific practice. Generic agencies that haven't shipped against these APIs tend to discover the gotchas on your dime. Arkenea and Topflight are capable healthcare and legal builders; the difference with a practice-specific build is whether the team has already hit the value-id trap and the expiring-webhook surprise before they hit them on your project.
Frequently Asked Questions
How do you run conflict checks across independent lawyers without merging their files?
Use per-user isolation. Each lawyer keeps their own practice-management instance and their own API credential, and the conflict logic runs as a fan-out query against each lawyer's data under that lawyer's own token, in memory. You never build a shared central index of everyone's matters. The check returns only a yes/no flag plus the responsible lawyer, never the underlying privileged records. This keeps files siloed by design while still answering "has anyone in the network touched this party."
Does the Clio API support reading and writing custom fields for normalization?
Yes. Read values via GET matter with a custom_field_values selector, write via PATCH matter with a nested custom_field_values array. The id inside that array is the value-instance id, not the field-definition id, which is the most common trap. There's no practical cap on field count. Field type matters: free text normalizes cleanly, picklist values must match predefined options (around 55 characters max), currency rejects decimals, and dates must be valid. Inventory fields by type before promising blanket normalization.
Can Claude process privileged Canadian legal data?
Anthropic has no Canadian data region, so Claude processes in the US. Zero-data-retention isn't available on the Team chat plan, but it is available on the Anthropic API at the organization level and is obtainable by a small firm. Route the automation through the plain Messages API under a ZDR arrangement with US-pinned inference, keep practice data in a Canadian region like Clio's ca.app.clio.com (PIPEDA), and document the cross-border step for your bar's confidentiality rules. Keep the pipeline off non-ZDR surfaces like the Files API and Batch.
Do you need a hosted server to automate this for a small lawyer network?
Usually no. For 10 to 15 lawyers, a packaged local-first install per lawyer, all calling one shared firm-level ZDR API organization, gives you local execution and the privacy guarantee with no hosted middle tier. A hosted server only earns its keep if you need a central audit log across the network or real-time webhooks. Polling a recording or document endpoint every 10 to 15 minutes is local and sufficient for most consult workflows.
Why not just build one central platform for the whole network?
Because independent lawyers who share a brand but not their files don't want their matters pooled into one index. A central platform creates exactly the cross-contamination the silo was built to prevent, and a single breach exposes the whole network. A central platform is the right call when lawyers genuinely share matters and supervise each other, where its audit trail is a feature. Match the design to the real relationship, not to what's easier to build.
Next Step
If you're running a network of independent lawyers on Clio or MyCase and want routing, conflict checks, or consult automation that respects per-user isolation, the right first move is to prove one workflow before committing to a rollout. Start with the highest-friction step, ship it for one lawyer, then replicate the install across the network.
We offer a free 30-minute architecture review where we'll look at your stack, your network structure, and the workflow you want to automate, and give you an honest read on what's a config change, what's connector work, and where the API actually limits you. No pitch deck, just the technical conversation.
Book a free architecture review →
Or explore more from our legal AI integration practice:
