Configuring Case Xchange as a Receiving Firm in Salesforce/Litify

Summary

Configure the Case Xchange–Litify integration so your firm receives referrals automatically and syncs status and field updates back to Case Xchange. This guide walks through the full receiving-firm setup: planning your configuration, preparing your Salesforce/Litify fields, enabling CX Intake records, and building the flows that move data in both directions.

Before you Begin

These steps reflect the Case Xchange managed package v3.7. You'll need Firm Admin or Account Manager access in Case Xchange, plus Salesforce admin access. If your org is on the Litify Bridge package, several of the fields below may already exist; confirm before creating. 

 Plan your Configuration

Decide the following before you build anything. These choices shape every flow later in the guide.

• Receiving object — which object your team should receive new referrals on.
• Update-source objects — which object(s) status and field updates should be sent back from, and the path a referral travels across them. Example: Intake → Matter.
• Trigger points — when each status or field update should fire back to Case Xchange (for example, on a stage change, or when a settlement amount is entered).
• Firm-tracking object — which object stores the originating (sending) firm, so inbound referrals can resolve to it.

Step 1: Configure Objects/Fields

Confirm or create the fields let the integration match inbound referrals to the correct records in Salesforce/Litify.

Fields To Keep In Mind:

• Referral link — on each object you'll map updates back from, add a lookup field linking the record to its originating CX Intake, or a text field that stores the CX Reference Number/ID. This is what lets a status or field update resolve back to the correct Case Xchange referral.
• CX Firm ID — on the Firm object, create a unique External ID text field that stores the originating firm's Case Xchange firm ID. When an inbound referral arrives, Salesforce uses this field to match it to the correct Firm record.
• CX Case Type ID (only if using the Litify Case Type object) — create a unique External ID text field that maps each Litify Case Type to its Case Xchange equivalent, so inbound referrals resolve to the correct case type.

Step 2: Enable CX Intake records in Case Xchange

1. In Case Xchange, go to Settings → Integrations.
2. Click Manage next to the Salesforce integration.
3. Enable Create CX Intake Records.

Case Xchange will now create a record on the CX Intake object each time a referral is acknowledged.

What the CX Intake record stores. Each CX Intake is a flat object (all fields are text except dates) and holds the referral's core data from Case Xchange, including CX Firm ID (the sending firm's ID), Sending Firm Name, and CX Reference Number. 

Step 3: Build your flows in Litify

With your fields in place and CX Intake records enabled, the rest of the setup happens in Litify. This is where you decide how referrals move through your org: how new referrals become working records, and how your team's updates flow back to Case Xchange. Details outlined below are recommendations based on a standard Litify setup. The package is designed to be customizable based on a firms individual processes. 

Receiving a new referral

Option A — Review before creating a downstream record

Choose this if your intake team wants to accept or reject each referral directly from the CX Intake record, and only create a working record for the ones they accept.

Example: When a CX Intake record is created, a team member reviews it and accepts or rejects it from that record. On accept, a new record is created on the appropriate object to manage the referral. On reject, the referral is updated back in Case Xchange.

1. Create a record-triggered flow that runs on update of the CX Intake record. When the record is marked accepted, create a record on the correct target object.
2. In the same flow, when the record is marked rejected, use the Update Referral Status action with status = rejected to set the referral's status back in Case Xchange.

Option B — Create the downstream record automatically

Choose this if every inbound referral should flow straight through to your working object with no manual review step.

Example: When a CX Intake record is created, a Litify or intake record is generated automatically.

1. Create a record-triggered flow that runs on create of the CX Intake record, generating a record on the correct target object.

Sending status and field updates back to Case Xchange

Map which object and which change should fire each update. Because your team may work a referral across more than one object, build a separate flow on each object that needs to push updates back — each watching for the specific change that should sync.

Before building, decide for each object:

• What change triggers an update? A status/stage field reaching a value, a financial field being populated, a date being set, and so on.
• Is it a status update or a field update? These use different actions and follow different rules.
• How does the flow find the referral? Every update needs the referral identifier. Use the lookup field from Step 1 to retrieve the linked CX Intake (or the stored CX Reference Number) and target the correct referral.

Structure each flow using this pattern:

1. Set the trigger. Run the flow on update (or on create), with entry conditions narrowed to only the change that should sync. Tight entry conditions keep the flow from firing on unrelated edits.
2. Use the Case Xchange Case/Reference ID. Use the lookup or stored ID from Step 1 to identify the Case Xchange referral this record maps to.
3. Add the correct update action (status or field — see below).
4. Run asynchronously. Don't block the user's save on the callout to Case Xchange. Use an asynchronous path so the API call runs after the record commits.

Status updates

Trigger a status update when a change should move the referral forward in Case Xchange, based on the Intake or Matter's progress in Litify. Case Xchange enforces the order below — you can't skip states. 

Case Xchange status values 

Values Map & Validation

Case Xchange closing sub-status values (the closingStatus input; set when status = closing)

Technical Notes on Flow Design

Using managed actions to trigger status updates

• Investigating, Signed, In Litigation, Closing (Lost or Dropped), Closed, Rejected, and Withdrawn — use the Apex action Update Referral Status (CaseXchange), passing status (and closingStatus / closureReason where applicable).
• Closing → Won/Settled — The settlement amount and fees must already be on the referral when the status transitions. To do this,  use the Case Xchange: Update Referral subflow first, which patches detail fields and transitions status in a single operation. Then trigger the status update. 
• For all closing statuses — set every required field to avoid validation errors. We recommend adding field validation where necessary to prevent sync failures.

Field Updates & Field Formatting Validation Requirements

Use field updates when case details (financials, dates, notes) change on the local record and should reflect back to the referring firm.

Use the Apex action Update Received Referral (CaseXchange), passing the referral identifier and only the fields that changed — it's a partial update, so any field you leave out stays as-is. Input variables are outlined in the next section. Important field formatting notes are below. 

• clientFeeAgreementPercentage is a decimal between 0.00 and 1.00 (e.g., 0.33 for 33%).
• sendingFirmPercentage is a whole number between 0 and 100.
• Date fields use ISO 8601 date-time format.

Case Xchange action input reference for the actions mentioned in this guide: 

Update Received Referral (CaseXchange) — Apex action

Field updates only. All inputs except id are optional.

Outputs: isSuccess, referral (CX_ReceivedReferralDetail), error.

Update Referral Status (CaseXchange) — Apex action

Transitions a referral to a new status. In v3.3 this action does not carry financial fields — set those via Update Received Referral or the subflow.

Outputs: isSuccess, referral (CX_Referral), error.

Case Xchange: Update Referral — subflow (Autolaunched Flow)

Updates status and/or detail fields in a single operation. Included / Not Included toggles; only toggled-on fields are sent. If Status is provided it transitions the referral; if detail fields are provided it patches them.

Outputs: Succesful_Update (Boolean — system spelling, one "s"), Error_Message (Text).