Observability for MuleSoft–Salesforce Integrations: What to Log, Measure, and Alert On

A MuleSoft flow being UP does not mean a Salesforce integration is healthy. Production observability must describe whether business data is moving correctly and whether the system can recover when it does not.

Correlation first

Carry a correlation identifier from the inbound boundary through Salesforce calls and downstream operations. For event-driven flows, also capture the relevant event/replay identity and business record identifier.

Do not log access tokens, passwords, private keys, or unrestricted customer payloads merely to make troubleshooting easier.

Metrics by interaction type

Synchronous Salesforce operations

Measure request count, latency, success/failure rate, timeout/connectivity failures, Salesforce validation errors, and rate/limit pressure.

Bulk jobs

Measure jobs submitted/completed/failed, job duration, records attempted/succeeded/failed/unprocessed, and reconciliation backlog.

CDC / Platform Events

Measure events received, processing success/failure, processing latency, current checkpoint/replay position, redelivery/duplicate counts when detectable, and age of the oldest unprocessed work.

Business metrics matter

Technical success can hide data loss. Add metrics such as customers synchronized, opportunities rejected, or records waiting for reconciliation when they represent meaningful outcomes.

Structured logs

A useful structured event might contain:

{
  "correlationId": "c-8012",
  "integration": "customer-sync",
  "operation": "salesforce-upsert-account",
  "sourceId": "CUST-10482",
  "result": "VALIDATION_FAILURE",
  "retryable": false
}

Alert on symptoms requiring action

Avoid alerts for every isolated error. Better signals include sustained error-rate increase, growing event lag/backlog, repeated authentication failures, exhausted retries, bulk-job failure ratio, or no events/transactions when traffic is normally expected.