Every legal team eventually hits the edge of what configuration reaches. The question is not whether to extend CaseCloud — it is whether the extension is built so a Mitratech release lands quietly, or so every upgrade becomes a regression project. Twopir Consulting builds workflow automation, custom interfaces and Apex on CaseCloud, with the boundary stated first.
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
None of these come from a single bad decision. They come from a series of reasonable ones taken without a stated boundary. The boundary is the deliverable.
Without a stated boundary, every request becomes Apex — including the ones Flow would have handled in an afternoon. The org accumulates custom logic that only its author understands, and the firm pays for that in every subsequent change.
Extensions built against managed-package internals rather than supported extension points fail when Mitratech ships an update. Upgrades get deferred, the org drifts behind, and eventually the firm is stuck on a version it cannot leave.
Flows, process builders, triggers and validation rules added over years by different hands, firing in an order nobody has mapped. A field update takes eleven seconds and produces two records nobody expected.
The data model is sound but the screens were never designed for how a fee earner actually works a matter. So work happens in email and a spreadsheet, and the system holds a half-accurate record of it.
Custom code without meaningful test coverage means every deployment is a gamble. Teams compensate by deploying rarely, which makes each release bigger and riskier — the opposite of what they wanted.
The contractor who wrote it has moved on and left no documentation. The firm cannot safely change the thing its matter workflow depends on, and rewriting it is now a project.
["CaseCloud customization means extending a Mitratech CaseCloud deployment beyond what configuration reaches — using the Salesforce platform's own extension model: Flow, Lightning Web Components, Apex, Platform Events and APIs. Because CaseCloud is a managed package on Salesforce, it is extended the way any Salesforce application is extended, through supported extension points rather than by modifying the vendor's package.", "That distinction is the whole discipline. Code written against supported extension points survives Mitratech's releases; code that reaches into package internals does not, and the firm discovers this at the worst possible moment. The same logic governs automation: a deadline engine built in Flow, with its order of execution understood, is maintainable by the firm's own administrator — the same rule expressed as an Apex trigger usually is not.", 'Twopir Consulting builds on CaseCloud; we do not modify Mitratech\'s product. We are a Salesforce implementation partner with Salesforce developers, and our default is to configure first and write code only where it demonstrably earns its maintenance cost. Page one of this set sets out where configuration stops and development starts; this page is what happens on the far side of that line. Where the requirement is really about moving data between systems, integration services is the better starting point.']
The question is never "can it be built" — it is which tool the requirement belongs to, and what maintaining that choice costs for the next three years.
| Layer | What it covers | Upgrade & maintenance profile | When we use it |
|---|---|---|---|
| Configuration | Matter types, record types, page layouts, validation rules, approval processes, reports and dashboards. | Upgrade-safe by construction. Maintainable by a firm administrator. | Always the first answer. If configuration reaches it, configuration wins. |
| Declarative automation | Flow, scheduled and record-triggered automation, deadline and reminder engines, document generation, approval routing. | Upgrade-safe. Traceable in the platform's own tooling. Needs design discipline around order of execution. | Covers the large majority of legal workflow requirements, including most of what firms call "custom". |
| Custom code | Apex services and triggers, Lightning Web Components, Platform Events, batch and scheduled jobs, callouts to external systems. | Upgrade-safe only when written against supported extension points, with test coverage that is real rather than nominal. | Justified for genuine complexity, volume, or an external system with no declarative path. |
| Not recommended | Modifying the managed package, undocumented dependencies on package internals, logic duplicated across triggers and Flow. | Breaks on vendor releases. Cannot be supported. | We will say so and propose the supported alternative instead. |
Everything here is built on the Salesforce platform alongside the CaseCloud package — never by modifying it.
The bulk of what firms want from customization is automation, and most of it is achievable declaratively. We build matter workflow that holds up under real caseload and stays maintainable afterwards.
Screens designed around a fee earner's actual job rather than the object model — so the system stops being something attorneys work around.
Where genuine complexity or volume justifies code, we write it as a Salesforce developer would: bulk-safe, governor-aware, tested, and built against supported extension points.
When CaseCloud needs to reach a system with no packaged connector, we build and own the integration surface — with error handling and retry designed in, not added after the first outage.
We audit existing customizations for release risk, then remediate — replacing fragile code with supported patterns so vendor updates stop being events.
Custom work is only an asset if the firm can change it later. We deliver source control, a sandbox-to-production path, and documentation an incoming administrator can actually use.
Five phases. The first exists specifically to remove work — the cheapest custom development is the build that turned out to be configuration.
We take the requirement apart before estimating it. A surprising share of "custom development" requests are configuration once the underlying need is separated from the solution somebody already picked.
For anything that genuinely needs code, we design the approach against supported extension points and state the maintenance cost. If the cost outweighs the benefit, we say so — that is a legitimate outcome of this phase.
Development happens in source control against a sandbox, following Salesforce engineering standards: bulk-safe, governor-aware, configuration-driven, with security and sharing enforced rather than assumed.
Meaningful test coverage for code, structured user acceptance testing for workflow, and a regression pass against the CaseCloud package so we know the extension and the vendor's product still agree.
Deployment through a repeatable pipeline, documentation written for whoever maintains it next, and knowledge transfer to the firm's administrator. Ongoing change can then run through managed services or the firm's own team.
These are the requirements that come up repeatedly across law firms and corporate legal teams — and most of them are reachable declaratively, which is usually the surprise.
Court dates, limitation periods and internal review deadlines calculated from matter data and jurisdiction rules, generating tasks and escalations automatically. Built declaratively wherever the rule set allows, so the firm can adjust the rules without a developer.
Engagement letters, court forms and matter correspondence generated from CaseCloud data against firm templates, then routed for approval and signature — with the executed document and its status written back to the matter.
Guided intake that captures the right information per practice area, runs conflict checks on contact creation, routes to the right team by rules the firm controls, and converts a qualified enquiry into an open matter without re-keying.
Automated time capture prompts, rate and billing-arrangement logic, invoice assembly and approval routing, and budget-threshold alerts on matter spend — the automation that most directly changes realization.
Document extraction, summarisation and classification against matter records where volume justifies it. Mitratech ships CaseCloud Legal Assistant AI capabilities on Salesforce Agentforce; we advise on where those fit versus a custom build, and on the data and confidentiality questions either raises.
Where standard reporting cannot express a firm's measures — realization by matter type, workload weighted by complexity, deadline risk by team — we build the data structures behind them. Covered further under reporting and dashboards.
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.
The measure of custom work is not whether it shipped. It is whether the firm can still change it after a vendor release and a change of administrator.
Our default answer to a customization request is to ask what configuration cannot do. That conversation removes a meaningful share of requests before anyone is billed for development — which is not a sales strategy, it is what keeps orgs maintainable.
Extensions are written to survive Mitratech's releases. That constraint is decided at design time, because it cannot be retrofitted onto code that already reaches into package internals.
Bulk-safe, governor-aware, configuration-driven rather than hard-coded, with sharing and field-level security enforced and test coverage that actually asserts behaviour. The same standards we apply across 250+ platform deployments.
Most CaseCloud development engagements start with inherited custom work. We audit it, tell you what is a liability, and retire what is redundant rather than building another layer on top.
Source control, a deployment pipeline, documentation and knowledge transfer are deliverables, not extras. If your administrator cannot safely change what we built, we have not finished.
It can be extended substantially, because it is a managed package on the Salesforce platform rather than a closed product. Everything Salesforce offers for extending an application applies: Flow automation, Lightning Web Components, Apex, Platform Events and APIs. What should not happen is modification of Mitratech's package itself — extensions go alongside it through supported extension points, which is what keeps vendor releases from breaking them.
Not if it was built correctly. Extensions written against supported extension points — your own objects and fields, Flow, LWC, Apex that calls documented interfaces — survive vendor releases. Extensions that depend on package internals or undocumented behaviour do not, and that is the single most common cause of a firm becoming stuck on an old version. We assess release risk at design time, and we audit inherited customizations for it before adding anything new.
Configuration is declarative setup — matter types, layouts, validation, approvals, reports — and is upgrade-safe by construction. Workflow automation means Flow and related declarative tooling: deadline engines, task orchestration, document generation, approval routing, which covers the large majority of what firms describe as custom. Custom development means Apex, Lightning Web Components and APIs, and is justified by genuine complexity, data volume, or an external system with no declarative path. The cost difference between the second and third is significant, which is why the distinction is worth insisting on.
Both, with a stated preference. We build declaratively wherever the requirement allows, because declarative automation is traceable in the platform's own tooling and maintainable by a firm administrator. Where code is genuinely warranted we write production-standard Apex and Lightning Web Components — bulk-safe, governor-aware, configuration-driven, with enforced sharing and real test coverage.
Yes. We start by auditing what exists: managed-package dependencies, automation order of execution, test coverage, hard-coded values and release risk. You get a written assessment of what is sound, what is a liability and what is redundant, with the trade-offs of remediating versus rebuilding. Inherited custom work is a large share of what we are asked to look at.
By deciding ownership and order of execution up front rather than adding automation wherever it is convenient. That means consolidating logic per object instead of spreading it across overlapping triggers and Flows, mapping what fires when, documenting it, and retiring superseded automation rather than leaving it disabled. Most of the unmanageable orgs we inherit got that way one reasonable addition at a time.
Start with what the vendor ships. Mitratech offers CaseCloud Legal Assistant AI capabilities built on Salesforce Agentforce, covering areas such as document handling, intake and matter workflow — and vendor-supplied capability that is maintained for you is cheaper than an equivalent you own. A custom build is worth considering when the requirement is genuinely firm-specific, when data must not leave a particular boundary, or when the volume justifies it. Either way the confidentiality and data-residency questions should be answered before, not after.
Twopir Consulting extends Mitratech CaseCloud on Salesforce — workflow automation, custom interfaces and platform development for growing and mid-market companies and enterprise legal teams that need extensions to outlive the people who wrote them.
Speak with Salesforce developers who work in legal every week
