The question this module answers: How do I draw a landscape that shows where the data goes?
Give me a new scenario and a blank whiteboard, and one of the first things I’ll draw is the system landscape. Not beautiful, not every API, not the data model yet. I want to see the enterprise: who the users are, which systems are involved, where Salesforce sits, what surrounds it, where data comes from and where it goes. And then I want to walk the arrows. A good landscape isn’t a picture of boxes. It’s a way to expose architectural decisions.
I make CTA candidates practice this. Read the scenario, then start drawing. Don’t wait until you’ve solved it all in your head; the drawing helps you solve it. That’s why the homework after day one is to start the landscape before taking a stab at the data model. Draw the data model first and you’ve already assumed what belongs in Salesforce. Draw the landscape first and you can see the systems that should shape that decision.
Start high, then drill down: the whole enterprise first, then the detail where it matters.
There are many ways to draw a system landscape. This is just my way, one I’ve refined over many years, and I’m sharing it so you can see how to put one together quickly. I use it for every Salesforce landscape, and it reads like a sentence: people on the left reach Salesforce in the middle, trusted through the systems above it, served through the channels below it, and connected to the back office on the right.
People on the left, top to bottom: internal users, partners, customers. Not every persona yet; enough to answer who is trying to reach this architecture? Each group points to where it comes in: internal users to Salesforce, partners to the partner community, customers to the customer community. Systems don’t exist by themselves. Somebody, or something, is trying to use them.
Step 2 of 6: who is trying to reach this architecture?
Salesforce in the middle. One plain box. Not because Salesforce is the center of the enterprise (we just spent three modules saying it isn’t) but because it’s the system I’m designing around. It’s the anchor.
The communities right below it, touching. A partner community and a customer community are separate endpoints, so they get their own boxes. But they sit against Salesforce, because nothing has to integrate to reach them: they run in the same org.
Step 3 of 6: Salesforce in the middle, the communities right below it.
Identity above. The identity providers go at the top, the ones developers forget: one for internal users, maybe another for partners. AppExchange packages go up there too, slid to the right, because they’re capabilities brought into the org rather than back-office systems trading data with it. Public websites sit at the top left.
Step 4 of 6: identity above, the box developers forget.
Integration, then the back office, to the right. The integration layer, an ESB or iPaaS (or MuleSoft, when it’s named), is a tall bar just right of Salesforce. The internal systems sit behind it: the ERPs, finance, order management, legacy systems, the warehouse. Now the page reads left to right: people, Salesforce, integration, back office.
Channels below. Whatever has a direct line to customers: email-to-case, web-to-lead, phone, messaging.
Data in and out, bottom right. External data sources, archives, data loads.
Data 360 to the right, below the integration layer. Users never connect to it, and its tenant connects to many back-end systems, so it sits with the plumbing, where those lines stay short: beside the internal systems, the warehouse and the data at the bottom right. Data teams do open its screens, but those screens are in the org: Data 360 is near-core, managed on core and hosted off core (module 1). One line back to Salesforce shows who manages it. Where you put the box should tell the story of what it does.
None of this geometry is sacred. The value of a convention is that I don’t reinvent the visual language every time, and anyone who’s seen one of my diagrams can read the next one faster.
Keep the notation simple. Every system is a card: its name, its role, and a small icon that says what kind of thing it is: an ERP, a database, an identity provider, a group of people. The regions I just described are drawn as faint, labeled zones, so the layout itself is visible. A legend at the bottom says what every icon and line means.
Don’t put too much inside a box. Only on a very complicated landscape do I open Salesforce up into its parts (Sales Cloud and Service Cloud inside the org, with arrows among them). And don’t invent fifteen shapes unless each one tells the reader something. I want someone to look at the landscape for thirty seconds and start understanding the architecture. Fancy doesn’t help. Clear does.
Don’t wait for detailed design to think about volume. An arrow carrying 500 products a night and one carrying 200,000 GPS readings a day can look exactly the same on the landscape. They aren’t the same problem. So before you draw a single arrow, count what moves. Start the inventory behind the picture with the counts: one row per important data set, with its volume. The zeros may never show up on the arrows, but you need to know when you cross into high numbers: thousands or millions in an hour, hundreds of thousands of transactions, even tens to hundreds of transactions a second.
Those numbers drive the mechanism. A few hundred records a night is a batch. A call someone waits on can be synchronous, if the volume lets it. Tens to hundreds a second may need events, such as platform events, rather than a call per record. The arrow will look the same; the volume decides what carries it, so record it in the inventory, where the mechanism gets chosen.
The mechanism can even change the direction of the arrow. Send a couple of records a minute, and Salesforce can simply call out: the arrow starts at Salesforce. Send far more, and Salesforce may publish events on the event bus instead; the external system subscribes and calls in for them, so now the arrow starts at the other end. Bigger still, say a nightly sync of millions of records, and it’s a batch process. So know your counts early, as you start designing the mechanisms, because the counts can redraw the arrows.
Volume matters in two places, for two reasons. On a data model, I need it to watch for large data volumes and plan archiving; Part 2 goes deep on that. On a system landscape, the large numbers in the inventory drive the choice of integration pattern and mechanism. Module 6 puts real zeros on Steve Trucking’s landscape and its inventory. With the counts in hand, draw the arrows.
With the systems in place, connect them, and the landscape becomes architecture. A box is a system; the arrow shows who initiates the connection. It starts at the system that opens the connection and points at the one it calls: client to server. The label says what moves, and which way.
That rule is for system landscapes, where systems are talking to systems. On a data-flow diagram the arrow follows the data, as you’d expect. Don’t carry the landscape rule into other diagrams; it only adds confusion.
The arrows dropped in. Every box is where it was; each arrow starts at the system that opens the connection, and its label says what moves and which way.
So if the integration layer pushes products into Salesforce, the arrow runs from the integration layer to Salesforce, labeled products in. If Salesforce calls out to fetch them, the arrow starts at Salesforce, still labeled products in. Same data, different conversation, and that difference tells me who needs the credentials and who has to handle the failure. Salesforce sends the order through the integration layer: orders out. The ERP’s fulfillment comes back: order status in. Now I can see who starts each conversation, where data enters Salesforce and where it leaves, which flows cross boundaries, where ownership probably sits, and where I need to ask more.
And remember module 1: whenever I see only one flow, I get concerned. At the high level, an orders out arrow depends on back flows: customers in, products in, prices. Look deeper still and there’s the return journey: acceptance, rejection, status, an invoice number, a cancellation. The arrows give me something concrete to challenge.
This is where the landscape stops being PowerPoint art. At the review board, any arrow can draw three questions, and I want you to have the answers:
How does it authenticate? OAuth, a certificate, a named credential, something else?
Is it synchronous or asynchronous? Does Salesforce wait for the ERP, or publish and carry on? How fast does the business need the result?
What’s the mechanism? A REST call, an event, a file, a message queue, through MuleSoft or direct?
And then: what happens when the other side is down? Every arrow needs a mechanism. If you can’t explain it, the line is decoration.
And “fire and forget” isn’t an answer. It usually means “I haven’t designed what happens after the fire.” Did it arrive? Was it accepted? Did it fail? Will it retry? Who knows it’s stuck? What if the same message arrives twice? None of that goes on the landscape, which would become unreadable. But the arrow should make you know those questions exist.
Zoom in on any one arrow and there’s a client and a server, and each owns its half. The client opens the connection: it needs the endpoint and the port, gets a token from the authentication server first, calls the protocol and contract the server defines, and chooses whether to wait. Only the client sees the whole round trip, so only the client can retry. The server listens, defines the protocol, the contract and the payload, validates what comes in, and sees only its own part. When I draw an arrow, I already know which end is which, and that tells me who owns each of these questions.
One arrow, zoomed in: the client handles, the server defines. None of this goes on the landscape, but every arrow has it.
Now turn the arrow around. When the ERP calls Salesforce, Salesforce is the server: it defines the APIs, runs its own authorization server, and decides through an External Client App and an integration user what the caller may do. Same questions, other side.
Here’s where architects ruin a good diagram: they make one artifact answer everything. The landscape gets API names, payloads, retries, error queues, transformations, every callback, and soon nobody can read it. Don’t. The landscape is the big picture: systems and the important flows between them.
When I need to explain an interaction, I draw a second diagram, but not for every integration. If system A sends something to B, or even asks and gets an answer, the labeled arrow is enough. I want a swim lane when the process becomes a conversation: A calls B, B checks with C, C answers, B creates something and calls A back, a person approves, another system carries on. My rule of thumb: more than one or two back-and-forth exchanges, and the sequence gets its own swim lane. Arrows on the landscape; the conversation in the swim lane.
And notice that an arrow means something different there. On the landscape, an arrow is a connection: who opens it, and what moves. In a swim lane, each arrow is one message in a conversation, read in order: a request goes one way, a reply comes back the other, and the next step follows.
Three arrows on the landscape; six steps in the swim lane. On the landscape an arrow is a connection; in a swim lane each arrow is one message, in order.
When the landscape looks mostly done, walk it, arrow by arrow. ERP to Salesforce: what’s moving, who owns it, how does it authenticate, what’s the mechanism, sync or async, how current must it be? Then the next arrow, and the next. This is where gaps appear. “Oh, we never worked out how the partner actually sends that.” “We send orders to the ERP, but we haven’t designed how rejected ones come back.” Good. You found it on the whiteboard instead of in production.
The picture has to stay readable, so the details go in the inventory behind it. You started it with the counts; now finish it, one row per important data set or flow:
That’s why I like this artifact: it helps me think. “How will we report across Salesforce and the ERP?” It’s the question from module 3: which of my diagrams solves this beautifully? The landscape. If everything’s on core, standard reports. If the data is in the ERP and the warehouse, you can see it immediately. “Where should this customer attribute be mastered?” Look at which systems use it and which already owns the customer. “Does Salesforce need every GPS reading?” Who produces it, who consumes it, what’s the workload? Maybe Salesforce needs the current position and another platform keeps the history. The landscape doesn’t hand you the answer. It gives you the right view of the problem.
One more discipline. In an existing enterprise, draw what exists, not what you wish existed. The spreadsheet emailed every Friday: draw it. The partner’s CSV on an SFTP server: draw it. The integration that bypasses the ESB for historical reasons: draw it. People rekeying data between two systems: show it. Don’t clean up reality while you’re documenting it. You need the current landscape before you design the target one, and that’s what we do for Steve Trucking in module 6.
Beyond the exam: what AI changes. The landscape is becoming an agent map. If an agent answers “where’s my delivery?”, the landscape has to say whether the answer comes from Salesforce, a partner system, telematics, the ERP, or a mix. Agents don’t remove system boundaries; they make knowing which system is authoritative, and how to reach it safely, even more important.
Which systems and user populations belong on the landscape, and how their placement shows their role.
Which flows cross system boundaries, in which direction, and what comes back.
How every connection authenticates, what mechanism carries it, and whether it’s synchronous, asynchronous, batch or federated.
When a labeled arrow is enough and when an interaction needs its own swim lane.
What the inventory behind the picture records: owner, workload, volume, org, timing, authentication, and copy, reference or federate.
The landscape isn’t something I draw after the architecture is done. It’s how I find the architecture. And when you think it’s finished, don’t admire it. Walk it. Every arrow you can’t explain yet shows you where the work is.
