What the Arrow Means on a Landscape

Module 3 of 6 in the chapter Understanding the System Landscape, chapter 5 of the Integration Architect course. Each module stands on its own. Previous: Boxes, Boundaries and Touch Points · Next: Where an Integration Happens: Browser or Server

The question this module answers: On a system landscape, what does each arrow tell you, and how do you draw the ones that aren’t simple calls?

The arrows are important. In chapter 1, Every Arrow Is a Decision asked what an arrow means, and we found two answers that can point in opposite directions: who starts the connection, and which way the data flows. On a system landscape, I tend to make mine client-server: the arrow starts at the system that opens the connection, and the label says what moves.

That rule is for the system landscape. On a data-flow diagram, the arrows follow the data, and we’ll come back to that at the end. Now let’s put the rule to work on a whole landscape.

Read the Arrows

Take the Steve Trucking landscape from module 2 and read its arrows one at a time. Each one answers a question before you’ve asked it: who starts this?

• The crews into Salesforce. The mobile app opens the connection. What comes back is the day’s deliveries, and what goes in is each status and photo, but the arrow starts at the app.
• The recipients to the tracking page, “a link, no login.” The person opens the page. The status comes back to them, but they started it.
• Salesforce to the SMS and email provider, “day-before, with a link.” Salesforce starts it: it calls the provider and asks it to send.
• FleetLink into Salesforce, “latest position only.” FleetLink starts it. Salesforce never asks; it’s told.
• The phone. As in module 2: an IVR is an arrow in, a dialer is an arrow out, and email can be in and out, so it gets one arrow for each.

Why does it matter who starts it? Because the system that starts the call carries the work: it needs the other side’s address, the credentials to sign in, the schedule, and the plan for when nobody answers. Chapter 1 made that point. On a landscape, you can see it for every system at once.

Two Conversations, Two Arrows

Now look at Redrock. Redrock sends Steve Trucking its manifests every night: Redrock starts that call. And Steve Trucking sends each delivery’s status back to Redrock: our side starts that one.

Same two systems. Two conversations. Two starters. So, two arrows.

Click to enlarge

Two conversations with Redrock, two arrows.

It’s tempting to tidy this into one line with a head at each end. Please don’t. Double arrows are a pet peeve of mine, because they hide the most important fact: these are two different mechanisms. Manifests in might be Redrock calling our API, with credentials we gave Redrock: an External Client App and an integration user, as in Who’s Calling In. Status out might be our side calling Redrock’s webhook, with credentials Redrock gave us, kept in a named credential, as in Named and External Credentials. Different starters, different secrets, different owners, different ways to fail. Two arrows show all of that. One double arrow shows none of it.

The Double Arrow Is a Connector

So when do I use a double arrow? Only for a connector: one thing, set up once, that works in both directions.

Think about how a connector between two products works. Underneath, it’s making calls both ways, through APIs you never see or touch. But you don’t configure those calls. You only configure the connector. So on the landscape, it’s one line with a head at each end. Heroku Connect, which keeps Salesforce data in step with a Heroku database, is the example I’ve used for years (Heroku is now in a sustaining engineering model: An Update on Heroku (opens in a new tab), Heroku, 2026-02-06). The same goes for the connectors between Salesforce products with their own hosting, from module 2.

And there’s one more kind of line: a dashed one, for trust. An identity provider above the org doesn’t call Salesforce to move data. The two trust each other, through a shared certificate, so a person signed in to one can be let into the other. No call between them, so no arrow.

Click to enlarge

Four kinds of line, and what each one tells you.

Who Can Start a Call

Here’s a question that catches people out: can every box start an arrow?

No. A database stores; a process calls. A table doesn’t wake up and decide to ask for data. Something has to run: a person, an app, a scheduled job, a flow, a service in the middle. At Steve Trucking, Snowflake wants every delivery status, but Snowflake doesn’t call Salesforce for it. The integration layer does the work, and Snowflake receives. So the arrows run from Salesforce to the integration layer, and from the integration layer to Snowflake.

When you draw an arrow starting at a box, ask: what’s running there that makes the call? If the answer is “nothing”, the arrow starts somewhere else, and there’s a box missing from your landscape. The Data Architect course works this case through in Before the Arrow.

Data Flows Get Their Own Diagram

You’ll also see landscapes drawn as data flows, and when the question is where the data ends up, that’s the right picture. On a data-flow diagram, the arrows follow the data: from where it starts to where it lands, whoever opens the connection.

Just don’t mix the two on one page. A landscape with some arrows for who starts it and some for where the data goes can’t be read by anyone. So: on the system landscape, arrows start at the initiator and the label carries the direction of the data (“manifests in”, “status out”). When you need the data’s journey, draw it on its own diagram, and say in the legend which kind you’ve drawn.

What an Architect Decides Here

• For every arrow on the landscape: who starts it, and what moves, in the label.
• Where two systems have two conversations: two arrows, each with its own mechanism, credentials and owner.
• Which lines are connectors (one double arrow) and which are trust (a dashed line, no call).
• For every arrow that starts at a box: what’s running there that makes the call.
• When a data-flow diagram is needed beside the landscape, and that each one’s legend says which kind it is.

Beyond the exam: what AI changes. An AI agent is a process, so it can start calls, and it often starts many more than a person would. On the landscape, draw an agent’s arrows like any other: starting at the agent, labelled with what moves. Then the questions from chapter 1 apply to it: whose credentials does it hold, when does it call, and what does it do when nobody answers? An agent that calls in through the same arrow as a person needs its own arrow, so you can see it.

Explore

• Heroku, An Update on Heroku (opens in a new tab) (2026-02-06), checked 2026-11-01.
• Every Arrow Is a Decision: the two meanings of an arrow, and how I draw mine.
• Who’s Calling In and Named and External Credentials: the credentials behind an arrow in, and an arrow out.
• In the Data Architect course, Before the Arrow: who asks, and a database stores; a process calls.