ข้ามไปยังเนื้อหา
SteveTechArcSteveTechArc Courses

Boxes, Boundaries and Touch Points

เนื้อหานี้ยังไม่มีในภาษาของคุณ

Module 2 of 6 in the chapter Understanding the System Landscape, chapter 5 of the Integration Architect course. Each module stands on its own. Previous: Two Boxes Protect You · Next: What the Arrow Means on a Landscape

The question this module answers: What does a box on a landscape stand for, which Salesforce products share your org, and how much do you draw?

In module 1, we drew two boxes and let the client fill in the rest. Now look closer at what we drew. What is a box, really? Where does one end and the next begin? And when does Salesforce itself need more than one box?

A Box Is a Process Boundary

Section titled “A Box Is a Process Boundary”

A system landscape is rectangles and arrows. The rectangles are what I call process boundaries: a running system, with its own memory and its own processing. The arrows are where one process talks to another, and every arrow crosses a boundary.

That’s why I don’t define an integration by machines or by distance. You can have an integration on the same physical machine: one process running that needs to talk to a different process. It could be another machine in the same data center, or a machine on the other side of the world. If the data has to leave one process and arrive in another, that’s an integration, and it gets an arrow.

So the question to ask of every box isn’t “is this a different computer?” It’s “does this run in its own space?” If it does, anything that reaches it crosses a boundary.

The Product Party

Section titled “The Product Party”

Here’s a secret about Salesforce: it’s not all one cohesive product. Salesforce does a lot of things, and many of them came from acquisitions, stitched together over the years. Some of them dance together in one space. Some do their own thing. I call it the product party.

The space they share is Salesforce core: your org. Everything on core runs in the same memory space, with the same objects, the same Apex, the same flows and the same Lightning components. That’s where a lot of the power of customizing the platform comes from. And it’s what makes this rule so useful:

Anything in core does not require an integration. Anything outside it needs a connector or an integration.

So where does each product run today? Here’s how it looked when I checked on 2026-11-01:

  • On core. Sales Cloud, Service Cloud, Field Service and the industry clouds all run in your org. So does B2B Commerce: in Salesforce’s words, you can “operate both a B2B and D2C channel from a single Salesforce org with shared data and processes” (Salesforce B2B Commerce (opens in a new tab), Salesforce Help, checked 2026-11-01). Experience Cloud sites are separate public addresses where you brand your site, but they don’t run in a separate memory space: they’re your org, seen from outside.
  • Near core. Data 360 (called Data Cloud until October 14, 2025: About Salesforce Data 360 (opens in a new tab), Salesforce Help, checked 2026-11-01) is its own case. Its screens are in your org, but the tenant that holds the data and does the processing runs off core. Managed on core, hosted off core. The Data Architect course’s One System Among Many goes deeper.
  • Its own hosting. Marketing Cloud Engagement, Account Engagement (it was Pardot), B2C Commerce, MuleSoft, Tableau and Heroku each run on their own, and Salesforce’s Trust Status site lists each one with its own status (Salesforce Trust Status (opens in a new tab), checked 2026-11-01). Slack runs on its own platform too. Each of these is a separate box on your landscape, and reaching it from your org takes a connector or an integration.
The product party Three columns. On core, in blue, in your org, no integration: Sales Cloud and Service Cloud, Field Service, Experience Cloud sites, B2B Commerce, the industry clouds and Marketing Cloud Next. Near core, in cyan, managed on core, hosted off core: Data 360. Its own hosting, in navy, needs a connector or an integration: Marketing Cloud Engagement, Account Engagement, B2C Commerce, MuleSoft, Tableau, Heroku and Slack. Underneath: checked 2026-11-01; where a product runs changes, so check again, on Salesforce Trust Status and in each product's own documentation. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-INT-LS-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} On core in your org: no integration Sales Cloud, Service Cloud Field Service Experience Cloud sites B2B Commerce Industry clouds Marketing Cloud Next Near core managed on core, hosted off core Data 360 Its own hosting a connector or an integration Marketing Cloud Engagement Account Engagement B2C Commerce MuleSoft Tableau Heroku Slack Checked 2026-11-01. Where a product runs changes: check again, on Salesforce Trust Status and in each product's own documentation. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The product party: some dance on core, some do their own thing.

Notice the two commerce products. It’s a good trick question for a class: does Commerce Cloud run on core? Yes and no. There are two of them. B2B Commerce runs on core. B2C Commerce has its own hosting, and needs a connector to reach your org.

And notice marketing. Marketing Cloud Next is, in Salesforce’s words, “Built natively on the Salesforce Platform” (Salesforce Announces Marketing Cloud Next (opens in a new tab), Salesforce News, 2025-06-11, checked 2026-11-01), while Marketing Cloud Engagement and Account Engagement still run in their own space. The party is moving. Heroku is changing too: it announced in February 2026 that it is “transitioning to a sustaining engineering model” (An Update on Heroku (opens in a new tab), Heroku, 2026-02-06).

That’s why I care less about memorizing which product runs where this year than about the habit. When a product says Salesforce, don’t assume it’s in your org. Check. Trust Status is a good first look: a product with its own status has its own hosting. Then read the product’s own documentation for how it connects.

You need to know the capabilities of these products, too. If I’m feeding Sales Cloud from Account Engagement, that’s an integration with a connector. If I’m doing quoting on core and then shipping the order to an ERP, that’s an integration with a system that isn’t Salesforce at all. And that one, opportunities going out to an ERP and coming back as processed orders, is the most common integration I see.

On the landscape, a connector between two Salesforce products gets one more mark: a double arrow. A connector is set up on both ends, and data moves both ways through it. Module 3 is about what an arrow means, and why that’s the only place I use a double arrow.

Touch Points

Section titled “Touch Points”

Now go back to the landscape. Some boxes are systems, and some are people. Every place a person reaches the estate is a touch point, and each one is an arrow you’ll have to design.

At Steve Trucking, the office staff, the dispatchers and the delivery crews work in the org: the crews from their mobile app, out on the road. The Retail Partners’ users have their own portal. The people receiving the deliveries get a tracking page from a link, with no login. They call the phone line, they send email that becomes a case, and the day before their delivery, a text message arrives with a link.

Every place a person touches it The finished Steve Trucking landscape, every box in its place from the first call. Eight arrows are picked out in amber, the touch points where a person reaches the estate: dispatch coordinators, delivery crews and care and office staff into Salesforce; Retail Partner users into their portal; recipients to the tracking page with a link and no login, and to the phone; email into Salesforce as cases; and Salesforce's day-before message, with a link, out through the SMS and email provider. The legend names amber as a touch point. Underneath: eight touch points: staff, dispatchers and crews in the org, partners in their portal, recipients on the tracking page and the phone, cases from email, and the day-before text. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.54.0", "built": "2026-10-30", "id": "DGM-INT-LS-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape 0.13.0", "theme": "stevetecharc 1.4.0"} ABOVE: IDENTITY, APPEXCHANGE, WEB PEOPLE RIGHT: INTERNAL SYSTEMS BELOW: CUSTOMER CHANNELS BOTTOM RIGHT: PARTNERS AND PROVIDERS Dispatch coordinators 45, inside 9 partner DCs Delivery crews ~700 on 330 trucks Care and office staff 100: service, ops, finance Retail Partner users ~300 at 3 partners Recipients ~1 million a year Corporate IdP SSO for office staff only Retail Partner portal Tracking page INTEGRATION Snowflake status history, analytics FleetLink raw GPS stays here Finance ERP invoices partners, pays crews Photo storage 4–5 million a year, off core RouteDesk archive retired; 8 years of history Phone care agents Email email-to-case SMS and email provider day-before message, with a link Redrock REST API, webhooks Keystone CSV over SFTP Brightwave EDI through a third-party network Salesforce Field Service, one US org a link, no login office staff only calls cases in manifests in status out manifests in status out manifests in status out upserts, partner key status events status events latest position only delivery counts delivery counts photos, from the crews' app day-before, with a link Salesforce a community people identity, apps, web an internal system a customer channel the integration layer starts at the system that opens the connection; the label says what moves a shared certificate: trust, no direct call a touch point: where a person reaches it Eight touch points: staff, dispatchers and crews in the org, partners in their portal, recipients on the tracking page and the phone, cases from email, and the day-before text. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Every place a person touches it.

Each touch point can hide more boxes. Take the phone. What if Steve Trucking’s phone line had an IVR, an interactive voice response? You know the sound: “Thank you for calling Steve Trucking. Press one to track a delivery. Press two to change your delivery day.” The IVR talks to the caller, collects data and routes the call. And then it feeds that data into Salesforce: the agent’s phone rings, and the caller’s record appears on the screen without the agent doing anything. That’s a screen pop, and it works through computer telephony integration, CTI. Turn it around, and an outbound dialer lets an agent click a button on a record and the phone dials. An IVR is an arrow in; a dialer is an arrow out. One phone line, two or three more boxes.

So for every touch point, ask: what’s behind it? Text messages, in and out, go through a provider. Email comes in through email-to-case and routing. Single sign-on puts an identity provider above the org. Even the first data load, the migration, is an arrow on the landscape.

Not the Schematic of a Processor

Section titled “Not the Schematic of a Processor”

You can put some things inside the boxes. But be careful putting too much in there. Otherwise your landscape starts to look like the wiring diagram of a computer chip, the schematic to the Pentium processor, and it loses its value.

Too much on one page is what I call information density. You have to decide how much of each system’s insides to show, against how much of the connections between the systems. A landscape is for the connections. Name each box, add a short note when it helps (how many users, which protocol, what’s retired), and leave the insides for their own diagrams.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • What counts as a box: every process that runs in its own space, whoever’s name is on it.
  • For every Salesforce product in the project: on core, near core or its own hosting, checked against today’s sources, with the date.
  • Where a product has its own hosting: a connector or an integration, and who owns it.
  • Every touch point, and what’s behind each one.
  • How much goes inside each box, and what goes on its own diagram.

Beyond the exam: what AI changes. AI products join the party too, and each one needs the same question: does it run in your org, beside it, or somewhere else entirely? An agent built on the platform shares your org’s boundary. An AI tool outside Salesforce is its own box, and every place it reaches your data is an arrow. And an AI assistant on a website or a phone line is a new touch point: draw it like any other, with what’s behind it.

Explore

Section titled “Explore”