Multi-Firm Litify: Standardize the Shared Layer, Keep Each Firm’s Edge
A multi-firm Litify rollout rarely fails on configuration. The managing partner sat across from legal operations with a blunt question: "Why don't our numbers ever add up?" Two affiliated firms ran Litify on Salesforce, but the same client appeared as three different names across reports, matter stages meant different things in each firm, and the group dashboard showed open matters that one firm considered closed. The software was there. The shared operating agreement was not.
Running multi-firm Litify for multiple law firms under one group works when the group standardizes a handful of shared elements, the data model, reporting definitions and the security baseline, and lets each firm keep its own intake rules, matter stages and templates. That is the core answer. A multi-firm Litify program is not about forcing every firm into one workflow; it is about making the shared layer shared and the local layer local, deliberately.
The real problem is rarely the Salesforce configuration. It is that the group never decides which layer is common and which is firm-specific, so every change becomes a negotiation. That is why multi-firm Litify is a governance problem before it is a technical one.
In the sections ahead, we'll look at why multi-firm Litify is a governance problem before it is a configuration problem, then walk through the standardize-vs-keep-firm-specific split across eight areas, explore how different Salesforce org setups change that split, lay out change approval and release coordination across firms, draw the reporting and access boundaries between group and firm views, propose an operating model that a central platform team, firm-level owners and a delivery partner can run together, and close with answers to the questions legal groups ask most. If you are newer to the platform itself, start with our explanation of what Salesforce Litify is before diving into the governance layer.
Why Multi-Firm Litify Is a Governance Problem Before It Is a Configuration Problem
The vendor describes Litify as an AI-native legal software platform built on Salesforce, designed to run intake, matters, documents and reporting on one connected system. Litify's own positioning points to legal software as a leading platform of action. When more than one law firm shares that platform under one group, the platform stops being one firm's tool and starts being an operating agreement. That agreement is about what gets shared, what stays local, and who decides when the two layers collide. Litify governance, in other words, is not an IT concern; it is a business agreement expressed in software.
Think of the arrangement like a condominium building. The structural skeleton, plumbing and safety systems are shared and must meet one code; each firm's unit, its kitchen, furniture and daily routines, is designed by the people who live there. The building works because shared infrastructure is governed centrally and living spaces stay local. The same logic applies here. Each firm keeps its own edge in the unit, while the group maintains the shared infrastructure that makes the whole building work. Shared data model, naming conventions, reporting definitions and the security baseline are the skeleton. Intake rules, matter stages, templates and firm-specific integrations are the unit.
The failure mode is not choosing one side. It is leaving the split undefined. A group with two plaintiff firms may discover that "Client" means something different in each firm: one treats co-counsel as a client, the other treats them as a vendor. A group-level case count becomes meaningless without a shared definition. Meanwhile, an insurance defense firm and a plaintiff firm may share the same Salesforce org, but their matter stages ("Open," "Active," "Closed") map to different real-world states, so a portfolio report overstates open matters. This is not a configuration defect; it is a gap in Litify governance, and it will surface in every multi-firm Litify review that follows.
Platform governance starts with one principle before any technical decision in a multi-firm Litify estate.
Standardize what makes the group legible. Localize what makes each firm effective. Govern the line between them like it's the product.
Once we accept that multi-firm Litify is a governance problem, the next practical question is straightforward: what exactly goes in the shared layer, and what stays local? The next section turns that principle into a decision table across eight areas.
The Standardize-vs-Keep-Firm-Specific Split: A Decision Table
The table below is a proposed starting point for any multi-firm Litify program. The exact rows and owners should be agreed by the group, not copied from a blog post. What matters is that each area gets an explicit decision owner and a reason it belongs in the shared or local layer.
| Area | Decision | Owner | Why it belongs there |
|---|---|---|---|
| Data model (Client, Matter, Party, related objects) | Standardize | Central platform team | Makes group reporting and cross-firm comparability possible |
| Naming conventions (accounts, matters, contacts) | Standardize | Central platform team | Prevents duplicate entities and inconsistent names in group views |
| Reporting definitions and shared metrics | Standardize | Central platform team | A group KPI defined locally is an average of local opinions, not a group KPI |
| Security baseline and access control | Standardize | Central platform team | Protects firm records and reporting slices consistently across the group |
| Intake rules and qualification logic | Keep firm-specific | Firm-level owner | Reflects how each firm actually qualifies and wins cases |
| Matter stages and stage criteria | Keep firm-specific | Firm-level owner | Maps to how each practice defines active work; a group-level mapping can roll these up |
| Templates (engagement letters, demand letters, email) | Keep firm-specific | Firm-level owner | Matter and firm-specific language, tone and jurisdiction |
| Integrations (finance, conflict check, document storage, firm-specific tools) | Split by reach | Central for shared, firm for local | Shared integrations belong to the shared layer; firm-specific tools stay local |
The real power of this split is that it makes the shared layer compact. Only four areas need group-wide consistency: the data model, naming conventions, reporting definitions and the security baseline. Everything else can stay local without destroying cross-firm comparability, because the shared definitions alone give the group a common vocabulary. A plaintiff firm may want to add a new intake question and a new email template. That is a firm-level change, approved locally, no central review needed. But if a firm wants to add a new picklist value to the shared Matter Type field, that touches the group reporting definition and needs central review. That distinction is what keeps local speed from eroding group clarity, and it is the heart of multi-firm Litify design.
Integrations deserve a little more nuance. Shared integrations, such as finance, conflict check and document storage, sit in the shared layer because they touch every firm. Firm-specific tools stay in the firm layer, but they still need to exchange data with the shared core. That is where Salesforce integration services become the connective tissue between the two layers. When you need an independent read on whether the current multi-firm Litify split is actually being honored, what to look for in a Salesforce audit is a useful lens.
A clean split on paper still has to survive the reality that different firms may not even run on the same Salesforce org. That configuration choice changes what "shared layer" can mean in practice for any multi-firm Litify estate.
One Org, Many Orgs, or Something In Between: How Configuration Shapes the Split
The Salesforce org configuration is a legitimate design choice, not an accident. A single shared org makes the shared layer literal: one data model, one set of naming conventions and one security baseline are naturally enforced. But firm-specific isolation becomes a design problem you have to solve deliberately with sharing rules and permission sets. Separate orgs per firm make isolation easy, but the shared layer has to be enforced through a common reference data model, shared data standards and a group-level reporting layer rather than within one org. Hybrid setups, or a shared core org plus firm-specific satellite orgs, simply move the boundary; they do not remove it.
In every setup, integration becomes the connective tissue between the shared layer and firm layers. Application integration, in the general sense, is the wiring that lets separate systems exchange data and processes. Enterprise application integration extends that to coordinating many systems across an organization. That is exactly what a multi-firm Litify estate needs: firm-specific intake tools and shared core systems exchanging standardized matter records. Salesforce is positioned as a platform composite of apps, data and automation building blocks, which is what makes a shared-standards-plus-local-workflows architecture expressible in the first place. The platform provides the building blocks; the group still has to assemble them with platform governance. This is where a multi-firm Litify design either gets practical or stays theoretical, because the org shape determines how much of the shared layer is enforced by the platform and how much is enforced by convention.
A practical recommendation: do not pick the org configuration first. Pick the standardize-vs-local split first, then choose the configuration that best supports it. A plaintiff group that wants one data model but strong firm-level sharing might run a single shared org with firm-scoped sharing rules. A group that wants hard isolation between insurance defense and plaintiff practices might run separate orgs for each firm, then mirror the shared definitions into a consolidated reporting layer. A multi-firm Litify rollout in that shape still lives or dies on how well the shared definitions travel between orgs. When a configuration has drifted from its original design, a Salesforce org audit is a structured way to see the current reality before redesigning the split.
Once the configuration and the multi-firm Litify split are agreed, the next question is not "what should we build" but "who decides, and how do changes actually land across firms?"
Change Approval and Release Management Across Firms
Every group running Litify for multiple law firms needs a single front door for changes. Otherwise, admins receive a dozen informal requests from different firms, and the shared layer gets modified without anyone noticing. The fix is a simple change intake queue: every request enters the same place, whether it is a new field, a renamed stage or a report filter. Then apply tiered approval, which is the backbone of multi-firm Litify governance.
Low-risk changes that only affect one firm and do not touch the shared layer can be approved at firm level. Anything touching the shared data model, naming conventions, reporting definitions or security baseline requires central review. Without these tiers, either everything escalates or nothing does. Firm-local approval might cover a new intake question or a new email template. Shared-layer approval covers picklist value changes, new fields on the core client or matter objects, or modifications to a shared report definition. Consistent release management is what keeps the shared layer from drifting between firms. That discipline is a core part of multi-firm legal operations, not an administrative extra, and it keeps multi-firm Litify from slowly fragmenting.
Release coordination needs a simple, published calendar. A monthly or quarterly cadence is enough for most groups. The point is that firms can see what is coming, not that the cadence is elaborate. A five-step release calendar works well:
- Change intake closes at the end of the month.
- Central review and firm review happens during the review window.
- Build and test occurs in the release window.
- Each affected firm formally accepts the release.
- Go-live happens on the agreed date.
The acceptance step is what turns a release from an IT event into an operating agreement. Before a release goes live, each affected firm reviews it against a short checklist: Do my local dashboards still work? Are my matter stage mappings intact? Does this change affect my intake forms? Formal acceptance, logged and signed, prevents release-night surprises. A firm that discovers after go-live that its local dashboard broke because a shared field changed should have caught that in acceptance. Keep a rolling shared-layer change log too. When someone asks "when did the matter stage mapping change?", the answer should be in one place, not in five email threads. Inside any multi-firm Litify program, that single log is often the difference between controlled progress and quiet drift.
Releases land, and the platform moves forward. But the day the group actually sees itself is the day consolidated reporting runs on shared definitions and firm views stay within their own boundaries.
Reporting and Access Control: What the Group Sees vs What Each Firm Sees
Each firm should see its own matters, clients, people and financial data in detail, because that is where the actual legal work lives. The group should see consolidated views built on shared reporting definitions, so the group view is comparable across firms rather than a collage of local definitions. The boundary is not just about who can see what; it is about which metrics are defined where. A group KPI that is defined locally is not a group KPI; it is an average of local opinions.
Access control and reporting boundaries should be designed together. The same sharing model that protects a firm's records should protect its reporting slices. A group dashboard may show portfolio-level case counts, average time-to-file and firm-level roll-up, but no drill-through into named individuals at other firms. A firm-level dashboard shows named matters, stage aging and individual workload, using the shared metrics so the local numbers still reconcile to the group view. A documented escalation path handles cross-boundary requests, such as group finance asking for a specific firm's write-off detail. The request is logged, the firm's managing partner approves, and the group receives an anonymized or aggregated extract. That is what access control looks like when it is treated as an operating rule rather than a setting.
Consolidated reporting is the payoff layer. If the group got the standardize-vs-local split and the governance right, a consolidated view is almost a byproduct. That is the practical case for a governance-first approach to multi-firm legal operations. Without shared data standards, two firms can report different "time to file" averages simply because one counts first client contact and the other counts signed engagement. The fix is not a better dashboard; it is a shared definition. In a multi-firm Litify deployment, shared definitions are the reporting product.
With reporting boundaries defined, the remaining question is who runs the platform day to day, and how the group keeps both continuity and capacity as firms come and go.
A Proposed Operating Model for Multi-Firm Legal Operations
The following operating model is proposed, not universal. The right shape depends on the group's size and org configuration. But the roles should exist and be named, even if they are part-time.
Central platform team owns the shared layer: data model, naming conventions, reporting definitions and security baseline. This team runs the release calendar, the change intake queue and the shared-layer change log. In many groups it becomes the center of excellence for multi-firm legal operations.
Firm-level owners own the local layer: intake rules, matter stages, templates and firm-specific integrations. They represent the firm in central review when a change touches the shared layer, and they formally accept releases that affect their firm.
External delivery partner provides capacity for build, integration and release engineering, and works to the group's standards rather than introducing new ones. This is where Litify consulting, customization and integration services can plug into an existing operating model without changing its shape. The partner does not replace the central team; it gives the group a reserve of Litify-specific and Salesforce-specific engineering capacity when the internal team is stretched or when a complex shared-layer change is too risky to staff internally.
RACI-style clarity makes the model work: the central team is accountable for shared-layer changes, firm owners are accountable for local changes, and the delivery partner is accountable for delivery to the agreed standard. A small group of two affiliated firms may run this model with one part-time central platform lead and one firm-level owner per firm, working with an external partner for release engineering. A larger group with four firms across two Salesforce orgs might have a central team of three, firm-level owners per firm, and a partner managing the shared integration layer. The point is not the headcount; it is that the roles exist and are named. That shapes how a multi-firm Litify operating model survives leadership changes and firm additions.
When a new firm joins the group, the model should describe how it adopts the standard shared layer, inherits the release calendar and nominates a firm-level owner. That onboarding path is what keeps the group from renegotiating the split every time. For many Salesforce multi-org law firms, this step is also the moment when the hybrid architecture is tested, since the new firm arrives with its own org, data and habits. A multi-firm Litify operating model that cannot absorb a new firm cleanly is not finished, no matter how well it runs today.
Frequently Asked Questions About Multi-Firm Litify
What is the biggest mistake legal groups make when running Litify across multiple firms?
Leaving the shared-versus-local split undefined. Groups often try to force every firm into one workflow or let every firm customize freely without shared data standards. Both paths create fragmented data and conflicting reports. The fix is a deliberate multi-firm Litify governance decision about which layers are shared and which are local. Without that decision, a multi-firm Litify program drifts into local improvisation, and consolidated reporting becomes impossible to trust.
Should every firm in the group use exactly the same matter stages?
No. Matter stages should stay firm-specific because they reflect how each practice defines active work. What should be shared is a group-level mapping that rolls those local stages into comparable portfolio metrics, not identical stage names. This is a classic multi-firm Litify trade-off: local flexibility in stage design, shared consistency in how stages roll up to the group.
How do we decide between one shared Salesforce org and separate orgs per firm?
Start with the standardize-vs-local split. If you need one data model but strong firm-level isolation, a shared org with firm-scoped sharing rules and clear access control works. If you need hard separation, separate orgs plus a consolidated reporting layer may be better. For many Salesforce multi-org law firms, that hybrid path is the pragmatic middle ground. The configuration should follow the governance model, not the other way around. That principle holds in every multi-firm Litify design conversation.
Who should approve changes that affect the shared data model?
A central platform team should own approval for anything touching shared fields, naming conventions, reporting definitions or security. Firm-level owners can approve changes that only affect their own intake, stages and templates. This tiered approval prevents both over-escalation and uncontrolled shared-layer drift, and it keeps release management predictable across firms. It also keeps a multi-firm Litify platform from accumulating undocumented exceptions.
What does a release acceptance step actually involve?
Before a release goes live, each affected firm reviews the change against a short checklist: local dashboards, matter stage mappings, intake forms, and any firm-specific integrations. The firm then formally logs its acceptance. This turns a release from an IT push into an operating agreement. That is also the moment when a multi-firm Litify release becomes a firm-level commitment, not just a central team milestone, and it keeps release management honest across the group.
The Split Is the Product: Making Multi-Firm Litify Work Over Time
A multi-firm Litify program does not succeed when every firm gets exactly what it wants. It succeeds when the group decides in advance what will be shared, what will be local, and who decides when those layers collide. The standardize-vs-local split, the change tiers, the release calendar, the acceptance step and the reporting boundary are not a launch checklist. They are a repeated decision. That repeated decision, not a perfect configuration, is the platform, and it is what makes multi-firm Litify sustainable as firms grow, merge or change leadership.
The business implication is straightforward: the group that governs the shared layer well gets comparable numbers, faster onboarding of new firms, and fewer release-night surprises. The group that does not ends up with expensive dashboards that nobody trusts.
If you want to compare your current operating model against a delivery-ready one, covering the shared layer, change tiers, the release calendar and reporting boundaries, our Litify consulting, customization and integration services team can walk through it with you. If the underlying Salesforce architecture needs attention first, that is where Salesforce development services and our wider Salesforce delivery work come in. When you are ready, we can discuss a multi-firm Litify delivery model that fits your group.
Discuss a multi-firm Litify delivery model.
Loading...