Architecture in production.

The problem

The organisation had accumulated over two million Contact records across three merged business units, with no consistent identity resolution strategy. Duplicate contacts were causing incorrect service histories, failed marketing suppressions, compliance reporting errors, and agent confusion at the point of interaction. Multiple previous attempts to fix the problem through scheduled batch jobs had introduced data loss and partial merges that made the underlying model worse.

The architecture

We designed a deterministic identity resolution layer using a custom matching rule engine built on Apex, scoring contacts across email, phone, name variants and address normalisation. Matches above a confidence threshold were surfaced to a stewardship queue for human review before merge execution. The merge itself was implemented as a controlled Queueable chain to respect governor limits at scale, with full audit trail written to a custom object before and after each merge. Downstream systems were notified of canonical ID changes via Platform Events to prevent reference breakage.

The problem

Access and relationship changes made in Salesforce — role assignments, account ownership transfers, contact deactivations — needed to propagate to a downstream enterprise user management and identity platform. The existing mechanism was a nightly scheduled batch. Any change made during the day was invisible to the downstream system until the following morning, creating access control gaps, compliance exposure, and operational friction for the security team who were managing exceptions manually.

The architecture

We replaced the batch with a Platform Event-driven integration. Salesforce triggers and Flow published change events to a custom Platform Event on every relevant record change. A Java subscriber service consumed these events from the Pub/Sub API, validated and transformed the payload, and called the downstream User Management API with idempotency keys to ensure exactly-once semantics. The subscriber was designed with a replay buffer supporting 72-hour event replay for outage recovery, and all events were logged to an audit store with correlation IDs for traceability.

The problem

The Service Cloud org had been in production for six years across four different implementation vendors. The automation layer had grown into an unmaintainable tangle — 34 active Flows, 11 Apex triggers across the Case object, and 40+ legacy workflow rules, many of which overlapped or contradicted each other. Any change to case handling required weeks of regression testing and still produced unexpected side effects in production. Agent console load time had degraded past eight seconds. The team had stopped making changes.

The architecture

We began with a full automation audit, mapping every trigger, Flow and workflow rule to its business intent and identifying redundancy, dead code and conflicts. We then consolidated the automation into a single Apex trigger-per-object following the handler pattern, replacing eligible Flows with bulkified Apex logic and retiring all legacy workflow rules. Case routing was redesigned using Omni-Channel skills routing with a clean escalation path. The console was rebuilt with lazy-loaded LWC components and a shared data service layer to eliminate duplicate SOQL.

The problem

Customer service agents were handling calls through a standalone Twilio-based telephony system entirely disconnected from Salesforce. After every call, agents manually searched for the customer record, typed call notes, updated the case status and logged a completed activity. This process took an average of four minutes per interaction and was error-prone — notes were incomplete, cases were linked to wrong contacts, and call data was unavailable for reporting. Management had no visibility into call volumes, durations or outcomes in Salesforce.

The architecture

We built a bi-directional integration using Twilio Programmable Voice and the Salesforce Open CTI framework. Incoming calls triggered a screen pop in the agent console via Open CTI, matching the caller's number to a Contact or Lead using E.164 normalisation and fuzzy fallback. Call events from Twilio — initiated, answered, completed, transferred — were published to Salesforce via a secure webhook endpoint built as a Salesforce External Service, creating real-time Task records with duration, disposition and recording links. Twilio Studio handled IVR routing and passed context to Salesforce before the agent answered. Post-call, Einstein Conversation Insights summarised the transcript and pre-populated case fields, reducing wrap-up time.

The problem

The contact centre was running Twilio Flex as its telephony platform and Salesforce Service Cloud as its CRM, with no integration between the two. Agents were manually logging call notes after each interaction, creating data quality issues and adding 4-6 minutes of after-call work per interaction. There was no screen pop on inbound calls, no automatic case creation, and no supervisor visibility into live call activity from within Salesforce. Leadership had no unified view of contact centre performance tied to CRM outcomes.

The architecture

We designed a bidirectional integration using Twilio Flex Plugins for the agent interface and a middleware layer on Twilio Functions to handle event orchestration. Inbound calls triggered a Twilio Function that queried Salesforce via the REST API to match the caller by phone number, then published the matched contact and open cases to the agent screen via a screen pop built in LWC. Call events — answered, transferred, completed — were published to Salesforce via Platform Events in real time. On wrap-up, call metadata including duration, recording SID and disposition was written to a custom Activity record linked to the Contact and Case. A Supervisor dashboard was built in Salesforce using real-time Platform Event subscriptions to show live queue depth, agent status and CSAT trends.