How to Automate Legal Intake & Conflict Checks with n8n + Claude (2026 Guide)

The intake bottleneck no firm wants to admit

In most mid-size firms, a new prospect waits 26 hours for a callback, a paralegal copy-pastes contact details into Clio for the third time that morning, and a partner discovers — three weeks into a representation — that the adverse party is a former client. Each of those failures is preventable with the same workflow.

This guide walks through a production-ready intake + conflict-check pipeline built on n8n, Claude (via Bedrock with a BAA), and your existing practice management system. It is the same architecture our engineers deploy for boutique litigation firms and 80-attorney general practices alike — see the parent Legal AI Automation service for the productized version.

1
Connect every inbound channel to one queue

The first failure mode in legal intake is fragmentation: web forms land in Gravity, referrals come by email, and walk-ins are transcribed by reception. Before any AI runs, normalize every source into a single n8n queue with a stable JSON shape.

We use three triggers in parallel: a Gravity Forms (or Formidable) webhook, an IMAP node polling `intake@` every 60 seconds, and a Twilio Voice Intelligence transcript webhook for after-hours phone leads. Each trigger writes to the same `intakes_raw` Postgres table with `source`, `received_at`, and a `payload` JSONB column. Downstream nodes never branch on source.

{
  "node": "Postgres Insert",
  "table": "intakes_raw",
  "columns": {
    "source":      "={{$json.source}}",
    "received_at": "={{$now.toISO()}}",
    "payload":     "={{JSON.stringify($json)}}",
    "channel_id":  "={{$json.channel_id || null}}",
    "status":      "queued"
  },
  "options": { "returnFields": "id" }
}

2
Extract PII and classify the matter type with Claude

A single Claude call now does double duty: structured PII extraction plus a constrained-vocabulary matter classifier. Use a tool-calling pattern with a strict JSON schema so n8n never has to parse free text — and so you get deterministic-shaped output for the conflict step.

The seven matter types we route to are: personal injury, family, criminal, real estate, business, IP, immigration. We append an `other` bucket that pages the duty attorney rather than auto-routing — silent misclassification is worse than a manual review.

You are an intake analyst at a US law firm. Given the
inbound message, extract PII and classify the matter.

Output ONLY valid JSON matching this schema:
{
  "client":   {"full_name": str, "email": str|null,
               "phone": str|null, "dob": str|null},
  "adverse":  [{"full_name": str, "role": str}],
  "matter":   "personal_injury" | "family" | "criminal" |
              "real_estate" | "business" | "ip" |
              "immigration" | "other",
  "summary":  str (max 280 chars, NO legal opinion),
  "urgency_signals": [str],
  "confidence": float (0-1)
}

NEVER summarize legal merit. NEVER cite statutes.
If matter is unclear, return "other" and confidence < 0.6.

3
Run a real conflict check (not just a name match)

Conflict-check is where most automations fail honestly: they query the Clio Contacts endpoint with `?query=Smith` and call it done. Real conflicts hide in former clients, opposing parties from closed matters, related corporate entities, and trust ledger payors. Pull all of them into a Postgres mirror nightly, then query with `pg_trgm` for fuzzy name match plus an exact-match pass on email/phone/EIN.

The two queries below run in parallel against `clients_mirror` and `adverse_mirror`. Anything above 0.62 similarity surfaces to a reviewer; anything above 0.85 hard-stops the pipeline pending partner sign-off.

-- Requires: CREATE EXTENSION IF NOT EXISTS pg_trgm;
WITH candidate AS (
  SELECT $1::text AS name, $2::text AS email, $3::text AS phone
)
SELECT
  c.id, c.full_name, c.matter_status,
  similarity(c.full_name, candidate.name) AS name_score,
  (c.email = candidate.email) AS email_hit,
  (regexp_replace(c.phone,'D','','g')
    = regexp_replace(candidate.phone,'D','','g')) AS phone_hit
FROM clients_mirror c, candidate
WHERE c.full_name % candidate.name        -- pg_trgm operator
   OR c.email = candidate.email
   OR c.phone IS NOT NULL
ORDER BY name_score DESC
LIMIT 25;

4
Triage urgency: statute of limitations and court dates

A car accident inquiry that arrives 11 months after the incident is a fundamentally different ticket than one filed three weeks out. Surface those signals before the matter hits an attorney's queue. Claude already returns `urgency_signals` in step 2 — a small rules engine in n8n converts those into a numeric priority that drives queue position and SLA timer.

We use four buckets: P0 (statute expiring in <60 days, court date in <14 days), P1 (statute <180 days, custody/restraining order), P2 (active deadline >180 days), P3 (no time pressure). P0 pages the duty attorney via Twilio SMS; everything else falls into a Slack channel with response targets.

const signals = $input.item.json.urgency_signals || [];
const text    = signals.join(' ').toLowerCase();

const has = (kw) => kw.some(k => text.includes(k));

let priority = 'P3';
if (has(['hearing tomorrow','court today','arraignment',
         'arrested','served papers'])) priority = 'P0';
else if (has(['restraining','custody','eviction',
              'deportation','statute'])) priority = 'P1';
else if (has(['accident','injury','contract breach',
              'closing date'])) priority = 'P2';

return [{
  json: { ...$input.item.json, priority,
          sla_minutes: { P0: 15, P1: 60, P2: 240, P3: 1440 }[priority] }
}];

5
Create the matter and assign by practice area + workload

Now the cleared, classified, prioritized intake hits the create-matter step. The Clio v4 REST API takes a contact, a matter, and a related-parties list in three sequential calls — wrap them in an n8n Sub-Workflow with a single retry policy so a partial failure rolls back the contact creation. PracticePanther and MyCase users follow the same shape with their respective endpoints.

Assignment is a weighted query against an `attorneys` table: filter by practice area, sort by current open-matter count ascending, break ties by oldest last-assigned timestamp. Avoid round-robin alone — it ignores capacity. Avoid pure capacity sort — it concentrates work on whoever just closed a matter.

POST https://app.clio.com/api/v4/matters
Authorization: Bearer {{$credentials.clio_oauth.access_token}}
Content-Type: application/json

{
  "data": {
    "client":            { "id": {{$json.client_id}} },
    "description":       "{{$json.summary}}",
    "practice_area":     { "id": {{$json.practice_area_id}} },
    "responsible_attorney": { "id": {{$json.attorney_id}} },
    "status":            "Pending",
    "custom_field_values": [
      { "custom_field": {"id": 12345},
        "value": "{{$json.priority}}" },
      { "custom_field": {"id": 12346},
        "value": "{{$json.intake_id}}" }
    ]
  }
}

6
Append-only audit log + privileged communication flag

ABA Model Rule 1.6 requires the firm to make reasonable efforts to prevent unauthorized disclosure. In automation that means: every intake produces an immutable record of what was extracted, what was sent to Claude, what conflict candidates surfaced, and who saw the result. Use a Postgres table with `INSERT`-only privileges and a daily WORM snapshot to S3 Object Lock.

Every row is tagged `privileged: true` by default and excluded from any reporting dashboard. Reporting joins against an aggregated view that drops the `payload` column entirely.

CREATE TABLE intake_audit (
  id              bigserial PRIMARY KEY,
  intake_id       uuid NOT NULL,
  occurred_at     timestamptz NOT NULL DEFAULT now(),
  actor           text NOT NULL,             -- 'n8n' | 'claude' | user
  event           text NOT NULL,             -- 'extract'|'classify'|...
  payload_hash    text NOT NULL,             -- sha256 of payload
  conflict_hits   jsonb,
  privileged      boolean NOT NULL DEFAULT true,
  matter_id       bigint
);

REVOKE UPDATE, DELETE ON intake_audit FROM PUBLIC;
GRANT  INSERT, SELECT  ON intake_audit TO n8n_writer;

Common failures we see in production

• The "Smith" problem. Surnames repeat. Always require at least one secondary identifier — DOB, email, or address — before a conflict-clear. Cleared "John Smith" representations turning out to be the wrong John Smith account for ~40% of conflict-related malpractice claims.
• Silent OAuth expiry. Clio and PracticePanther tokens roll on a 7-day window. Without an external monitor, a firm discovers the failure when intake silently stops creating matters; queue depth is your canary.
• Voicemail-as-intake. Twilio transcripts of poor-audio voicemails frequently produce garbage names. Always force `confidence < 0.7` on Claude's classification when source is `phone` to fall through to human review.
• Hallucinated practice area on novel matters. Claude will confidently classify a "trademark dispute about a non-fungible token" as IP when it might really be commercial litigation. The `other` bucket exists for this — keep it generous.
• Audit-log writes inside the same transaction as Clio create. A Clio API timeout rolls back your audit insert and you lose the breadcrumb. Audit writes are always their own transaction and run before the third-party API call.

Privacy and compliance posture

Legal automation lives or dies on the BAA chain. The default architecture we ship uses Claude via AWS Bedrock under an executed BAA, n8n self-hosted on AWS in a VPC the firm controls, and Postgres on RDS with encryption at rest and in transit. No client data leaves the firm's AWS account except for the encrypted Bedrock call itself, which Anthropic's Bedrock terms cover under zero-data-retention.

For EU clients, the same architecture deploys to `eu-central-1` and adds GDPR data subject access flows on the audit table. For firms doing ITAR-touching work, we recommend an air-gapped deployment that uses an on-prem LLM (Llama 3.1 70B) instead of Claude — the n8n workflow shape is identical, only the model node changes.

Attorney-client privilege is preserved by treating every intake as presumptively privileged from the moment it is received. Work-product doctrine extends to the conflict-check artifacts; that is why the conflict_hits column is in the same privileged audit table rather than a generic logging system.

For the SEO and content side of building authority around these capabilities, see our SEO services.

Results from a representative deployment

A 22-attorney general practice firm in the Midwest deployed this pipeline in early 2026. The numbers below are from the first 90 days post-go-live versus the prior 90 days.

Implementation timeline

A typical engagement runs four weeks from kickoff to go-live. Discovery is intentionally front-loaded; the Clio API audit catches half the issues that would otherwise surface in week 4.

• Week 1 — Discovery + Clio API audit. Map current intake channels, audit existing client database for duplicates, validate Clio (or PracticePanther) API access, sign Bedrock BAA.
• Week 2 — n8n + Claude prompt engineering. Stand up self-hosted n8n, build the four core workflows, iterate on the classifier system prompt against the firm's last 200 closed matters.
• Week 3 — Conflict check + matter routing. Mirror Clio data into Postgres, build pg_trgm queries, tune the similarity thresholds against known-conflict test cases, configure attorney assignment table.
• Week 4 — Audit log + go-live. Deploy audit table with WORM snapshots, walk through ABA Rule 1.6 review with the firm's COO or general counsel, soft-launch on one practice area, expand firm-wide by end of week.

Frequently asked questions