Reporting

Module 8 of 9 in the chapter Reliability, Recovery, and Observability, chapter 14 of the Integration Architect course. Each module stands on its own. Previous: What Salesforce Shows You · Next: Resilience to Releases

The question this module answers: Once an integration is live, which reports does it need, who reads each one, and where do the numbers come from?

Reports Are for Trends and Proof

Module 6 was about alerts: something is wrong now, someone has to act. Reports are different. They answer the questions nobody asks at two in the morning: Is this integration getting better or worse? Are we keeping our promise to Redrock? Will we run out of API allowance next quarter? Did every status we published arrive?

The exam calls this the reporting needs for integration monitoring. I’d put it this way: an alert tells you about a failure; a report tells you about the integration.

And the simplest version is one I’ve always liked. Put the log in a custom object, give it a tab, and an admin can see it on a list view or a report. That’s the nice thing about keeping the log on the platform: you get the power of the platform to work with. Everything in this module builds on that.

Who Reads Which Report

The first design decision isn’t the chart. It’s the reader. Different people need different numbers, at different times, and a report built for everyone usually serves no one.

Click to enlarge

Start with the reader, not the chart.

• The person on call, every morning. What needs attention today: open failures in the to-do list, how old the oldest one is, how deep the queue is, how many messages are still waiting for a receipt.
• The integration’s owner, every week. How the integration is trending: error rate, latency, retries, volume. Is anything slowly getting worse?
• The business, every month. Whether the promise is being kept: what share of statuses reached the partner on time, and what happened to the rest.
• The partner, on a schedule you agree. What you sent and what they confirmed, so both sides can reconcile and agree on the numbers.
• Capacity planning, every quarter. How much of the API allowance and storage the integrations use, and whether the growth matches the forecast.

The Measures That Matter

A handful of measures cover most of it. Salesforce’s Reliability guide names several of them, with targets.

• Volume. How many calls, messages or records per day, per integration. Compare it with what you sized for: chapter 6’s Number of Zeros, and the growth you planned (chapter 6 module 3). Steve Trucking planned for 30% a year. If the volume is growing faster, the design’s limits arrive sooner.
• Error rate. The share of calls that fail. The guide gives a target: “<1% for healthy integration.” And it suggests comparing like with like: “Error rates elevated compared to same-time-last-week baselines catch gradual degradation before a threshold breach occurs.” A Monday morning compared with last Monday morning, not with Sunday night.
• Latency, at p50, p95 and p99 (module 7), against the target you set inside the timeout.
• Completeness. Sent against confirmed: the receipts from module 5. This is the one that proves the integration did its job.
• The oldest open failure. Not just how many failures are open, but how long the oldest has waited. Ten failures from this morning are routine. One from last Tuesday means nobody owns it.
• Queue depth. For asynchronous integrations, how much is waiting. The guide again: “growing queue indicates processing falling behind production rate.”

And one roll-up for the business, straight from Salesforce’s health model: data health is all current, behind schedule, or failed or stale. Green, yellow, red. A business reader doesn’t need the error codes. They need to know whether the data they’re looking at is up to date.

Targets Per Business Capability

Measures need targets, or nobody knows what “good” is. Salesforce is clear about who sets them: “You’re responsible for defining and meeting your own service level objectives (SLOs)”, and the platform’s own service level only covers the platform.

Two pieces of the guide’s advice I’d underline. “Define SLOs per business capability rather than per technical component.” And “Design SLOs that reflect user journeys rather than individual API calls.” For Steve Trucking, the target isn’t “the webhook call succeeds 99% of the time.” It’s something a person cares about, for example: a delivery’s status reaches Redrock within ten minutes, for 99 out of 100 deliveries. That target spans Salesforce, the integration layer, the retries and Redrock’s webhook, which is exactly why it’s the right one. It’s what the partner experiences.

Where the Numbers Come From

Here’s a design point that’s easy to miss until it’s too late. You can’t run a standard report on a big object. Salesforce’s own guide: “When working with big data and billions of records, it’s not practical to build reports or dashboards directly from that data.” Instead, “You can store this working dataset in a custom object and use it in reports, dashboards, or any other Lightning Platform feature.”

That’s the counts tier from module 3, and now you can see why it exists. Each day, a job writes one small record per integration: calls, failures, retries, receipts, the slowest times. No payloads, no personal data. Those records are what the reports run on, and they’re small enough to keep for years after the payloads are purged.

So, for a design with module 2’s ledger and to-do list:

• The to-do list (a custom object) feeds the on-call view. Salesforce’s playbook says it plainly: “To track operational metrics like failure rates, build reports and dashboards on IntegrationError__c.”
• The daily counts (a custom object) feed the trends, the monthly business report and capacity planning.
• The ledger (a big object) feeds nothing directly. It’s where you go for one payload, by its ID.
• Event Monitoring (module 7) and the integration layer’s own dashboards fill in what your log can’t see. And Salesforce’s Proactive Monitoring, where you have it, “surfaces capacity risks including API use approaching request limit spikes, storage nearing limits, and batch job queue depth growing beyond sustainable levels.”

Steve Trucking’s Morning Report

Put it together for the person on call at Steve Trucking, as a labelled example. The Data Architect course found the first two numbers it needed: notifications without a receipt, and how old the oldest one is (Proof of Delivery). Here’s the whole page.

Click to enlarge

One page, read in a minute.

The test of a morning report is that it can be read in a minute, and that every number on it leads to an action. If a number never changes what anyone does, take it off.

Test knowledge. Know the reporting needs for integration monitoring (MNT-3): who needs which report; the measures (volume, error rate, latency, completeness, failures and their age, queue depth); targets per business capability; and reporting from a custom object (a log of failures, or daily counts), because big object data is copied to a custom object to be reported on.

Beyond the exam: what AI changes. It’s never been easier to make a dashboard: describe it, and an AI tool builds twenty charts. That’s the problem. More charts means more for someone to read, and less chance the important one is seen. Use AI to build the report, and to explain an odd number in it. Decide yourself which five numbers matter, and who reads them.

What an Architect Decides Here

• The readers, and which report each one gets, how often.
• The measures for each integration, and the target for each, set per business capability, from what a person experiences.
• The counts that are kept after the payloads go, in a custom object you can report on.
• The report you share with each partner, so both sides reconcile to the same numbers.
• The morning report, one page, every number with an action behind it.

Explore

• Salesforce Architects, Well-Architected: Reliability (opens in a new tab): service level objectives, error rate, queue depth, the health model (checked 2026-11-07).
• Big Objects Implementation Guide, View Big Object Data in Reports and Dashboards (opens in a new tab) (checked 2026-11-07).
• Salesforce Developers Blog, The Big Objects Playbook: Payload Capture and Replay (opens in a new tab): reports on the to-do list (June 2026, checked 2026-11-07).
• Proof of Delivery: the Data Architect course, monitoring as part of the integration.