Your Firm Runs on the Phone. Litify Doesn't Come With One.

Litify manages the case. The phone call is where the case starts. Litify does not ship with a phone system, so every firm on it ends up connecting one, and usually several other communication tools alongside it.

‍

When those connections are missing or half-built, the gap fills with manual work:

‍

• Intake works in two systems. Agents dial in one place and log the outcome in another, or export call lists by hand and rebuild them the next morning.

• Marketing spends blind. Calls come in from a tracked campaign, cases get signed, and nobody can connect the two.

• Calls land on the wrong record. A logged call attaches to the previous intake instead of the one the agent is looking at, and the case history quietly goes wrong.

• Follow-up doesn't scale. Reminders and updates go out one at a time because there is no trigger doing it automatically.

‍

Connected properly, the phone stops being a separate system and becomes part of the case record.

How phone integrations work in Litify

Litify is built on Salesforce, so a platform with a Salesforce integration or an open API can usually be connected. In practice the work splits into four jobs:

‍

• Calling from the record (CTI). Agents dial from the intake or matter without leaving Litify, and the call logs itself against the right record. This runs through a CTI layer, and what you can build depends heavily on that layer rather than on Litify.

• Call tracking and attribution. The tracking platform knows which campaign produced the call. Litify knows whether it produced a case. Writing attribution fields onto the call record connects marketing spend to signed cases.

• Outbound messaging. Messages triggered by case stage instead of sent by hand. Tools in this space often have no native Salesforce integration, so these usually run through a middleware layer.

• Routing the reply. Getting a message out is straightforward. Making sure the response reaches the paralegal actually assigned to the case is the part that takes design.

Where these integrations break

• The middleware sets the ceiling, not Litify. What an agent widget will render, and which version of the connector the firm is on, can rule out a Lightning Web Component before you write a line of code. Call disposition fields inside a managed package may not be customizable at all.

• Heavy objects cause visible lag. An Intake object carrying years of automation and validation makes agents wait when you write call state to it directly. Allocation status belongs on a lighter custom object.

• Middleware connections fail quietly. Credentials time out, API access changes, and nobody gets an error. We have been called in on integrations that had been failing for a while before anyone noticed.

• Time zones are not cosmetic. Allocating an outbound call in the firm's time zone rather than the client's means agents call people at the wrong hour, or the queue skips them entirely.

• Field sizes bite in production. Tracking URLs carrying full campaign parameters run past 255 characters, which is the ceiling on a standard text field. A field that passes testing fails the first time a real campaign string arrives.

• Compliance is part of the build, not an afterthought. Where the dialer sits, what gets recorded, and what the client consented to all have to line up before you scale outbound volume. Consent and recording rules are the firm's call to make, but the integration has to be built so those decisions are enforceable rather than assumed.

ECHO experience: what we have built

A dynamic call queue for a large mass tort firm. Intake staff were exporting priority intakes out of Salesforce, importing them into Cisco, and building campaigns manually. Every list was stale on arrival. ECHO replaced it with a component inside the agent's Bucher + Suter widget that queries the highest-priority intakes live and dials from the record. At the time, the widget rendered only Visualforce, so that is what the component was built as. Because writing to the Intake object introduced delay, allocation state went to a separate custom object. Intakes are marked as allocated on retrieval, so two agents never get the same call.

‍

Call attribution for a personal injury firm. The firm's existing feed carried only first-touch attribution, which is the less useful half for a firm buying intake calls. ECHO built the piece that pulls last-touch data from the CallRail API onto the call record: a record-triggered flow, an Apex callout authenticated through External and Named Credentials, a permission set so the integration user can actually make the callout, and fourteen mapped fields. Marketing source now sits next to case outcome and can be reported on together.

‍

SMS that reaches the right person. We reworked an existing SMS widget at a mass tort firm so intake and matter conversations stay separate, and messages surface only for the paralegal or team leader assigned to the case.

‍

Scheduled messaging at volume. Outside legal, we built a Twilio-based notification system for a nonprofit whose trainers kept missing email reminders. Scheduled jobs with a queueable architecture to stay inside platform limits, duplicate-message prevention, and message content held in custom settings rather than code. It now sends over 400 messages a month at a 99 percent delivery rate. The same pattern applies to a firm sending stage-based client updates.

‍

Running it ourselves. ECHO runs Aircall, an ECHO partner, for its own telephony. Not a client integration, but it means we run the same CTI, call logging, and reporting decisions on our own org before we scope them for anyone else.

‍

What your firm gets out of this

• Agents dialing from the record instead of exporting lists to a dialer

• Calls logged against the correct intake or matter, every time

• Marketing attribution that survives all the way to signed cases

• Messages triggered by case stage instead of sent by hand

• Integrations that alert you when they break, rather than failing quietly for a month

The 2028 deadline most firms have not planned for

Open CTI, the JavaScript API that most third-party phone integrations have run on for over a decade, is in maintenance mode and retires on February 28, 2028. It is already unavailable for newly created Agentforce Service orgs. Salesforce is pointing everyone at Salesforce Voice instead, and the major connector vendors have published migration paths.

‍

If your dialer sits inside Salesforce today, that transition is a project rather than a version upgrade. It touches how calls are logged, how data flows onto the matter, and what your reporting is built on. That runway closes on February 28, 2028 - sooner than it sounds for a firm running intake at volume.

Where this is heading

Past the migration, the interesting question is not which phone system to buy. It is what happens to the call after it ends: automatic client lookup on inbound calls, intelligent routing, and AI transcribing, summarizing, and tagging calls without anyone typing a note. The major platforms are shipping these features now, and the Salesforce side is following, with call logging starting to carry AI output as structured data rather than plain activity records.

‍

Our view is the same as with every other integration. The AI feature is only as good as the data model underneath it. A call summary that lands on the wrong matter is worse than no summary, which brings you straight back to the unglamorous work of making sure the call attaches to the right record.

Not sure what your phone stack is actually doing in Litify?

Get a free Salesforce audit. It's the fastest way to get our team's eyes on your setup, and the right place to start the conversation about your call and messaging integrations, and where Open CTI leaves you.

‍