Aller au contenu
SteveTechArcSteveTechArc Courses

Study guide

Ce contenu n’est pas encore disponible dans votre langue.

Study guide for chapter 6 of the Integration Architect course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries more exam objectives than any other in Part 1: all four of Evaluate Business Needs (11% of the exam), two of Translate Needs to Integration Requirements (22%), and building a scalable solution from Build Solution (23%). It’s the analysis half of the exam, the half people study least. The limits quoted here are dated to the release they were checked against; check the current page before you design.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

Functional and non-functional requirements (BIZ-1)

  • I can tell a functional requirement (what the business asks it to do) from a non-functional one (how it has to behave: timing, volume, errors, logging, security). (What It Does, and How It Has to Behave)
  • I discover the system at the other end: what it is, its API and version, how it signs callers in, how often it changes, its tech stack and its uptime. (Discover the Other System)
  • I know logging has two halves: enough detail to fix a failure, and nothing in the log that shouldn’t be there. (What Goes in the Logs)
  • I know residency doesn’t stop at the edge of Salesforce: an integration can carry data across a line the org doesn’t cross. (Where the Data Lives)
  • I can run the checklist for every arrow: timing, volume and growth, the other system, errors, logging, security and classification, regulation and residency, constraints. (A Checklist for Every Arrow)

The shape of the integration (BIZ-1, REQ-4)

  • I listen for the direction of action, the source and the target, and the timing, before anyone names a tool. (Listen for the Shape)
  • I can tell real time (synchronous: someone waits), near real time (seconds to minutes, nobody waits) and batch apart, and know Salesforce calls them synchronous and asynchronous. (How Soon)
  • When the business says “real time”, I ask: does someone wait for the answer? (How Soon)
  • I find every flow behind a need, including the initial load before a nightly sync. (Consider All the Flows)
  • I go from shape, to pattern, to mechanism, in that order. (From Shape to Pattern)

Steve’s Number of Zeros (REQ-4, BLD-3)

Classifying the data (BIZ-2)

  • I start with the company’s own language of data, then map it to Salesforce’s five Data Sensitivity Level values: Public, Internal, Confidential, Restricted and MissionCritical. (Start With the Company’s Language)
  • I can map the exam’s three words, confidential, secure and public, to those levels. (The exam’s three words)
  • I know every field has four data classification fields (sensitivity level, compliance categorization, data owner, field usage), and that the API exposes the level so the integration layer can act on it. (Where Salesforce Keeps It)
  • I know encryption in transit doesn’t protect a Restricted field sitting in the middleware, a queue or a file. (What Each Level Means for an Arrow)
  • I send only the fields each arrow needs. (Only What the Arrow Needs)
  • For every arrow, I decide which fields are logged, masked or never logged. (Watch the Logs)

Success, growth and regulation (BIZ-3, BIZ-4)

  • I can name the two CRM success factors: it meets the business requirements, and people use it; and how integrations decide both. (What CRM Success Means)
  • I use the business’s growth number, or 30% a year when there isn’t one. (Growth: 30% When Nobody Has a Number)
  • I know growth multiplies through the child records: 30% at every level makes 2,197,000 line items from 1,000,000 in a year. (Watch the child records)
  • I know the obligations come with the data, that the field’s Compliance Categorization lists them, and that the law comes from the client’s legal and privacy teams, not the architect. (Regulation: The Obligations Come With the Data)
  • I mark the residency zone of every system, including middleware, logs and AI services, and check every arrow that crosses a zone. (Residency: Know What Crosses the Line)

Constraints (REQ-2, supports LAND-2 and BLD-3)

  • I find the other system’s capacity at my peak, and plan a queue when the peak is higher. (Capacity)
  • I know the inbound API allocation is per rolling 24 hours and shared by every caller; in Enterprise Edition, 100,000 plus 1,000 per Salesforce license (Winter ‘27). (Allocations)
  • I know only 25 calls of 20 seconds or longer can run at once, and a REST or SOAP call can run up to 10 minutes (Winter ‘27). (Allocations)
  • I check the ports, the allow lists, and how long a firewall change takes. (The Network)
  • I find the windows (maintenance, business hours across time zones, freezes, cut-offs) and the team’s skills. (Time and People)
  • Once a mechanism is chosen, I match its own limits against these numbers, today and in three years. (Then the Mechanism’s Own Constraints)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • AI gives you what you ask for, not what you forget to ask.
  • Find the other system’s planned outages first. Found before go-live, the monthly weekend is a queue in the design.
  • Shape first, then pattern, then the mechanism.
  • “Real time” usually means near real time. Asking saves the business a lot of money.
  • Do your math early, with the business in the room, one number at a time.
  • A guessed number nobody agreed to is worse than no number.
  • A field that isn’t on the arrow can’t leak from the other end.
  • A system nobody uses is useless. The integration decides whether the data is there, on time and right.
  • The best design is one the team can keep running after the project ends.

Words to Know

Section titled “Words to Know”
TermIn one line
Functional requirementWhat the business asks the integration to do
Non-functional requirementHow it has to behave: timing, volume, errors, logging, security
Real time (synchronous)The caller waits for the answer
Near real timeSent in seconds to minutes; nobody waits
BatchChanges collected and sent together, hourly, daily or weekly
Steve’s Number of ZerosGetting the order of magnitude when nobody will commit to a number
TPSTransactions per second
Activity windowThe hours a day the traffic really runs in
Data Sensitivity LevelA field’s classification: Public, Internal, Confidential, Restricted, MissionCritical
Compliance CategorizationThe laws and rules that apply to a field’s data
ResidencyWhere the data is allowed to be
API allocationThe org’s shared budget of inbound calls per rolling 24 hours

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. The requirement is "send each order to the ERP." The design is done when someone mentions the ERP is down one weekend a month. What went wrong, and what's the fix?

Nobody discovered the system at the other end, including its uptime. Build the outage in: a queue that holds the orders through the weekend and feeds them on when the ERP is back. Find these first, before the design is done. Reread Discover the Other System.

2. The business says the partner must know about every delivery "in real time." What do you ask?

Does anyone wait for the answer? If nobody is sitting at a screen waiting for the partner to reply, it’s near real time, asynchronous, which is much cheaper and easier to maintain than synchronous. Reread How Soon.

3. A flow carries about half a transaction a second. Is it a small integration?

By transactions, yes. But check the bytes: if each delivery carries photos, it might be about 53 GB a day, about 1.2 MB a second. Size transactions and bytes separately, and size the mechanism for the largest message. Reread Count Transactions and Bytes Separately.

4. A client won't say how many accounts they have, because "it's going to grow." What do you do?

Get the number of zeros: ten, a hundred, a thousand, ten billion, until they commit to an order of magnitude, and aim slightly higher. Then turn it into transactions, records and bytes per second over the activity window. Reread When Nobody Will Give You a Number.

5. The integration logs every payload in full, to help support. The payloads carry recipients' phone numbers and gate codes. What do you change?

Decide per field from the classification: Confidential fields masked, Restricted fields never logged. Better still, don’t put the gate code on that arrow at all. The integration layer can read each field’s sensitivity level from Salesforce and mask from it. Reread Watch the Logs.

6. A business with 10,000 customers expects 30% growth. Why might the integration see more than 30% more line items next year?

Growth can come at every level: more customers, each ordering more often, each order bigger. At 30% each, 1,000,000 line items becomes 2,197,000. Ask where the growth comes from, and multiply it through. Reread Watch the child records.

7. The org runs in the European Union. Where else do you look for a residency problem?

At every arrow, and every box at the end of one: the integration layer, every target, the log and monitoring tools, the AI services. A crossing may be allowed, but someone has to know what’s on it, and the lawyers decide how it’s allowed. Reread Residency: Know What Crosses the Line.

8. A tracking system wants to send each truck's position as its own call: about 200,000 calls a day. The org is Enterprise Edition with 200 Salesforce licenses. What's the constraint?

The shared allocation: about 300,000 inbound calls in 24 hours, for every caller (Winter ‘27 numbers). This one integration would spend two thirds of it. Send every truck’s latest position in one call on a schedule instead, if the other system can, and check the current limits page before you design. Reread Allocations.

Explore

Section titled “Explore”