Building a connector for a law firm's document system: lessons from Legora's FDE job posting

Picture your first week at a law firm. The partners want to ask questions of the documents for each matter, which sit in iManage. Almost nobody mentions the model at the first technical meeting.

The head of IT asks just one question: if lawyer A is walled off from matter X, will your system expose any page of matter X to A?

Your job starts with that question. Legora describes its FDE role as sitting between product engineering and customer success. The person in it works alongside enterprise clients during and after deployment, writing production code that connects Legora’s platform to the client’s systems.

The job posting spells out what you need to know: DMSs such as iManage, SharePoint or NetDocuments, SSO via SAML and OIDC, and REST-style APIs and webhooks.

It comes with a specific responsibility: build and maintain connectors, automation scripts and reusable tools so that later deployments go faster.

The skill is not confined to Legora. You can take it to any company that sells software to an industry with sensitive data.

Who owns the documents?

When Legora launched its integrations ecosystem in October 2026, it stressed one principle: lawyers can browse, search and work with matter documents inside Legora, but the source platform remains the system of record. It sounds like a line for the marketing team. In fact it is the most important design requirement for the connector.

The principle has two consequences. The DMS keeps the official copy of each document, along with its versions, metadata and edit history, so the connector must not create a copy that gradually drifts away from the original. And access is decided by the DMS, not by you.

According to LawNext, in the iManage integration, iManage permissions determine what each user can retrieve. Artificial Lawyer likewise wrote that the ethical walls and security restrictions the firm already applies determine what Legora is allowed to access.

An ethical wall stops a lawyer from reaching files where there is a conflict of interest. A document slipping through that wall is a serious incident, not an ordinary technical bug.

One interface, many adapters

Why does the job posting stress the word “reusable”? This firm uses iManage, the next uses NetDocuments, and the one after keeps everything in SharePoint. If you start from scratch each time, your experience never compounds.

The sensible split is a shared interface for the application to call, with a separate adapter for each DMS underneath. The sketch below illustrates the design; it is not Legora’s code:

from typing import Protocol

class DMSConnector(Protocol):
    def search(self, user: UserIdentity, query: str,
               matter_id: str | None = None) -> list[DocRef]: ...
    def fetch(self, user: UserIdentity, doc: DocRef) -> DocContent: ...
    def handle_event(self, event: dict) -> None: ...  # webhook: doc moved, permission changed

class IManageAdapter:
    def search(self, user, query, matter_id=None):
        token = self.tokens.for_user(user)  # user's own token, never a service account
        return self.client.search(query, matter=matter_id, auth=token)

    def fetch(self, user, doc):
        token = self.tokens.for_user(user)
        # the DMS checks permissions again on every read
        return self.client.get_document(doc.id, auth=token)

    def handle_event(self, event):
        if event["type"] in ("permission_changed", "document_moved"):
            # drop results computed under the old permissions
            self.cache.invalidate(matter_id=event["matter_id"])

The detail worth noticing is that UserIdentity appears in every function. Each call carries the identity of the person asking, taken from SSO (SAML or OIDC), and the adapter uses that same identity to call the DMS. The DMS therefore filters by that person’s permissions itself, both when searching and when opening a document, and you do not have to replicate the permission logic.

The design also pays off when the connection method changes. According to LawNext, Legora has integrated iManage via its API and plans to add a connection to the iManage MCP Server.

The ecosystem launch announcement also said iManage and NetDocuments are connected through the Model Context Protocol for knowledge and search. If the connection type lives only in the adapter, you can swap the adapter without touching the interface or the permission tests.

A six-cell matrix before go-live

Ethical walls need to be tested the way security is tested. Take a hypothetical scenario with two matters and three lawyers. An works on matter 1001. Binh works on matter 1002. Chi is a lawyer at the firm who has never worked on matter 1001, but is walled off from it because of a conflict of interest.

User	Search in matter 1001	Search in matter 1002
An	Results	Empty
Binh	Empty	Results
Chi (walled off from 1001)	Empty, even when typing the exact document name	Empty

Three people times two matters makes six cells, each an automated test. The most important cell is Chi’s in matter 1001. If the search index was built with a service account that can read everything, that cell will almost certainly return results, which means a leak.

You should also rerun the matrix after every permission change. Remove An from matter 1001 in the DMS, send the webhook event to handle_event, then check that An’s next search comes back empty. This is exactly where a stale cache tends to break things quietly.

Owning the work end to end at the client

Legora gives its FDEs the whole technical scoping process, from gathering requirements to designing the integration architecture. At a law firm, the scoping session should answer four questions. Which DMS, and is it cloud or on-premise? Does SSO use SAML or OIDC? Where are the ethical walls configured? Does the DMS emit webhooks when permissions change?

After that, the order of work should be: interface, adapter, identity mapping, test matrix, webhook handling, and only then the question-answering feature. Many people do it the other way round because question answering impresses in a demo. But a single data leak is enough to lose the contract.

The last step, often skipped, is taking what you learned back to Engineering and Product. Legora’s job posting states that FDEs work with both teams to improve the integrations and the shared product.

If you find yourself hand-writing the same permission-group mapping at three clients in a row, that is a sign it should become part of the standard connector.

Mistakes that make a connector impossible to reuse

The most common mistake is copying the whole DMS into a separate store to make search faster. It breaks both principles: the copy drifts away from the system of record, and permissions are frozen at the moment of copying.

The second is letting client-specific logic leak into the shared interface, for example a field called matter_code_format_firmB. Every difference belongs in the adapter or a configuration file.

The third is skipping identity mapping. The email in SSO and the username in the DMS do not always match. Map one person wrongly and the test matrix becomes meaningless.

Showing this skill on your CV

When reading FDE job postings, look for phrases such as “reusable connectors”, specific DMS names, SAML/OIDC and webhooks. They signal that the work leans towards integration rather than demos.

On your CV, do not just write “integrated SharePoint”. Write that you built a connector, reused it across a number of deployments, tested permissions with a given number of test cases, and let no document through an ethical wall. A hiring manager reading that line will understand that you can genuinely answer the head of IT’s question.

Models will keep changing, and so will connection methods, from REST to MCP to whatever standard comes next. The question of who may see what will not, and the FDE who answers it with tests rather than promises is the one clients will trust.