Skip to main content
Zentium Technologies
Case study

Rebuilding integrations that were silently losing records

A set of synchronous, fire-and-forget callouts rebuilt as resilient, observable interfaces with retry, idempotency and reconciliation reporting.
Client
Confidential — financial services
Published
February 10, 2026

0

Records lost after remediation

Minutes

Time to detect an integration failure

Bulk-safe

Callouts removed from the save path

Challenge

What was going wrong

Salesforce pushed records to a downstream platform through synchronous callouts inside triggers. When the downstream service was slow or unavailable, the callout failed and the record was never retried.

Nobody knew how many records had been lost, because there was no integration log and no reconciliation process. The gap only surfaced during a quarterly review.

Callouts inside loops were also pushing the org close to governor limits during bulk operations.

Approach

How we built it

  • 01

    Measure the damage first

    A reconciliation job compared both systems to quantify the divergence before anything was changed, so remediation could be prioritised against actual impact.

  • 02

    Move to asynchronous, event-driven delivery

    Synchronous trigger callouts were replaced with platform events consumed by a queueable dispatcher, removing integration failure from the user's save path.

  • 03

    Retry and idempotency

    Every outbound message carries an idempotency key. Failures are retried with exponential backoff and land in a dead-letter object after the retry budget is exhausted.

  • 04

    Observability

    Structured integration logging with a failure dashboard and alerting, so an outage is visible within minutes instead of at quarter end.

Architecture

How the pieces fit together

  1. Platform events published from a single trigger handler per object

  2. Queueable dispatcher performing bulkified callouts via named credentials

  3. Idempotency keys preventing duplicate downstream writes on retry

  4. Exponential backoff with a dead-letter object for exhausted retries

  5. Scheduled reconciliation job comparing record counts and checksums across systems

  6. Integration log object driving a failure dashboard and alert rules

Stack

  • Platform Events
  • Queueable Apex
  • Named Credentials
  • Dead-letter object
  • Scheduled reconciliation
  • Integration logging

Services involved

Start here

Recognise this problem in your own org?

Send us the details. We will tell you whether it is a configuration fix, an architecture problem, or something you can solve without us.

Get a proposalEmail us directly

24/7 support — response within one business hour