Success Factors, Growth and Regulation

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

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.

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

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

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.

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

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

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.

Click to enlarge

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

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

• 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

• Salesforce Architects, Well-Architected: Trust (opens in a new tab): the architect’s obligations for data and jurisdiction, and the residency checklist, checked 2026-11-01.
• Salesforce, Hyperforce: Public Cloud Infrastructure (opens in a new tab) and Hyperforce Operating Zone (opens in a new tab): where an org can run, checked 2026-11-01.
• The Building Nobody Described: the three-year horizon, and 30% a year.