← Back to Blog

Insights

Scaling Salesforce for Growing Companies: The Complete Guide

Digital illustration showing a growing Salesforce organization scaling upward with connected data streams and users

Scaling a Salesforce org from 10 to 100 users requires far more than adding license seats. The configurations, sharing rules, automation, and data architecture that worked for a handful of users will crack under the weight of a growing organization. Without deliberate architectural decisions around governor limits, data volume management, permission structures, and pre-growth org audits. Companies face slow page loads, record lock errors, frustrated users, and escalating technical debt. Mid-market companies that invest in strategic Salesforce scaling avoid these outcomes entirely. By fixing the foundation before adding users, they turn the CRM into a growth accelerator instead of a bottleneck. Ready to scale your Salesforce org without breaking it? Schedule a free Salesforce strategy session with Omnivo Digital today. Omnivo’s senior consultants build scalable Salesforce architectures for growing companies using a business-first, technology-second approach with results-based pricing. This article covers why configurations break at scale, the specific governor limits that matter most, how to restructure permissions for a 100-user org. A step-by-step pre-growth audit process, and a real case study of how Unison achieved 10x growth using Salesforce as its operational backbone.

Scaling Salesforce For Growing Companies: Why Salesforce Configurations That Work at 10 Users Break at 100

Many mid-market companies build their first Salesforce org with a small team in mind. A handful of users, straightforward sharing rules, a few simple flows. It works. Then the company grows. New sales reps join. Customer success managers need access. Operations wants reporting. And suddenly, pages load slowly, records lock unexpectedly, and users start complaining that Salesforce is “broken.” The root cause is almost never a single configuration error. It is an accumulation of small decisions that worked at 10 users but compound into systemic failure at 100. Here are the most common breaking points.

Ready to turn insights into action?

Build a smarter Salesforce strategy with Omnivo Digital.

Connect with our team to discuss your CRM goals, Salesforce challenges, and the best next step for your business.

Permission Set Sprawl

When you have 10 users, managing access through a handful of profiles is manageable. At 100 users, profiles become a bottleneck. You end up assigning excessive object permissions through profiles because creating a new permission set for every role variation feels heavy. The result: users see data they should not, or cannot access data they need.

Sharing Rule Anti-Patterns

Small orgs often rely on a simple role hierarchy for record visibility. As the org grows, manual sharing rules proliferate. Salesforce imposes limits on certain sharing rule configurations, and crossing those thresholds can lock you out of making further changes without a support case.

The Record Lock Problem

At 10 users, two people rarely edit the same record simultaneously. At 100 users, contention spikes. Unbulkified Apex triggers that worked fine with one-at-a-time updates start throwing record lock errors. The same automation that ran cleanly in year one becomes a daily frustration in year three.

Technical Debt Acceleration

IEQ Capital, a financial services firm that Omnivo Digital worked with, had accumulated 4.5 years of unpopulated Financial Account relationships and erroneous Household data. Their operations team spent 20 to 30 man-hours every week on manual data fixes. That is the real cost of unscaled architecture: not just system slowness, but human time burned on compensating for it. The lesson is clear. If you are planning to grow from 10 to 100 users. The time to fix the architecture is before the new users arrive, not after they start reporting problems.

Governor Limits, Data Volume, and the Architectural Decisions That Matter

Every Salesforce org operates within governor limits. These are platform-imposed boundaries that prevent any single tenant from consuming excessive resources. At 10 users, you rarely notice them. At 100 users, you hit them daily. Understanding which limits matter most is the first step in designing for scale.

The Five Most Critical Governor Limits

  • 100 SOQL queries per synchronous transaction. Every Apex trigger, class, and flow counts toward this limit. At 100 users, the volume of concurrent transactions means inefficient query patterns get exposed fast. A trigger that queried accounts inside a loop worked fine with one user updating one record. With 50 sales reps updating opportunities simultaneously, it throws query exceptions.
  • 10 MB maximum heap size. Large data sets processed in a single transaction exceed this limit. Archiving old records and using skinny tables keeps heap usage manageable.
  • 2,500 asynchronous callouts per hour. Integrations with ERP systems, marketing platforms, and financial tools consume this budget. Each integration needs a throttling strategy.
  • 50,000 total daily API requests per org (Enterprise Edition). Every connected app, every integration, every third-party sync tool counts. Monitoring API consumption is essential before it becomes a blocker.
  • 10,000 records returned per SOQL query. A query that returned 200 records for a 10-user org might return 8,000 for a 100-user org, consuming governor budget and slowing page loads.

Data Volume Management

As user count grows, so does the data they create. Old opportunities, closed cases, completed tasks, and archived leads accumulate. Without a data archiving strategy, page layouts slow down, reports time out, and list views become unusable. Salesforce provides tools for this: skinny tables for standard and custom objects, indexed fields to speed up common queries. And Big Objects for storing massive data sets without affecting transactional query performance.

Bulkification: The Non-Negotiable Practice

Every trigger, every flow, every invocable method must handle batches of records. A trigger written to process one record at a time will fail when an import job updates 200 accounts simultaneously. Bulkification means using collection-based processing: iterating over lists, not performing DML inside loops. Metroll, a building supplies manufacturer with 273 employees, proved what is possible with proper architecture. Omnivo Digital built a custom manufacturing ERP on Sales Cloud that handles the entire order lifecycle across quoting, work orders, invoicing, shipping, purchase orders, inventory, and COGS. The system supports their full team without hitting governor limits because it was designed for their scale from day one. Read more about Salesforce CRM for manufacturing companies and how smart architecture enables real operational scale.

Restructuring Roles, Profiles, and Permission Sets for a Scaled Org

When your org had 10 users, you probably assigned everyone a “Sales User” profile and moved on. At 100 users, that approach breaks. Different teams need different access. Sales wants to see pipeline. Service needs case history. Operations touches everything. And management needs cross-functional visibility without interfering with day-to-day work.

Profiles vs. Permission Sets: The Right Tool for the Job

Capability Profiles Permission Sets
Best for Base-level access per user type Granular feature assignments on top of a profile
Scalability Limited: profile edits affect every user on that profile High: assign to specific users, groups, or roles
Count limits ~25 profile-based sharing rules No practical limit per user
Change flexibility One wrong edit impacts dozens of users Add or remove access without side effects

The recommended pattern: use profiles for broad categories (Sales User, Service User, System Administrator). Use permission sets to grant specific feature access.

Role Hierarchy vs. Sharing Rules

A role hierarchy grants upward visibility automatically: every manager sees what their reports see. This works well at small scale. But at 100 users, the role hierarchy can become a mess of deeply nested roles built to mimic an organizational chart that changes quarterly. The better approach: keep the role hierarchy flat at three levels max and use sharing rules and manual sharing for row-level visibility exceptions. This gives you granular control without the complexity of deep role trees.

Permission Set Groups

Salesforce introduced Permission Set Groups to bundle related permission sets together. A “New Sales Hire” group might include a Standard Sales User permission set, a Territory Access permission set, and a Mobile App permission set. When a user joins, assign the group once. When they change roles, swap the group. This eliminates the per-user micro-management that bogs down admins in 100-user orgs. For more on getting users to actually adopt the system at scale, check out the Omnivo guide to improving Salesforce user adoption.

How to Audit Your Salesforce Org Before a Growth Phase

Before you add the next 50 users, run a pre-growth org audit. Skipping this step means every new user inherits the existing problems. A thorough audit provides a roadmap for what to fix, what to defer, and what to design differently for the larger org.

Step 1: Current State Analysis

Start by documenting exactly what your org looks like today. Pull a report of all active profiles, permission sets, roles, sharing rules, flows, process builders, Apex triggers, validation rules, and custom objects. Map the data model. Note every integration and API consumer. This is not a feel-good exercise. IEQ Capital’s Org Audit revealed that Financial Account relationships to Households had been unpopulated or erroneous for 4.5 years. That discovery alone recovered 20 to 30 hours of weekly manual data fixing. An audit finds the hidden costs you have been paying without realizing it.

Step 2: Technical Debt Identification

Flag every workaround, every “we will fix it later” configuration, and every deprecated feature still in use. Common findings include:

  • Workflow rules that should be flows (Salesforce is deprecating workflows)
  • Aura components that should be Lightning Web Components
  • Formula fields with unbounded text returns that slow queries
  • Unused fields and objects cluttering the schema
  • Process builders that fire on every create or edit without conditions

Step 3: Goal Alignment Review

Map every existing configuration back to a business requirement. Any feature that does not serve a current business goal is either technical debt or a candidate for removal. This step also identifies gaps: capabilities your team needs at 100 users that do not exist yet.

Step 4: Roadmap Development

Prioritize fixes by business impact. Quick wins such as removing unused fields and cleaning sharing rules can be done immediately. Architectural changes such as migrating from Aura to LWC or restructuring the data model go into a phased plan. The roadmap should align with your hiring plan: fix the infrastructure before the team that will stress-test it arrives. IEQ Capital’s Org Audit produced a blueprint that led to a 400-hour engagement spanning six months. Omnivo resolved the 4.5-year relationship maintenance issue, migrated from Aura to LWC, and implemented Data Processing Engine with Rollup by Lookup configurations. The result: Operations team burden dropped from 20 to 30 hours of weekly data fixes to minimal levels. Before any data-heavy restructuring, refer to Salesforce data migration best practices for a practical migration checklist.

How Unison Scaled 10x Using Salesforce as Its Operational Backbone

One of the strongest proofs that deliberate Salesforce architecture enables growth comes from Unison, a financial services firm specializing in equity origination. With 149 employees and $5.5 billion in assets under management. Unison partnered with Omnivo Digital to transform its Salesforce org from a basic CRM into the operational backbone of a scaling business.

The Challenge

Unison needed a Salesforce implementation that could support aggressive growth. The company was scaling from approximately $3 million to $30 million in monthly equity origination volume. Their org had to handle Person Accounts, Household relationship management, and the complex compliance and regulatory requirements of financial services.

The Solution

Omnivo implemented a Financial Services Cloud optimization tailored to Unison’s equity origination workflow. The architecture focused on:

  • Person Accounts and Household management: accurately modeling the relationships between individual investors, family groups, and their equity holdings
  • Compliance-first configuration: building FINRA and SEC-aligned data tracking into the core data model rather than adding it as an afterthought
  • Scalable automation: ensuring every flow and trigger was bulkified to handle the projected transaction volume increase

The Result

Unison achieved 10x growth enablement. Their Salesforce org scaled from supporting a small team to powering a financial services operation that originates $30 million in equity per month. The system handles the full investor lifecycle without the performance degradation, record lock errors, or data quality issues that plague poorly scaled orgs. This case illustrates the broader principle: scaling a Salesforce org from 10 to 100 users is fundamentally a business strategy problem, not just a technical one. The architecture decisions made before the growth phase determine whether the system accelerates or impedes the company’s trajectory. For more on measuring the business value of your Salesforce investment, read Omnivo’s guide to measuring Salesforce implementation ROI.

Frequently Asked Questions

What happens when you add more than 10 users to Salesforce?

When you exceed 10 users, your org may encounter governor limits on API calls, record locks, and concurrent automation. Permission sets become harder to manage, sharing rules that worked for a small team start causing record-access issues, and unbulkified triggers throw errors under load. A strategic review of profiles, sharing rules, automation, and the data model is recommended before scaling past 10 users.

How do governor limits change as a Salesforce org grows?

Governor limits remain the same per-transaction regardless of org size, but the probability of hitting them increases with more users, records, and automation. Key limits include 100 SOQL queries per synchronous transaction, 10 MB heap size, and 2,500 asynchronous callouts per hour. At 10 users you rarely notice them. At 100 users you plan around them.

What are the most common Salesforce scaling mistakes?

Building automation without bulkification, overusing formula fields on large datasets, failing to archive old records. And assigning excessive object permissions through profiles instead of permission sets are the most frequent errors. These issues compound as user count grows, leading to slow page loads, record lock errors, and low user adoption.

Should I restructure my Salesforce org before or after adding users?

Restructure before adding users. Conduct an org audit to identify technical debt, inefficient sharing rules, and automation bottlenecks. Clean up your data model, permission sets, and role hierarchy before onboarding new users. Adding 50 new users to a poorly configured org multiplies existing problems and makes the cleanup more expensive.

How does Omnivo Digital help companies scale their Salesforce org?

Omnivo Digital starts every engagement with a comprehensive Org Audit that assesses current state, technical debt, goal alignment, and the right architectural roadmap. Using a product management approach, Omnivo’s senior consultants prioritize the highest-impact fixes first. With results-based pricing, clients only pay when deliverables are completed in Salesforce.

Ready to Scale Your Salesforce Org?

A growing company should not have to choose between adding users and maintaining system performance. Omnivo Digital builds Salesforce architectures that scale with your business. Talk to a senior Salesforce consultant about your growth plans, your current org health, and the fastest path to a scalable foundation. Omnivo’s unique “Pay for Results, Not Hours” model means you only pay when deliverables are completed. Schedule a Free Strategy Session

Ready to turn insights into action?

Build a smarter Salesforce strategy with Omnivo Digital.

Connect with our team to discuss your CRM goals, Salesforce challenges, and the best next step for your business.