How law firms automate client identity verification in Filevine: two Zaps connect deepidv to intake and write structured results into every open project.
A practical guide for law firms running Filevine: how to make client identity verification start itself at intake and write its result straight into the case, using deepidv, Zapier, and one custom section, with no code and no middleman.
At most firms, identity verification is a side quest. A paralegal emails the client a link, waits, checks a vendor dashboard, and eventually types ID verified into a note where no report, filter, or auditor will ever find it. The case lives in Filevine; the verification lives everywhere else. Connecting the two turns that side quest into a property of the case itself.
Filevine is a full citizen of the Zapier directory, with real triggers and real actions, which makes the connection to deepidv a configuration exercise rather than an engineering project. Once the two Zaps described below are live, a new project triggers a verification session automatically, the client completes a selfie and document check anchored by passive liveness on their own phone, and the outcome lands back inside the same project as data: status, method, date, and session reference, each in its own field.
The word data is doing the work in that sentence. The result is written into a custom Identity Verification section as collection item fields, not filed into the project as a document. That is a feature, not a shortcut: fields can be filtered, reported on, and required, while a PDF in a folder can only be opened. A firm running this integration can pull a list of every open case with an unverified client in one report view. That is a compliance answer, not a convenience one.
The design is a round trip with the Filevine project ID as the thread that ties it together.
| Zap | Trigger | Steps | Result |
|---|---|---|---|
| 1. Intake starts verification | Filevine: New Event (project created or intake stage reached) | Create a deepidv verification session, passing the project ID as the session reference | Client receives the verification link automatically |
| 2. Outcome writes back | deepidv: session completed event | Filter on outcome, Find Project by the session reference, Create/Update Collection Item in the Identity Verification section | Verified status, method, date, and session ID land in the case |
The project ID as session reference is what makes the loop close. When the completed session comes back through Zapier, the second Zap does not have to guess which case the client belongs to: it carries the answer it was born with, finds the project, and writes the result exactly where the file handler will look for it.
Suggested read: Customer due diligence, explained
The staffing effect is the part firms feel first. With the loop live, nobody sends verification links, nobody polls a dashboard, and nobody transcribes outcomes. The paralegal's job narrows to exceptions: the sessions that fail, expire, or come back flagged, which surface in the same section with the same filters. Verification stops being a task someone performs on every client and becomes a condition the case either meets or visibly does not.
For firms with engineering resources, the same round trip can run against the Filevine API v2 directly: personal access tokens exchanged for bearer tokens, service accounts for automation identity, and separate US and Canada gateways. The Zapier route is the same architecture with the plumbing handled, which is why it is the right first build even for teams that could code it.
Plan an afternoon, not five minutes. The sequence that works: build the Identity Verification custom section in Filevine first, with fields for status, method, date, and session ID, because the Zap cannot write into a section that does not exist. Create a Filevine service account so the automation acts under its own identity rather than a staffer's login. Connect Filevine and deepidv to Zapier, build Zap 2 before Zap 1 so the write-back path exists before sessions start flowing, test with a dummy project end to end, then switch on the intake trigger. Finally, diarize the credential renewal: Filevine client secrets expire yearly, and the calendar entry is part of the build.
Honest edges, so the rollout survives contact with reality. Default API credentials are rate limited, which matters for high-volume intake. Client secrets expire every year, so set and forget is wrong by exactly one calendar reminder. Zapier's access follows the permissions of the connected user, which is the argument for the service account. A new project can fire its webhook before the project is fully queryable, so build the second Zap's Find Project step with a retry rather than assuming instant consistency. Filevine's firewall blocks VPN and anonymous IP traffic, which occasionally surprises remote staff. And decide deliberately who can see the Identity Verification section, because verification data is client data.
None of these are reasons to wait. They are the difference between an integration that demos well and one that is still running quietly at renewal time, which is the continuous trust standard worth building to.
Suggested read: Account takeover prevention: why verified users get hijacked
Yes. Filevine has a full Zapier presence with triggers and actions, so verification platforms such as deepidv connect without code: a new project can trigger a verification session, and the completed result writes back into a custom section as structured fields.
Through a Zap that fires on the completed deepidv session, finds the project by the ID the session carried as its reference, and creates or updates a collection item in a pre-built Identity Verification section: status, method, date, and session ID as fields, not a document.
No. The two-Zap build runs entirely in Zapier and takes roughly an afternoon including testing. Firms with engineering teams can implement the same round trip on Filevine's API v2 with service accounts, but the no-code route delivers the same architecture.
One recurring item: Filevine client secrets expire yearly, so credential renewal belongs on the calendar from day one. Beyond that, monitor the exceptions view for failed or expired sessions and revisit section permissions as the team changes.
Fields are reportable. A firm can filter every open case by verification status, make the field a stage requirement, and hand an auditor a live answer instead of a folder search. A document proves one client was checked; a field proves the process runs.
Go live in minutes. No sandbox required, no hidden fees.
An operational engineering analysis evaluating deepidv, CLEAR, and authID on sub-150ms response latency, device attestation, and deepfake prevention.
An operational engineering analysis evaluating deepidv, Persona, and Jumio on sub-150ms execution latency, device attestation, and deepfake interception.
A technical evaluation comparing deepidv against Veridas and Fourthline following their merger, focusing on eIDAS 2.0 readiness and sub-150ms execution.
