What Salesforce Shows You

Module 7 of 9 in the chapter Reliability, Recovery, and Observability, chapter 14 of the Integration Architect course. Each module stands on its own. Previous: Escalation and Recovery · Next: Reporting

The question this module answers: When you’re watching an integration, what does Salesforce itself let you see, where, and for how long?

Your Log, and Theirs

Modules 2 to 6 built your own record: the integration log, the to-do list, the receipts, the alerts. That’s the part only you can build, because only you know what should have happened: which partner, how many statuses, by when.

Salesforce keeps its own record too, of what did happen inside the org: every API call, every flow that failed, every callout and how long it took. When I teach this, I put it simply. On incoming calls you have your debug logs. On outgoing, you have Event Monitoring, maybe event handlers, maybe third-party tools. You need both views, yours and the platform’s. Neither is enough on its own.

This module is a map of the platform’s view, organized the way you’ll use it: by the question you’re trying to answer.

Question by Question

Click to enlarge

Where to look, by question.

Did the Automation Fail?

For flows, the first stop is the Monitor tab in the Automation app, where “The Error Details column shows you the reason for a failed flow interview” (Monitoring and Managing Paused and Failed Flow Interviews (opens in a new tab)). Chapter 4 walked through it, along with the error email and who receives it (chapter 4 module 6).

One line on that page matters a lot for integrations: “For bulk transactions that include Apex Actions, failed flow interviews show the first record’s details instead of the details for the record that caused the failure.” Think about Redrock’s evening manifests, loaded as a set, firing a flow on each Work Order. If one record fails, the Monitor tab may point you at the first record in the batch, not the one that broke. That’s another reason for your own log, with the business key of every record (module 2).

How Much of the Allowance Is Left?

Chapter 8 covered the meter: the Sforce-Limit-Info header on every REST response, the /limits call, System Overview, and API Usage Notifications, which email someone when usage passes a percentage you choose (chapter 8 module 7). For monitoring, the point is: set a notification before you need it, and watch the trend, not just today. An allowance that’s 60% used today and was 40% used three months ago is telling you something about next quarter.

Who Called, How, and How Long Did It Take?

This is Event Monitoring: Salesforce’s event log files, one type for each kind of activity. For an integration architect, a handful of the event types matter most: REST API, Bulk API 2.0, API Total Usage, Apex Callout, Flow Execution, and two for composite calls, Composite API and Composite API Subrequest (EventLogFile Supported Event Types (opens in a new tab)).

How long they’re kept depends on what you’ve turned on. Salesforce’s own words: “API-enabled organizations have access to the API Total Usage event log files for the previous 24 hours.” With Event Monitoring, every event log type is kept for 30 days, and that can be extended to a year in Event Monitoring Settings or through the EventSettings Metadata API (Salesforce Help 005321531 (opens in a new tab), checked 2026-11-07). So one day for free, for one type; a month by default with Event Monitoring; up to a year if you extend it.

Anything older is gone, unless you copied it out. The Data Architect course makes the case for sending these logs to your own long-term store before you need them; I won’t repeat it, but I agree with every word (Protect, Retain and Prove).

The Composite Call That Succeeded

Here’s one worth knowing. Chapter 10 sent Redrock’s evening manifests as a Composite request, many records in one call. A composite call can come back as a success overall while one of its parts failed. If you only watch the overall call, you’ll never see the part.

Salesforce logs the parts separately. In its Object Reference: “One composite API subrequest event is generated for each subrequest or collated set of subrequests.” Each has its own SUCCESS field, “True if the subrequest call succeeded.” So the overall call can say success, and one of its subrequest events can say false.

Click to enlarge

Watch the parts, not only the whole call.

Your integration layer should be checking each part’s answer anyway (chapter 10 module 6). The subrequest events are how you check that it does.

How Fast Is It, Really?

Exam objective MNT-1 asks you to identify performance monitoring needs. Averages hide the problem: an integration that answers in a quarter of a second on average can still have one call in twenty that takes eight seconds. Salesforce’s Reliability guide says to measure latency “at p50, p95, p99 (set SLO per integration based on timeout budget)”: the time half the calls beat, 95 out of 100 beat, and 99 out of 100 beat. Then set a target for each integration that fits inside the timeout you chose in module 4. The same guide sums up what to watch: “error rate, latency, and circuit breaker state.”

The event logs give you the durations. Your own log gives them too, with the business meaning attached. Module 8 turns them into reports.

And when the slowness is the org itself, under load: Scale Center. Salesforce describes it as a way to “Diagnose root causes and act on scale issues earlier in your development cycle”, and it’s “a free product in full sandboxes and production orgs for all Unlimited Edition (UE), Enterprise Edition (EE), Professional Edition (PE), Signature, and Scale Test customers” (Scale Center (opens in a new tab)). It’s not available everywhere, though: “not available in the EU Operating Zone or Government Cloud Plus.” Check before you plan on it.

The Normal-Looking Call That Isn’t Normal

Chapter 13 ended with a promise: this chapter would take the watching. Remember the three doors from 2024 to 2026. In every case, the data left through API calls that looked legitimate: a real app, a real token, a real user (chapter 13 module 3). No error. No failure. Nothing in your integration log would look wrong.

So how would you notice? By knowing what normal looks like, and spotting the call that doesn’t fit. Salesforce does some of this for you. Threat Detection “uses statistical and machine learning methods to detect threats to your Salesforce org,” and among what it looks for are “Anomalies in how users make API calls.” You see its findings “in the events with Threat Detection in Event Monitoring,” and because those events “are compatible with transaction security policies and flows,” a policy can notify someone the moment one appears (Threat Detection (opens in a new tab)).

And here’s where an earlier design decision pays off again. Chapter 13 said one integration, one identity. That’s also what makes “normal” measurable. If Redrock’s integration user always reads Work Orders, a few thousand a day, from the integration layer’s addresses, then the day it exports every Account is an anomaly anyone can see. If five integrations share one user, there’s no normal to compare against. A shared identity hides the attack inside everyone else’s traffic.

What Happened Across Every System?

Salesforce can only show you Salesforce. A call that went from Redrock to the integration layer to Salesforce and back passed through three logs, and you want to read them as one story.

Module 2 did this by hand: one ID that every layer writes down. There’s now a standard way to do it. The W3C Trace Context recommendation defines a header, traceparent, that “describes the position of the incoming request in its trace graph in a portable, fixed-length format.” Every system that receives it passes it on, so one request can be followed through every hop. OpenTelemetry, the open-source project most monitoring tools now support, uses it, and its HTTP conventions were “the first OpenTelemetry semantic conventions to be declared stable,” in November 2023.

Most integration platforms can create and pass trace IDs for you. Where the call passes through your own Apex, log the ID you were given, and send it on with your callouts. And whatever your middleware’s own dashboard shows, the questions in this module still apply to it.

Test knowledge. Know what’s monitored where (MNT-1): failed flow interviews on the Automation app’s Monitor tab; the API allowance through /limits, the Sforce-Limit-Info header and API Usage Notifications; API activity in Event Monitoring’s event log files, with API Total Usage free for 24 hours and other types kept 30 days (up to a year) with Event Monitoring; a composite request’s parts in Composite API Subrequest events; scale problems in Scale Center; anomalous API use through Threat Detection.

Beyond the exam: what AI changes. Event log files are big, flat and hard to read, which makes them a good job for AI: “which integration user’s REST calls got slower this week?”, “which subrequests failed yesterday, and what did they have in common?” Ask it to work from the logs you’ve exported, and check its counts against the source before anyone acts on them. And the anomaly question cuts both ways: agents calling your APIs are callers too, and they need their own identities and their own normal, for the same reason.

What an Architect Decides Here

• Which platform signals each integration needs, question by question, alongside your own log.
• Event Monitoring: which event types, how long they’re kept in Salesforce, and where they’re copied for longer.
• The performance targets for each integration, at p95 or p99, inside its timeout.
• How a composite call’s parts are checked, in the integration and in the logs.
• What “normal” is for each integration identity, and who’s notified when Threat Detection or a policy finds something that isn’t.
• The trace ID that follows a call through every system, and that your own Apex passes on.

Explore

• Salesforce Help, 005321531: API versions 31.0 through 40.0 retirement (opens in a new tab): includes the API Total Usage log and Event Monitoring retention (checked 2026-11-07).
• Object Reference, EventLogFile Supported Event Types (opens in a new tab) and Composite API Subrequest Event Type (opens in a new tab) (checked 2026-11-07).
• Salesforce Help, Scale Center (opens in a new tab) and Threat Detection (opens in a new tab) (checked 2026-11-07).
• W3C, Trace Context (opens in a new tab) (Recommendation, November 2021), and OpenTelemetry, HTTP semantic conventions declared stable (opens in a new tab) (November 2023) (both checked 2026-11-07).
• Protect, Retain and Prove: the Data Architect course, Event Monitoring retention and keeping logs longer.
• Salesforce Help, Monitoring and Managing Paused and Failed Flow Interviews (opens in a new tab), checked 2026-11-07.