Why Filevine reporting gets hard at exactly the moment you need it
Filevine stores your custom data in two shapes, and the difference decides how far native reporting can take you.
Static sections hold fields that exist once per case: incident date, primary insurance carrier, client details. One project, one value. Reporting on these is easy, and the native Report Builder handles it fine.
Collection sections hold repeating rows: medical providers, insurance policies, settlement offers, discovery requests. One case might have nine providers and four policies. Each row is its own object with its own fields. Collections are what make Filevine flexible enough to replace the spreadsheets your case managers used to keep on the side.
They're also where reporting breaks.
Why can't the Report Builder join my providers, policies, and offers?
The native Report Builder can list one collection section across projects. What it can't do is join several collections into one view: medical providers next to settlement offers next to policy limits, per case, in one table. That query needs a relational join, and the native UI doesn't do relational joins across collections. Firms that try to force it get duplicate rows, inflated totals, or reports that time out. This isn't a bug you can configure around. It's the boundary of the tool, and everything below is about what to do once you hit it.
The four pathways out, compared
| Pathway | Latency | Cross-collection joins | Best for |
|---|---|---|---|
| Report Builder | Real time | No (one collection per report) | Daily task lists, SOL checks, single-collection audits |
| Data Connector (CSV) | Hours, max 5 runs/day | No (flat files) | Legacy BI feeds; not new builds |
| DataBridge (Snowflake) | ~10–20 min | Yes (full SQL) | Executive dashboards in Power BI, Domo, Looker Studio |
| REST API v2 | Real time | In your code | Event-driven automation, targeted queries, integrations |
What does the native Report Builder actually handle well?
More than it gets credit for. Grouped fields, custom columns, filters, and scheduled email delivery cover the operational layer: today's deadlines, this week's statute checks, every case in the demand phase. If a report reads one section and answers one question, build it natively and schedule it. The mistake isn't using the Report Builder. It's asking it to be a business intelligence platform.
What breaks in the Data Connector?
The Data Connector schedules exports of saved reports as CSV files into your own S3 bucket or Azure storage, up to five times a day. It was the standard answer for feeding external BI tools, and plenty of firms still run it. As of mid-2026 it comes with three warnings. Delivery latency runs to hours, so nothing built on it is close to live. Performance degrades hard on wide reports, around 50 custom columns or 100,000 collection records in our experience and in Filevine's own guidance. And Filevine has signaled the connector is headed for retirement in favor of DataBridge. If someone proposes building your new dashboard suite on scheduled CSVs, that's a proposal to build on a floor marked for demolition.
What does DataBridge give you that nothing else does?
DataBridge is the pathway Filevine itself is investing in. You get a normalized copy of your data, delivered through Snowflake Secure Data Sharing, refreshing on roughly a 10 to 20 minute lag, with the full schema exposed: notes, audit trails, billing entries, calendar events, documents metadata, static fields, and, critically, every custom collection as a queryable table. This is where the multi-collection join problem dies. Providers, policies, and offers become tables you join with ordinary SQL, and the result feeds Power BI, Domo, or Looker Studio like any other warehouse. The cost is infrastructure: you need a Snowflake account or reader account, someone to model the data, and someone to build and maintain the dashboards. That's a real project, and it's the right project for firms past a certain size.
Where does the REST API fit, and where do its rate limits bite?
The API is the pathway we know best, because we shipped a public integration against it. Authentication runs on a Personal Access Token exchanged for a bearer token, and every request carries three headers, not one: the bearer token plus x-fv-orgid and x-fv-userid. Miss the second two and nothing works, which is the first thing that surprises developers arriving from other legal platforms like Clio or MyCase, where a bearer token alone is enough.
The limits are the part that shapes architecture. Standard endpoints allow around 320 requests per endpoint per minute, billing around 250. The reports and vitals endpoints allow roughly 5 per minute. Read that again before you design anything: the endpoints most relevant to reporting are throttled at about a sixtieth of the standard rate. So the API is excellent for event-driven work, a webhook fires when a case changes phase, your code updates a tracker, notifies a client, or creates tasks, and it's the wrong tool for bulk-extracting your whole dataset every night. Firms that try to run dashboards through the API end up building rate-limit queues to reinvent what DataBridge already is.
The fifth pathway: asking your case data questions in plain English
There's now a pathway that didn't exist when most Filevine reporting guides were written. An MCP connector lets an AI assistant like Claude read Filevine directly, so a partner types "which of our litigation cases have had no note activity in 30 days" and gets an answer, without anyone building a report first.
We built and published the open-source Filevine MCP server (@oktopeak/filevine-mcp on npm), the same family as our Clio and MyCase connectors. The hardest engineering problem wasn't auth. It was that PI-specific data lives in custom collection sections that differ from firm to firm, so the connector runs a schema discovery step: it learns your firm's sections and field names before it queries anything, instead of assuming a fixed layout.
Honest scope note: MCP querying inherits the API's limits, including the 5-requests-per-minute ceiling on vitals endpoints. It's built for ad-hoc questions and case-level answers, not for rebuilding your dashboard suite. Think of it as the reporting layer for questions you haven't thought of yet; DataBridge is the layer for questions you ask every Monday.
One more thing firms rightly ask: what about privilege? Plain-English querying means case data flows through a model. The defensible configuration is enterprise-tier AI with training disabled and zero data retention, and for firms whose requirements rule out any third-party processor, the same pattern works with models running on your own infrastructure.
What a PI firm should actually put on the dashboard
Pathways are plumbing. The reports are the point, and in high-volume personal injury work six of them cover most of what leadership is missing:
- Phase aging. Average days per phase, per case type, with the outliers surfaced. Stalled files cost settlement value quietly.
- Treatment and records status. Open record requests, balance verifications, treatment completion, so demands go out when treatment ends, not weeks later when someone notices.
- Demand pipeline aging. Every demand from draft to insurer response, tracked against carrier response windows.
- SOL risk matrix. Statutes of limitations across every open matter, sorted by proximity, visible to more than one person.
- Staff throughput. Task completion, note activity, and document volume per user, from the activity data Filevine already records.
- Settlement realization. Gross settlement to attorney fees to lien reductions to net client recovery, per case and in aggregate.
We've built this class of reporting before, outside Filevine: a case lifecycle platform whose aging report flags any file that sits open past a 14-day threshold and alerts the responsible person, and a compliance platform that generates templated PDF reports in under 3 seconds each. The pattern transfers directly; Filevine just changes which pathway feeds it.
Which pathway for which firm
Sizing this honestly saves you from buying architecture you don't need.
Small firm, one office, one practice area: native Report Builder plus scheduled email delivery, and maybe the MCP connector for ad-hoc questions. You don't need a warehouse.
Growing firm with workflow pain: the API layer earns its keep here. Phase-change automations, client notifications, deadline syncs, intake pushed from your lead tools into the right project sections. Middleware platforms like Zapier, Make, or Workato can carry some of this; custom code carries the rest. This is also where purpose-built PI tooling starts to make sense alongside Filevine.
Multi-department firm where leadership runs on dashboards: DataBridge into Power BI, Domo, or Looker Studio, modeled once, refreshed continuously, with row-level security so each department head sees their own slice. At this size the question isn't whether to build it, it's whether it gets built by someone who understands both the Filevine schema and the legal workflow it describes.
The three failure modes we see in Filevine reporting projects
First, schema fragmentation: a migration vendor pasted the old database into Filevine without normalizing anything, so the same fact lives in three fields and every total is wrong. The fix starts with a field-mapping audit, not with dashboards. Second, automations authenticated through a person instead of a service account: the paralegal who set up the Zapier connection leaves, their account gets deactivated, and every automation dies the same morning. Use dedicated service accounts, and put token renewal on a calendar with at least 15 days of margin. Third, building new analytics on the Data Connector because it was already there. It's deprecated-in-waiting; see above.
FAQ
Can Filevine's native Report Builder join multiple collection sections?
Not in a single report. One collection per list report is the boundary. Cross-collection views require pulling the data out through DataBridge, the API, or an export and joining it outside Filevine.
What is Filevine DataBridge and when does a firm need it?
A normalized copy of your Filevine data shared through Snowflake, refreshing on roughly a 10 to 20 minute lag, with full SQL access to every table including custom collections. You need it when leadership wants standing cross-collection dashboards in Power BI, Domo, or Looker Studio.
Is the Filevine Data Connector being deprecated?
Filevine has signaled the legacy CSV connector is headed for retirement in favor of DataBridge. It still runs as of mid-2026, capped at five deliveries a day with multi-hour latency, but we don't build new analytics on it.
What are the Filevine API rate limits for reporting?
Roughly 320 requests per endpoint per minute on standard endpoints, 250 on billing, and about 5 per minute on reports and vitals endpoints. That last number is why the API suits targeted queries and automation rather than bulk dashboard feeds.
Can I ask Filevine questions in plain English with Claude?
Yes, through our open-source Filevine MCP server (@oktopeak/filevine-mcp on npm). It reads projects, contacts, deadlines, and custom collections after a schema discovery step, and it's built for ad-hoc questions rather than bulk analytics.
What reports should a personal injury firm track first?
Phase aging, treatment and records status, demand pipeline aging, an SOL risk matrix, staff throughput, and settlement realization. Each one maps to a specific, expensive leak: stalled files, late demands, missed deadlines, uneven workloads, and fee slippage.
If you're staring at a report the Report Builder won't produce, the fastest way to find out which pathway you actually need is a conversation with someone who has shipped against this API. Our Filevine integration work, including scope and pricing, is laid out on the Filevine integration page, and discovery is free: book a 30-minute call. Bring the report you can't build. That's usually the whole brief.
