Nobody decided which system owns which field
Both systems can write the client address, so both do, and the last one to sync wins. Without a field-level ownership decision an integration does not resolve disagreement — it spreads it faster.
An integration is easy to demonstrate and hard to operate. The difference shows up the first time an API is down, a document is locked, or an invoice syncs twice. Twopir Consulting designs CaseCloud integrations around direction, ownership and failure — then monitors them.
Trusted by 500+ organizations — including law firms, corporate legal teams and legal technology companies building their operations on Salesforce with Twopir Consulting.








Built for Legal Operations
Every failure here was working on launch day. What was missing was a decision, an owner, or an alert. All three are design choices, not accidents.
Both systems can write the client address, so both do, and the last one to sync wins. Without a field-level ownership decision an integration does not resolve disagreement — it spreads it faster.
Integrations built without monitoring fail silently. The firm finds out weeks later when a reconciliation does not balance, and by then nobody can say which records are affected or when it started.
A copy is pushed to the document management system and another stays on the matter. Versions diverge, attorneys learn not to trust either, and the firm ends up with a third location — someone's desktop.
Time sits in CaseCloud, invoices in the accounting system, disbursements in a spreadsheet. Each is defensible alone; together they produce three different answers to the only question partners actually ask.
Each integration was built in isolation by whoever was available. Years later there is no diagram, changing one system breaks two others, and every upgrade turns into an archaeology exercise.
Matter data crosses into systems with looser access rules than the matter itself. Ethical walls hold inside CaseCloud and quietly do not hold in the system it syncs to.
["A CaseCloud integration connects the matter record to the systems around it — document management, finance, e-signature, identity, email and CRM — so that data is entered once and every system agrees on it. Because CaseCloud runs on the Salesforce platform, it inherits Salesforce's integration surface: REST and SOAP APIs, Platform Events, external services, middleware connectors, and the AppExchange ecosystem.", 'The technical connection is rarely the hard part. The hard parts are deciding which system owns each field, which direction data moves, what happens when the far end is unavailable, and who finds out when something fails. An integration designed without answers to those four questions works in a demonstration and produces reconciliation problems in production.', 'Twopir Consulting designs, builds and operates these connections as a Salesforce implementation partner — including the Salesforce-side architecture that determines whether an integration is maintainable. Mitratech\'s CaseCloud documentation covers what the product connects to natively, including its document management integrations; this page is about designing and running those connections for a specific firm. Integration is usually a workstream inside a wider CaseCloud implementation, and where a system is being retired rather than connected, migration services is the right starting point.']
Four patterns, chosen per flow rather than per firm. Most estates end up using at least three of them, and the mistake is applying one everywhere.
| Pattern | How it works | When it fits | What it costs you |
|---|---|---|---|
| Real-time API | A call is made the moment something happens — a matter opens, an invoice is approved. | The user is waiting, or the downstream system must act immediately. | Needs retry and failure handling designed in. A slow far end becomes your slow screen. |
| Scheduled sync | Batches move on a schedule — nightly finance reconciliation, periodic contact updates. | Volume is high, and minutes or hours of latency are acceptable. | Simplest to operate and easiest to re-run. Not suitable where staleness has consequences. |
| Event-driven | The source publishes an event; interested systems subscribe and react independently. | Several systems care about the same change, or you want them decoupled. | Scales well and isolates failures. More moving parts to monitor. |
| Middleware / iPaaS | An integration platform brokers the connections, holding mapping and orchestration centrally. | Many systems, complex transformation, or a firm that wants connections visible in one place. | Adds licence cost and a platform to own. Pays for itself past a handful of integrations. |
Building the connection is a fraction of the work. Deciding it correctly and operating it afterwards is the rest.
Before anything is built we map every system that touches matter data and decide, field by field, which one owns it and which direction data moves.
Matter records and document stores kept consistent, so attorneys stop maintaining a parallel folder structure alongside the system of record.
Time, invoices, payments and disbursements moving between CaseCloud and the accounting system so both agree on what a matter has cost.
Access governed by the firm's identity provider, with matter confidentiality enforced consistently across every connected system rather than only inside CaseCloud.
Where no packaged connector exists, we build the interface — with retry, idempotency and alerting designed in rather than added after the first incident.
An integration nobody watches is an outage waiting to be discovered by a client. We instrument every interface and put a named owner behind the alert.
Five phases. The second is where most of the value sits, and it is the one most projects skip straight past.
We inventory every system holding matter, client, document or financial data — including the ones not on the official list — and produce a current-state data-flow map. Most firms have not seen one.
Field by field: which system is authoritative, which direction data moves, and what happens on conflict. This is a business decision with technical consequences, so the firm makes it and we document it.
Pattern selection per flow — real-time, scheduled, event-driven or brokered — with a written data contract, failure behaviour, retry policy and alerting defined before anyone builds.
Interfaces are built in a sandbox and tested for the unhappy paths as well as the happy one: far end unavailable, partial payload, duplicate delivery, rate limit hit. That is where production integrations actually differ.
Go-live includes dashboards, alert routing and a named owner. From there interfaces are maintained under support and managed services or handed to the firm's team with runbooks.
Each of these names both systems, the business purpose, and the direction data travels — because a logo grid tells a buyer nothing about whether the connection will hold.
The most common legal integration and the one most worth doing properly. On matter open, the matter number, client, practice area and matter team flow from CaseCloud to iManage to provision the workspace with correct metadata and security. Document links, counts and activity flow back to the matter — so CaseCloud stays the system of record for the matter and iManage stays the system of record for the document, with neither duplicating the other.
The same pattern for firms standardised on Microsoft 365 or Google Workspace: matter-driven folder provisioning with naming conventions and permissions applied from the matter record, and document links surfaced on the matter. Permission alignment is the part that needs design — a folder structure that ignores the matter's confidentiality is a real risk, not a cosmetic one.
Engagement letters and matter documents are generated from CaseCloud data and sent for signature; envelope status, completion date and the executed document write back to the matter. This is what allows an intake record to become an open matter without anyone re-typing client details, and it is where intake-to-retainer time is most often lost.
Approved invoices, time entries and disbursements flow from CaseCloud to the accounting ledger; payment status, credit notes and write-offs return to the matter. Finance works from its own system, partners see realization on the matter, and reconciliation runs against control totals rather than opinion.
Because CaseCloud is on the Salesforce platform, client and contact data can be shared rather than synchronised — which is a materially better position than two systems agreeing to disagree. Business development sees matter history on the account; matter teams see the relationship. Firms most often skip this integration and most often regret it.
Single sign-on through the firm's identity provider, with CaseCloud access provisioned and deprovisioned by the same joiner-mover-leaver process as every other system. Matter confidentiality and ethical walls are propagated to connected systems rather than assumed to be handled there.
These outcomes come from Salesforce legal-operations engagements delivered by the same team, on the same platform CaseCloud runs on. Each figure is scoped to the engagement it was measured in — follow the case study for the full context.
Twopir's specialized Salesforce customization enabled efficient integration of third-party systems and streamlined administration and billing, leading to seamless financial operations and enhanced productivity. Automated mass billing and matter management minimized errors across our entire legal workflow.
A 50% efficiency gain from Accounting Seed and Salesforce integration.
Connecting two systems is a task. Keeping them in agreement through outages, upgrades and staff changes is the actual job.
Retry policy, idempotency, error queues and alert ownership are designed before the interface is built. Anyone can make two systems talk on a good day; the engineering is in what happens on a bad one.
The commonest integration failure is not technical — it is two systems both believing they own the same field. We force that decision early and write it down, because it is a business decision the firm has to make.
CaseCloud runs on Salesforce, so integration means governor limits, API allocation, bulkification and platform events. That is core Salesforce engineering, and it is where generalist integration work usually comes unstuck.
Legal data carries obligations that do not stop at a system boundary. Ethical walls and access rules are propagated deliberately rather than left to whatever the receiving system happens to do.
Integrations are not finished at go-live. We monitor, alert, maintain and change them — or hand over documentation and runbooks good enough for your team to do the same.
Two layers. Mitratech ships integrations with document management providers including iManage, SharePoint and Google Drive, and because CaseCloud is built on the Salesforce platform and distributed through AppExchange, it also inherits Salesforce's integration surface — REST and SOAP APIs, Platform Events, external services, middleware connectors and the AppExchange ecosystem. In practice that means most systems a firm runs can be connected; the real question is which ones should be, and in which direction.
The pattern that works is matter-driven provisioning. When a matter opens in CaseCloud, the matter number, client, practice area and matter team flow to iManage to create the workspace with correct metadata and security applied from the matter record. Document links and activity flow back, so the matter shows what exists without holding a second copy. CaseCloud stays the system of record for the matter, iManage for the document, and neither duplicates the other — which is the point most implementations miss.
One way per field, wherever possible. Bi-directional sync is genuinely required less often than it is requested, and every bi-directional field needs a conflict-resolution rule that someone has to own. Our default is to establish a single owning system per field and move data outward from it; we make exceptions where the business case is clear and we write the conflict rule down. Systems that both write the same field without a rule do not stay consistent — they just become inconsistent faster.
Direct integration is usually right for a handful of stable, well-documented connections. Middleware or an iPaaS starts paying for itself when you have many systems, meaningful transformation between them, or a firm that wants every connection visible and changeable in one place rather than buried in code. It adds licence cost and a platform to own, so we recommend based on the estate we actually map rather than as a default position.
That should be a designed behaviour, not a discovery. Every interface we build has a defined failure mode: retry policy with backoff, idempotency so a replay cannot duplicate records, an error queue holding what could not be processed, and an alert routed to a named owner. Reconciliation reporting then shows whether the two systems still agree. The integrations that cause real damage are the ones that fail silently for weeks.
Yes, and it has to be designed explicitly. Matter confidentiality enforced inside CaseCloud does not automatically hold in a connected system — a document store or reporting tool will apply its own access model unless told otherwise. We propagate the restriction to connected systems, align permission models, and include access review reporting. Treating this as an afterthought is one of the more serious mistakes available in legal integration.
Yes. We start by mapping what actually exists — which is often different from what is documented — then assess each interface for ownership clarity, failure handling, monitoring and confidentiality. You get a written position on what to keep, what to instrument and what to rebuild. Undocumented point-to-point integrations are among the commonest reasons firms call us.
Twopir Consulting designs, builds and operates Mitratech CaseCloud integrations on Salesforce — for growing and mid-market companies and enterprise legal teams that need matter, document and finance systems to agree.
Speak with a team that operates integrations, not just builds them