Aller au contenu
SteveTechArcSteveTechArc Courses

Success Factors, Growth and Regulation

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

Module 5 of 6 in the chapter Understanding Integration Requirements, chapter 6 of the Integration Architect course. Each module stands on its own. Previous: Classifying the Data · Next: Constraints

The question this module answers: What makes a CRM succeed, and what outside the project, growth and the law, changes how its integrations have to be built?

The exam asks for three things here: the key factors for CRM success, the growth you have to plan for, and the regulations that apply. They sound like three different topics. They’re one question: will this integration still be the right one when the system is live, busy and being checked?

What CRM Success Means

Section titled “What CRM Success Means”

When I say a CRM project succeeded, I mean two things, in this order.

First, it meets the business requirements. That’s the first thing. The business asked for something; did they get it? Not what we thought they meant, not what was easy to build: what they asked for, and the implied requirements behind it.

Second, people use it. Adoption: getting people to actually use the system. A system can meet every requirement on paper and still fail, because nobody opens it. Meet the requirements and get it used, because a system nobody uses is useless.

Those are the two critical ones. Everything else you might list, data quality, one view of the customer, speed, serves one of them.

So where does integration come in? Into both. Most of what a business asks a CRM to do needs data from somewhere else: the order from the ERP, the delivery from the partner, the balance from accounting. And whether people use the system often depends on that data being there, on time, and right.

Meet it, then get it used Two columns. Meet the business requirements, in blue, what they asked for and what they assumed: every requirement the business asked for, traced to an arrow; the implied ones too: errors, volumes, logs; the non-functional ones as numbers; checked with the business, not only by the team. Get it used, in amber, adoption, people actually use the system: the data people need, on the screen where they work; there when the process needs it; right, so people trust it; fast enough that nobody waits on it. Underneath: meet the requirements and get it used; a system nobody uses is useless. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.53.0", "built": "2026-10-30", "id": "DGM-INT-RQ-09", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison/side-by-side 0.5.0", "theme": "stevetecharc 1.4.0"} 1. Meet the business requirements what they asked for, and what they assumed Every requirement the business asked for, traced to an arrow The implied ones too: errors, volumes, logs The non-functional ones as numbers Checked with the business, not only by the team 2. Get it used adoption: people actually use the system The data people need, on the screen where they work There when the process needs it Right, so people trust it Fast enough that nobody waits on it Meet the requirements and get it used. A system nobody uses is useless. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Meet it, then get it used.

The second column is where integrations quietly decide adoption. If the delivery status on a customer’s record is a day old, the service rep calls the warehouse instead, and soon stops looking at the record at all. If the numbers in Salesforce don’t match the numbers in finance, people keep their own spreadsheet. Each of those is an integration requirement nobody wrote down: how soon, how right, how fast. And each of them is the difference between a system people use and a system nobody uses.

Growth: 30% When Nobody Has a Number

Section titled “Growth: 30% When Nobody Has a Number”

An integration has to work on the day it goes live and for years after. In chapter 1, I said I like a three-year horizon: records will grow, traffic will grow, users will grow, complexity will grow. So you need a growth number.

Ask the business first. If they have a growth plan, use it. If they don’t have one, here’s my rule: take the current year’s traffic and add 30%. That’s 30% for typical growth, as a baseline, when you don’t have an existing growth number. Module 3 ran Steve Trucking out to year three that way: about 2.2 times today’s volume.

Watch the child records

Section titled “Watch the child records”

Now be careful, because 30% on the parent can mean much more on the children. Growth can lead to something more like exponential with child records.

Here’s a “what if”, with round numbers. A business has 10,000 customers. Each one places 10 orders a year, and each order has 10 line items. That’s 1,000,000 line items a year going through the integration.

Next year, the business grows 30%. If that means 30% more of everything, you have 1,300,000 line items. But growth rarely stays on one level. Say there are 30% more customers, and each customer orders 30% more often, and each order is 30% bigger. Now it’s 13,000 × 13 × 13: 2,197,000 line items. More than double, in one year.

Growth multiplies through the children A table of customers, orders and line items a year, in three columns. Today: 10,000 customers, 100,000 orders (10 each) and 1,000,000 line items (10 an order). Next year, with 30% on the total: 13,000, 130,000 and 1,300,000. Next year, with 30% at every level (tinted amber): 13,000 customers; 169,000 orders, 13 each; and 2,197,000 line items, more than double. Underneath: no growth number? Use 30% a year. Then ask: more parents, more children for each, or both? {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.53.0", "built": "2026-10-30", "id": "DGM-INT-RQ-10", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape/inventory 0.13.0", "theme": "stevetecharc 1.4.0"} A YEAR TODAY NEXT YEAR: 30% ON THE TOTAL NEXT YEAR: 30% AT EVERY LEVEL Customers 10,000 13,000 13,000 Orders 100,000 (10 each) 130,000 169,000 (13 each) Line items 1,000,000 (10 an order) 1,300,000 2,197,000: more than double No growth number? Use 30% a year. Then ask: more parents, more children for each, or both? © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Growth multiplies through the children.

Run that for three years and it’s more than ten times today. You may never see that, but you need to know which of your numbers can multiply. So for every flow, ask where the growth comes from: more parents, more children per parent, or both. The 30% baseline is for the total. When the growth comes at every level, multiply it through.

And growth isn’t only volume. Users grow, so more people wait on the synchronous calls. Complexity grows: new partners, new regions, new channels. As module 2 said, two workflows might turn into five.

Regulation: The Obligations Come With the Data

Section titled “Regulation: The Obligations Come With the Data”

Some requirements aren’t the business’s choice at all. They come from the law, or from a contract, and they come with the data. Salesforce puts it plainly: “Architects are responsible for the obligations that are attached to your data and jurisdiction” (Well-Architected: Trust (opens in a new tab), Salesforce Architects, checked 2026-11-01). Which laws apply, how the data is classified, how long it may be kept, what the customer consented to.

You’ve already met the names. In module 4, every field’s Compliance Categorization can list the rules that apply to it, such as GDPR (personal data in the European Union), HIPAA (health information in the United States) and PCI (payment card data). Those categories are your list of which arrows carry regulated data.

I’m not going to teach you the law here, and neither should anyone who isn’t a lawyer. Laws differ by country and change over time. Salesforce’s own guide says the same: its guidance “is directional”, and you “must always verify specific obligations against the governing regulation”. The architect’s job is to find which rules apply to which data, ask the questions early, and get the answers from the people who own them: the client’s legal, privacy and security teams.

Residency: Know What Crosses the Line

Section titled “Residency: Know What Crosses the Line”

One regulation question changes the landscape itself: residency, where the data is allowed to be.

Salesforce lets you choose where your org runs. Hyperforce has regions for “the U.S., U.K., Germany, India, Japan, and more” (Hyperforce: Public Cloud Infrastructure (opens in a new tab), Salesforce, checked 2026-11-01). The Hyperforce Operating Zone goes further for the European Union and Switzerland: authorized products process and store customer data within the region, with support from people in the region (Hyperforce Operating Zone (opens in a new tab), Salesforce, checked 2026-11-01).

But that’s one box on the landscape. The org can be in the right place, and the integration can still carry the data somewhere else. That’s what module 1 warned about: a European org sending its customers’ documents to an e-signature service hosted in the United States.

So if you’re building a system that has to respect data residency, then on your system landscape, identify the country, or the residency zone, of every system. Not only Salesforce: the integration layer, every target, the log and monitoring tools, the AI service. Then look at every arrow that crosses from one zone to another, and make sure you’re not passing data across residency zones without knowing what you’re sending across.

Know what crosses the line Two frames on the same cells. Frame 1: a landscape in two zones. In the European Union: Salesforce, in a Hyperforce region in the EU; and the integration layer, hosted in the EU. In the United States: an e-signature service, hosted in the U.S.; and a monitoring tool, the integration's logs, hosted in the U.S. Salesforce sends contracts to sign to the integration layer; the integration layer sends contracts to sign to the e-signature service, and the logs, with their payloads, to the monitoring tool. Frame 2: the two arrows that cross from the EU to the U.S. turn amber. To the e-signature service: the contract and the signer, known, and covered. To the monitoring tool: the whole payload, which nobody planned. Underneath: mark the zone of every system, not only Salesforce; crossing may be allowed, but never without knowing what you're sending across. EUROPEAN UNION UNITED STATES Salesforce a Hyperforce region in the EU The integration layer hosted in the EU An e-signature service hosted in the U.S. A monitoring tool the integration's logs, hosted in the U.S. contracts to sign contracts to sign logs, with payloads Mark the zone of every system, not only Salesforce. Crossing may be allowed, but never without knowing what you're sending across. HOW TO READ IT crosses from the EU to the U.S. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Frame 1 of 2: every system, marked with its zone.

Know what crosses the line Two frames on the same cells. Frame 1: a landscape in two zones. In the European Union: Salesforce, in a Hyperforce region in the EU; and the integration layer, hosted in the EU. In the United States: an e-signature service, hosted in the U.S.; and a monitoring tool, the integration's logs, hosted in the U.S. Salesforce sends contracts to sign to the integration layer; the integration layer sends contracts to sign to the e-signature service, and the logs, with their payloads, to the monitoring tool. Frame 2: the two arrows that cross from the EU to the U.S. turn amber. To the e-signature service: the contract and the signer, known, and covered. To the monitoring tool: the whole payload, which nobody planned. Underneath: mark the zone of every system, not only Salesforce; crossing may be allowed, but never without knowing what you're sending across. EUROPEAN UNION UNITED STATES Salesforce a Hyperforce region in the EU The integration layer hosted in the EU An e-signature service hosted in the U.S. A monitoring tool the integration's logs, hosted in the U.S. contracts to sign the contract and signer: known, and covered the whole payload: nobody planned it Mark the zone of every system, not only Salesforce. Crossing may be allowed, but never without knowing what you're sending across. HOW TO READ IT crosses from the EU to the U.S. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Frame 2 of 2: two arrows cross the line. One was planned.

Notice the second arrow. The contracts going to the e-signature service were a decision: someone knew, and someone could check it. The logs going to the monitoring tool weren’t. They carry whatever the payload carries, and nobody marked that tool’s zone. That’s module 4’s log problem, crossing a border.

Crossing a zone isn’t always forbidden. Salesforce’s guide notes that the GDPR “requires adequate protection for personal data leaving the European Union (EU), but not EU deployment as such”, and that a transfer can be permitted under an adequacy decision, Standard Contractual Clauses or Binding Corporate Rules. Other countries have stricter rules that keep some data in the country. Which applies is the lawyers’ answer. Knowing which arrows cross, and what’s on them, is yours. Salesforce’s checklist is the right order: classify where each kind of data must reside, confirm a suitable region exists before you build, and design a legal transfer for data that crosses a border.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • What success means for this CRM: the requirements it must meet, and who has to use it, and what the integrations must do for each.
  • The growth rate for every flow: the business’s number, or 30% a year when there isn’t one, multiplied through the child records where the growth comes at every level.
  • Which rules apply to which data, from the fields’ Compliance Categorization, confirmed with the client’s legal and privacy teams.
  • The country or residency zone of every system on the landscape, including the middleware, the logs and the AI services.
  • For every arrow that crosses a zone: what it carries, and how that crossing is allowed.

Beyond the exam: what AI changes. An AI service is one more box on the landscape, and it has a location too. A prompt that carries a customer’s details to a model hosted in another zone is an arrow crossing the line, and so is the prompt log. And AI changes adoption: if people can ask an agent instead of opening the record, the agent is now part of what gets the system used, and the data it reads has to be just as current and just as right.

Explore

Section titled “Explore”