# How to design a scalable Salesforce architecture for high growth

One person owns automation on each object. Limits are a design input. What is packaged stays separate from local configuration.

**Published:** 2026-01-01
**Canonical:** https://synconai.com/scalable-salesforce-architecture
**Author:** SynconAI Architecture Team

## In short

Design for growth by naming one automation owner per object, treating governor limits as an input you design under, and drawing a line between what is packaged and what is local configuration. Orgs get brittle when every request adds another flow on the same save. The owner merges or refuses. New work lands on that diagram before it lands in production.

## Sources

- **Agentforce: How do you build AI agents?** (retrieved 2026-10-10)
  https://www.salesforce.com/agentforce/
  > Businesses can build agents with Agent Builder using existing Salesforce Platform tools to create standard and custom subagents and actions.
- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs.

## What to take away

- One named owner per object decides what runs when a record saves.
- Governor limits are a design input. Look up the figure for your edition rather than inheriting a stale number.
- Packaged baseline holds shared objects and protective automation. Local configuration stays local.
- A new flow on every request is how growth breaks the org.

## The guide

A campaign lands on a Friday. The opportunity save, which used to be a moment, now takes long enough that sellers click twice. Seven flows run. Two of them write the amount. Which one wins depends on an order nobody has written down since the person who built the third flow left. A pilot, in a hurry, adds an agent action that updates the stage from outside that list. Under the Monday load the save fails for a slice of records. Someone finds a number in an old post, pastes it into the design as the daily ceiling, and asks for the limit to be raised. The number is not the edition you pay for. The raise, if it arrives, will be spent by the next workshop, because nothing in the design got smaller.

Growth breaks the org that added a flow every time someone asked. The save gets slower. The order of automation becomes folklore. The next cloud copies the mess into a second place. Scale is a diagram you can still explain: who owns each object, what is allowed to run on save, what is packaged, and what a country may change without forking the model.

## One automation owner per object

Account, opportunity, case, and the custom objects that carry revenue or entitlement. Each has a named owner for flows, Apex, and the order they run in. The name is a person, written on the diagram, not a team alias that nobody monitors. A request for "a small flow" goes through that owner. They can merge it into what already runs, or they can refuse it. Refusal is the job. An architecture practice that cannot refuse will accumulate one automation per workshop until nobody can say what happens when a record is inserted, and the next incident will be diagnosed by reading flows in the order the platform happens to run them.

Write the order down, in three bands. Before-save work that must be true for the record to make sense: a default, a derivation, a block when a required fact is missing. After-save work that can live with a short delay: a notification, a child record, a call to another system that must not sit inside the save. Scheduled or batch work that was never a good idea on the save itself: a recalculation across a family of records, a push of a whole book of business, a retry loop. If a design puts the third band on the save, the owner sends it back before anyone argues about limits. The limit is the symptom. The band is the decision.

If two automations write the same field, the owner picks one this month, not after the next production incident. Two writers on amount, or on stage, means the value you see depends on which flow finished last. That is not a business rule. It is a race. Merge them, or give them different fields with different names. A comment in one flow that says "do not touch, the other flow handles this" is how the race survives a handover.

Recursion belongs on the same page. A flow that updates the record it started from will run again. If the owner cannot point at the condition that stops the second run, the flow is not finished. "It has not looped yet" is not a condition. It is a wish that the data stays in the shape you tested.

Workflow Rules and Process Builder reached end of support on 31 December 2025. That date is about those automation tools. It is not a date on which Classic disappears, and this guide will not invent one. If those tools still run work the business needs, they are on the object owner's list. Rebuild them in Flow, with tests, on their own plan. Do not bury the rebuild inside a page-layout weekend, and do not leave them as unmarked boxes the diagram pretends are someone else's problem. New work lands in the tool you can still support. The owner says where.

## Limits are an input

[Data 360 help](https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5) states the commercial shape of one feature set: "Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs." Read it as a habit, and keep it scoped. Those are Data 360 licences and Data 360 limits. Platform governor limits on Apex, Flow, and API calls are a different page. They differ by edition and by what the transaction is doing. Design under them. Look up the current figure for the edition you pay for when you need a number, and write the date you looked next to it. This guide will not print one. A number remembered from a blog, or from another customer's org, will be wrong for somebody, and it will be the number that ships.

Do not wait for a failed save in production to discover that one record does too much. Count, in the design, what a single save will query, write, and call. If the honest count only fits when the record is small and the related lists are empty, the design is for a demo. Move heavy work to batch, to a scheduled path, or to a system built for that volume. A raised limit, where your contract allows one, is a planned change with a date and a cost. It is not the design. Spending the raise on another flow, the following month, means you bought capacity and filled it with the same habit.

API calls made from the save, or from a poll sitting beside it, are part of the same picture. Several integrations will meet the allowance together if none of them has a budget. That register is the subject of [how to govern API limits across the clouds you run](/govern-api-limits-salesforce). An automation owner who adds a callout and does not tell that register has designed a failure for a team they do not sit with. The register is a list of callers and a budget each of them may spend. It is not a hope that the edition will be generous on the day the book of business is pushed.

:::warn
Do not print a limit from memory. Editions differ, and so do the licences on top of them. A figure from an old slide will be wrong for someone, and several designs will be sized to it before anyone checks.
:::

## Packaged behaviour and local configuration

What must be true in every business unit belongs in a package or a managed baseline. The objects. The required fields. The automation that protects them, including the block that stops a save when the commercial fields are empty. What is local stays configuration a local admin can change: page layouts, picklist values that are truly local, a report folder, a translation. The line is the point. Write it as a column on the diagram, not as a principle in a slide that the next project will not open.

If every country forks the object, you do not have a product. You have copies, and the next fix lands in one of them. The other countries keep the defect, and a global report silently compares fields that no longer mean the same thing. A local field that must be global is a decision to put it in the package, with the pain of a migration. A global field that only one country fills is a decision to take it out, before every other country types a dummy value to get past the save.

Local does not mean invisible. The owner of the object still knows which local values exist, because a local picklist that drives a global flow is not local. If a country's value changes the path of packaged automation, that value is part of the contract. Put it in the package, or stop the flow from depending on it.

## Agent actions join the list

Salesforce says: "Businesses can build agents with Agent Builder using existing Salesforce Platform tools to create standard and custom subagents and actions." Those actions are platform automation. They join the object owner's list. An agent action that writes the opportunity, built outside the owner because a pilot was in a hurry, is another flow. It can recurse, it can write a field a flow also writes, and it can do it as a user with wider access than the seller it is helping. Treat it as one item on the diagram: the object, the fields it may change, the user it runs as, and the owner who accepted it.

A pilot that "just tries an action" in production has skipped the diagram. The owner can still refuse it after the fact, which is worse, because someone has already seen it work and will ask for it back. The refusal is easier the week the request arrives. Wide access so the action returns an answer is not an architecture decision. It is an access decision, and it belongs with the running user, not with a sentence in the instructions.

:::note
Before-save work has to be true for the record to make sense. After-save work can wait a moment. Anything that recalculates a set of records, or calls out and retries, does not belong on the save. The owner sends that request back with the band written on it.
:::

| On the diagram | Who fills it | A gap looks like |
| --- | --- | --- |
| Object owner | One named person | "The team" or a departed builder |
| Order of automation | Before-save, after-save, scheduled | Two flows write the same field |
| Packaged | Objects, required fields, protective automation | A country has forked the object |
| Local | Layouts, truly local values, report folders | A local value changes a global path |
| Off the save | Batch, schedule, or another system | The save fails when the record is no longer small |
| Agent actions | The same owner, with the running user named | A pilot action nobody merged |

## The one-page diagram

Objects. The automation owner. What is packaged. What is local. Which work is synchronous on save. If you cannot draw it, you cannot grow it. New clouds and new agents land on the diagram before they land in a sandbox. If a design needs a second flow on the same object for the same event, the owner merges the two or sends the request back. That conversation is the architecture. The tools are whatever you already run.

Cheap, while the seventh flow is still a request: the refusal, the merge, the decision to move work off the save. A conversation in the week the request arrives.

Expensive, after the save fails in production and every country has a copy: finding which flow wrote the amount, which action the pilot added, and which limit number in the design was never your edition. That archaeology is the cost of a diagram you did not keep. Draw it before the next cloud. If a box will not fit on the page, the box is the thing to remove, not the page to enlarge.

## Questions

### Who owns automation on an object?

One named person for each object that matters: account, opportunity, case, and the custom objects that carry revenue or entitlement. Requests for another flow go through them. They merge it into what already runs, or they refuse it. Refusal is the job. If two automations write the same field, the owner picks one now, rather than after a production incident. An owner described as the whole team is nobody when the save fails.

### How should limits affect the design?

As an input you design under, not as a surprise after a failed save. Data 360 help documents add-on licences and usage limitations for its own features, and says many of those limits can be adjusted. Platform governor limits are a separate page and differ by edition and by the transaction. Look up the current figure for the edition you pay for. Do not ship a number from memory or from another org. A raised limit, where the contract allows one, is a planned change rather than a substitute for moving heavy work off the save.

### What belongs in the package?

Shared objects, required fields, and the automation that protects them in every business unit. Page layouts, picklist values that are truly local, and report folders stay local configuration. If every country forks the object, the next fix lands in one copy and the others keep the defect. A local value that changes the path of a global flow is not local. Put it in the package, or stop the flow from depending on it.

### Where do agent actions fit?

Salesforce says businesses can build agents with Agent Builder using existing platform tools to create standard and custom subagents and actions. Those actions are automation. The object owner governs them with the flows and Apex already on that object. A pilot action built outside that list, because a demo was in a hurry, is another flow. Name the fields it may change and the user it runs as. Wide access so the demo returns an answer is an access decision, and it does not belong in the instructions.

### What is the diagram for?

One page: objects, owners, packaged versus local, and which work runs on save. New work lands on the diagram before it lands in production. If you cannot draw it, you are not ready to add a cloud or an agent. Before-save work has to be true for the record, and scheduled or batch work stays off the save. Workflow Rules and Process Builder reached end of support on 31 December 2025, which is an automation date rather than a Classic shutdown, and anything still running in those tools sits on the owner list until it is rebuilt.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce development (https://synconai.com/salesforce-development).