Two-way DMS sync without copying what we don’t need

A mid-sized firm has around 1.8 million documents in its document management system. Of those, perhaps 40,000 are contracts a reviewer might plausibly want to open in ZAAN this year. A sync that copies all 1.8 million into a second store has created a second record, a second attack surface and a second set of permissions to keep aligned, in exchange for nothing the firm asked for.

This guide explains how the two-way sync works, what it deliberately does not do, and how to set it up so that it stays that way.

What we sync and what we do not

The sync has two tiers. The first is metadata: document identifiers, titles, matter and client codes, version numbers, modification timestamps and the access control list attached to each document. This is what Recall indexes for search scoping and what Review uses to attach a flag to the right matter. Metadata is pulled on a schedule and on webhook events where the DMS supports them.

The second tier is content, and content is fetched on demand. When a reviewer opens a document in the Word add-in, or when Recall needs to read a precedent it has matched on metadata, ZAAN requests the current version from the DMS at that moment, processes it in memory within the tenant’s region, and discards it when the session ends. Zero retention applies: there is no ZAAN-side copy of the document after processing.

The exception is the Recall index itself. Recall needs a representation of document content to search it. That representation is an embedding store, per tenant, encrypted with the tenant’s key, and it is not the document. It cannot be reversed into the text. It is tagged with the DMS access control list at index time so that permission filtering happens before retrieval, not after.

Write-back as a new version, never in place

When Review proposes redlines and a reviewer accepts them, the result has to get back into the DMS. We had two options: modify the document in place, or save a new version. We chose new version, without exception, and no configuration changes this.

Each written-back version carries provenance in the DMS’s own version comment field: the ZAAN surface that produced it, the user who accepted the changes, the playbook version in force, and a short hash that the trace view can resolve. A partner looking at version history in the DMS sees a version authored by a named person via ZAAN, not a version authored by ZAAN.

Draft works the same way. A document composed in Draft is saved to the DMS as version one of a new document, in the matter the drafter selected, with the citations preserved as Word comments where the DMS keeps them and as a sidecar where it does not.

Permissions come from the DMS

ZAAN does not have its own model of who may see what. The DMS is the authority, and the sync reads its access control lists rather than reconstructing them. This has three consequences.

First, if a user cannot open a document in the DMS, they cannot open it in ZAAN, and Recall will not return it to them, not even as a snippet or a count. The filter is applied at retrieval, and the results are assembled only from documents the user is permitted to see.

Second, when permissions change in the DMS, the change propagates on the next metadata sync. For webhook-enabled systems this is near-immediate. For polled systems it is bounded by the polling interval, which administrators set and which we recommend keeping under fifteen minutes. Ethical walls applied retroactively after a lateral hire are the case to watch: the metadata updates quickly, but the affected matters must be re-indexed for the wall to apply inside Recall’s embedding store, and that re-index is scheduled, not instant. The admin console shows re-index progress per matter.

Third, we do not elevate. The service account used for sync has read access to metadata and read-and-version-write access to content, scoped to the libraries the firm chooses. It cannot change permissions, delete documents or alter version history.

Setup checklist

Before enabling the integration:

• Decide which libraries or cabinets are in scope. Most firms start with active transactional matters and exclude HR, finance and closed archives.
• Create a dedicated service account in the DMS with the minimum rights above. Do not reuse an administrator account.
• Confirm the data residency region for the tenant matches where the DMS is hosted or where the firm’s policy requires. The sync will not move content across regions.
• Set the metadata polling interval, or enable webhooks if the DMS supports them.
• Choose whether Recall indexes on first sync or only as documents are opened. Firms with strict walls usually start with the latter and widen scope once the wall configuration has been verified.
• Run the permissions audit from the admin console. It samples 200 documents, checks that each user’s visibility in ZAAN matches the DMS, and reports any mismatch before indexing starts.
• Nominate an administrator to receive re-index notifications.

Known limitations

Documents larger than 200 megabytes are not fetched on demand and must be opened directly in the DMS. Documents with custom security that bypasses the DMS’s standard access control list are excluded from sync entirely and show as “restricted at source”. Version write-back requires the DMS to support programmatic versioning; where it does not, ZAAN saves the result as a new document and records the relationship in the comment field. And a document checked out by another user in the DMS cannot receive a write-back until it is checked in; ZAAN holds the accepted redlines and retries, and tells the reviewer it is doing so.

The sync is designed to be forgettable. If it is working, nobody at the firm should ever need to think about where the document lives.