Constraints

Module 6 of 6 in the chapter Understanding Integration Requirements, chapter 6 of the Integration Architect course. Each module stands on its own. Previous: Success Factors, Growth and Regulation · Next chapter: Integration Patterns

The question this module answers: Once you know what an integration has to do, what limits how you’re allowed to do it?

Requirements say what the integration must do. Constraints say what it can’t. They’re the walls you design inside: a system that can only take so many calls, a daily allocation shared with every other caller, a firewall that only opens one port, a window when nothing may run, a team that has never used the tool you had in mind.

The exam asks you to look at the existing landscape and analyze it for constraints or pain points. That’s the right order. The constraints are already there, on the landscape, before you design anything. Your job is to find them before you design, not in production.

When I look for constraints, I look at four things: capacity, allocations, the network, and time and people.

Click to enlarge

Four kinds of constraint.

Capacity

Capacity is how much each side can take. Start with the system on the other end. How many calls a second can it answer? How big a message will it accept? Does it slow down at month end, when everyone else is using it too?

Then put your own numbers next to it. Module 3 gave you your peak: transactions, records and bytes per second, in the busiest window, in the busiest season. If your peak is higher than their capacity, that’s a constraint, and it decides part of the design: something in the middle has to take the burst and feed it on at a rate the other side can handle. That’s the queue from module 3, and the same queue that carried the utility’s weekend outage in module 1.

Nobody will tell you the other system’s capacity unless you ask. Ask the team that runs it. And if they don’t know, that’s a finding too: plan a test before go-live, not after.

Allocations

Salesforce has limits of its own, and an integration architect has to know them. For the APIs other systems call into, Salesforce sets three kinds of limits (API Request Limits and Allocations (opens in a new tab), Salesforce Developers, Winter ‘27, API 68.0, checked 2026-11-01):

• Total calls in 24 hours. Every org gets an allocation of inbound API calls per rolling 24 hours. In Enterprise Edition, it’s 100,000, plus a number for each license (1,000 for each Salesforce license), plus any calls the company buys. In Unlimited and Performance Edition, it’s 5,000 for each Salesforce license.
• Long calls at once. Calls that run 20 seconds or longer: 25 at a time in production and sandboxes. The 26th gets an error, REQUEST_LIMIT_EXCEEDED, until one finishes.
• The length of one call. A REST or SOAP call can run for 10 minutes, except queries, which follow their own limits.

The one that catches people is the first, because it’s shared. Every system that calls into the org spends from the same allocation. Here’s a “what if” with Steve Trucking. FleetLink, the truck tracking system, sends Salesforce the latest position of each truck: about 200,000 readings a day. Say the org is Enterprise Edition with 200 Salesforce licenses. That’s 100,000 + 200 × 1,000 = 300,000 calls in 24 hours, for everyone.

Click to enlarge

Frame 1 of 2: one call for every reading.

Click to enlarge

Frame 2 of 2: one call every five minutes, with every truck’s latest position.

If FleetLink makes one call for every reading, that one integration spends two thirds of the org’s allocation, and every other caller, the partners, the warehouse, the mobile app, shares what’s left. Send the latest position of every truck in one call, every five minutes, and it’s about 144 calls a day over twelve hours. Same requirement, “latest position only”, and a very different constraint. Whether FleetLink can do that is a question about the other system, and that’s why module 1 said to find out what it can do.

The numbers change by edition and by release, so check the current page before you design, and write down which one you checked.

These are the org’s limits, the ones every integration shares. Each mechanism has limits of its own too, and we’ll come to those at the end of this module.

The Network

Even when both systems have the capacity, the call still has to get through. In chapter 2 we saw that a call needs a name, an address, a port, and someone listening, and that every firewall in between has to allow it. In chapter 4, Salesforce’s own allow list decided where a call may go.

As constraints, I ask:

• Which ports are open, on every firewall between the two systems?
• Which allow lists apply, inbound and outbound? Does the other system only accept calls from known IP addresses? Then you need to know where your calls come from.
• Who runs the firewall, and how long does a change take? In a large company, opening a port can take weeks of tickets and approvals. That’s a constraint on the plan, not only on the design.

Time and People

The last group is when the integration may run, and who will keep it running.

Windows. The other system may be down on a schedule, like the utility’s ERP, down one weekend a month. Your own company may freeze changes before a busy season. The business may work only in its own hours: a business spread across the continental United States, from Eastern to Pacific time, has an eleven-hour day, not an eight-hour one. And there are cut-offs: if finance closes the month on the third working day, everything that feeds the close has to arrive before it.

People and process. Salesforce’s decision guide asks the right questions: “What teams will be expected to maintain the integration? What skills do they currently have? What skills will they need in the future?” (Data Integration with Salesforce (opens in a new tab), Salesforce Architects, checked 2026-11-01). If the company already has an integration layer and a team that runs it, that’s a constraint in your favor: use it. If the only person who understands a tool is leaving, that’s a constraint too. The best design is one the team can keep running after the project ends.

Then the Mechanism’s Own Constraints

Everything so far is a constraint you can find on the landscape today, before you’ve chosen how to build anything. But we haven’t chosen a mechanism yet. That comes next: chapter 7 picks the pattern, and Part 2 picks the mechanism, a REST call into Salesforce, a callout out of it, the Bulk API, an event.

And when you choose a mechanism, you take on its constraints too. Every mechanism has its own limits: how many records one call can carry, how big a message can be, how many it can send in a day, how long it can run, how many can run at once. So the last step is a match. Put the numbers from this chapter next to the mechanism’s limits: your peak and your message size from module 3, your year-three growth from module 5, the allocation this integration may spend. If they fit, keep the mechanism. If they don’t, change the mechanism or change the design.

Look back at FleetLink. Frame 2 sent every truck’s latest position in one call. Whether that works depends on how many records the mechanism lets one call carry, and that’s a constraint of the mechanism, not of the landscape. Each mechanism chapter in Part 2 gives its own limits, with the release they were checked against, so you can make that match.

What an Architect Decides Here

• For every system at the other end: its capacity, at your peak, and what happens to the calls it can’t take.
• Every caller into the org, and its calls a day, against the allocation they all share, for the edition and release you checked.
• Which calls may run longer than 20 seconds, and how many at once.
• The ports, allow lists and network changes each arrow needs, and how long those changes take to get.
• The windows: maintenance, business hours and time zones, freezes and cut-offs.
• Who will run and maintain each integration, and whether they have the skills.
• Once a mechanism is chosen: its own limits, matched against this chapter’s numbers, today and in three years.

Beyond the exam: what AI changes. Agents spend allocations too, and they’re hard to predict. A person asking an agent one question can start several API calls, and an agent working through a list can start thousands. So when an agent can call into the org or out to another system, put it on the landscape as one more caller, with its own estimate of calls a day and calls at once, and watch it after go-live. And AI services have constraints of their own: limits on requests and on the size of each request, which are capacity under another name.

Explore

• Salesforce Developers, API Request Limits and Allocations (opens in a new tab): the 24-hour allocation, long-running calls and timeouts, Winter ‘27, API 68.0, checked 2026-11-01.
• Salesforce Architects, Data Integration with Salesforce (opens in a new tab): the decision factors, including teams and skills, checked 2026-11-01.
• Finding the Server: names, addresses, ports and firewalls.