Context

A retail bank moved loan origination onto Salesforce. Four systems already held the truth and none of them were going away: the core banking platform, Docuware for the document archive, the online banking channel, and I2C for card issuing and validation. The loan officer was expected to work all four from one screen.

Constraint

Card validation had to be authoritative at the moment of the decision, not eventually consistent. At the same time Salesforce could not quietly become a second copy of the bank's customer and balance data, because a stale figure inside a lending decision is a compliance finding, not a bug.

Options weighed

• Synchronous Apex callouts for everything. Quickest to stand up. Every downstream hiccup becomes an error in front of a customer, and every screen change turns into an Apex deployment.
• Replicate the four sources into Salesforce and read locally. Fast screens, but it makes Salesforce a second system of record and puts stale data in a regulated decision.
• Split the traffic by criticality. Orchestrate the authoritative, low-volume calls synchronously. Push everything bulk or delay-tolerant to asynchronous.

What I built

• OmniScripts for the origination journey, step validation included.
• Integration Procedures orchestrating the synchronous path across core banking and I2C.
• Data Mappers for each transformation, so payload changes stay declarative.
• Apex callout layer with timeout handling, retries and faults translated into a message an officer can act on.
• Permission and sharing model for the lending team.

Outcome

• Four production integrations serving one Salesforce front end: core banking, Docuware, online banking and I2C.
• Loan officers work a single guided journey instead of switching between four systems.
• Payload changes are handled in Data Mappers, without an Apex deployment.

Context

A Health Cloud implementation needed clinical records from the hospital systems the client already ran: CERNER and EPIC. Care teams wanted the record in the Salesforce console; the electronic health record stayed the clinical source of truth.

Constraint

Protected health information changes the shape of every choice. Copying clinical data into Salesforce widens the compliance surface and creates a second version of a patient record. Two vendors also means two implementations of the same standard, so the integration could not be written twice.

Options weighed

• Batch replication of clinical data into custom objects. Familiar and easy to report on, but it duplicates PHI and the copy is wrong the moment the chart is updated.
• A vendor-specific integration per EHR. Fastest for the first hospital, then the second one doubles the code and the maintenance.
• Read on demand against the FHIR standard, one client for both vendors. More upfront design, no PHI at rest in Salesforce, and vendor differences isolated behind the standard.

What I built

• SMART on FHIR authorization and the FHIR resource client in Apex.
• An adapter layer absorbing the differences between the CERNER and EPIC implementations.
• Lightning Web Components rendering clinical resources inside the Health Cloud console.
• The Patient 360 engagement console, combining standard Health Cloud components with custom LWC.

Outcome

• EHR exchange live with two different vendor systems, CERNER and EPIC, through a single standards-based integration.
• No clinical data persisted in Salesforce, so the compliance surface stayed with the EHR.
• Care teams get a Patient 360 view without leaving Salesforce.

Context

Customer data sat in separate systems with no agreement on who was who. The business wanted to spend its marketing budget on the customers who were actually worth it, which meant one profile per person first and metrics second.

Constraint

Identity resolution is a business decision disguised as a technical setting. Match too loosely and two people merge into one profile, so the metrics lie and someone gets another person's offer. Match too strictly and the same person stays split, so lifetime value is understated everywhere. Both failures are invisible in a dashboard until someone complains.

Options weighed

• Deduplicate inside the CRM with matching rules. Cheap and familiar, but it only sees CRM records and it destroys the source rows it merges.
• Aggressive fuzzy matching in Data Cloud. Produces the tidiest profile count, and quietly merges distinct people.
• Ranked deterministic rule sets, source data left intact. Match on strong identifiers first, then progressively weaker ones, with each rule reviewed against real records.

What I built

• Data streams and ingestion from the source systems into Data Cloud.
• Transformations and the data model mapping onto data lake and data model objects.
• Identity resolution rule sets, ranked from strong to weak identifiers.
• Calculated Insights for lifetime value and RFM style recency, frequency and monetary metrics.
• Segments built on the unified profile for marketing activation.

Outcome

• One unified customer profile replacing fragmented records across source systems.
• Lifetime value and RFM metrics available as Calculated Insights for budget and marketing decisions.
• Source data preserved, so identity rules can be revised without a recovery project.

Context

Large trigger handler classes had accumulated years of business logic. Order of execution was implicit, responsibilities overlapped, and performance suffered under volume. Every change carried the risk of breaking something unrelated, which is the point where a team stops shipping.

Constraint

The business could not stop while the code was cleaned up, and none of the existing behaviour was allowed to change. A rewrite that is correct but arrives in nine months is not a solution to a delivery problem.

Options weighed

• Leave it and optimise the worst queries. Buys a quarter, and the next feature puts the risk right back.
• Rewrite the automation declaratively in Flow. Attractive on paper, but this logic needed bulk-safe iteration and complex branching that belongs in Apex.
• Refactor incrementally toward single-responsibility classes behind a stable entry point. Slower to feel finished, safe at every step.

What I built

• One trigger per object, delegating to a handler with an explicit execution order.
• Business logic split into single-responsibility classes, bulkified, with test coverage per class.
• Query and loop rework to bring the heavy paths inside governor limits under volume.
• Einstein Case Classification configured and trained on historical cases.

Outcome

• Trigger logic restructured to SOLID single-responsibility classes with explicit execution order.
• Performance improved on the heavy paths that were hitting limits under volume.
• Case classification handled by a model trained on the client's own history instead of a maintained rule list.

Context

Vehicle distributors needed insurance pricing from HDI Seguros while the customer was still at the desk. The carrier exposed a SOAP API. The sales team was working in Salesforce and did not want a second tab.

Constraint

A quote is only useful if it is current, so caching prices was not an option. That puts a third party API on the critical path of a live conversation, which means the failure modes matter as much as the happy path.

Options weighed

• Embed the carrier portal in an iframe. No integration work, and no data back in Salesforce, no audit trail, and a jarring experience.
• Nightly rate import and quote locally. Fast and offline-capable, but the number shown to the customer can be wrong.
• Live callout from Salesforce with the response surfaced in a component. Real work on error handling, correct number every time.

What I built

• Apex service consuming the HDI Seguros SOAP API, with request building and response parsing isolated.
• Error and timeout handling that returns an actionable message to the salesperson.
• Lightning Web Component for quote entry and results, embedded in the sales flow.
• Named Credential based authentication, so no endpoint or secret sits in code.

Outcome

• Real-time carrier quoting inside Salesforce, no second system for the sales team.
• Carrier protocol details contained in one Apex service, so the UI can change without touching the integration.
• Quotes captured against the Salesforce record, which the portal approach would not have given.

Context

Customers running Openbravo ERP alongside Salesforce kept paying for the same integration: accounts, contacts and orders in both directions. The company wanted to stop selling it as a project and start shipping it as a module.

Constraint

A product has a harder brief than a project. It has to work in an org the author has never seen, survive an upgrade on either side, and be installable by someone who was not in the design meetings. Bidirectional sync also raises the question every such integration has to answer: when both sides changed the same record, who wins.

Options weighed

• Per-client custom integration. Highest margin on the first sale, and a maintenance liability that grows with every client.
• Middleware between the two systems. Clean separation, and a third licence and a third thing to operate for a mid-market buyer.
• A packaged connector with configuration instead of code. More design work upfront, one codebase for every customer.

What I built

• Bidirectional sync for accounts, contacts and orders between Openbravo ERP and Salesforce.
• Apex integration layer on the Salesforce side, Java on the ERP side.
• Connected App and OAuth authentication, with no stored customer passwords.
• Configurable field mapping and per-object conflict rules, so a new customer is set up rather than coded.

Outcome

• Shipped as a commercial module, not a per-client build. One codebase served every customer.
• New deployments became a configuration exercise instead of a development project.
• Designed and built end to end, from the integration contract to the packaging.