Platform limits, large data volumes and data skew as architecture constraints
Key Takeaway
Plan for governor limits, large data volumes and data skew from the start: keep each parent under 10,000 child records, sort bulk loads by parent Id, and give a skewed record owner no role when ownership skew can't be avoided.
Large data volumes, data skew and platform limits decide whether an Agentforce Manufacturing org stays fast as records and users grow. Salesforce runs on shared infrastructure, so it enforces governor limits on every transaction. Data that is poorly spread across records causes slow queries, record locks and long sharing recalculations. During discovery, a consultant looks for these risks in the existing architecture, so the data model and integrations are planned for scale from the start.
Governor limits as design constraints
Salesforce runs on multitenant infrastructure, so it enforces governor limits on every transaction. A governor limit caps what one transaction can process. The limits stop any single tenant from degrading performance for the other customers on the same infrastructure.
Examples of governor limits:
- 100 SOQL queries per synchronous transaction
- 10 seconds of CPU time
- 6 MB of heap
Treat governor limits as design constraints from the start, not as obstacles to work around. Design each transaction to run comfortably within the limits at peak load and at maximum data volume. Leave room for future features, other installed packages and unexpected data patterns.
Running close to a limit is a risk even when the solution works today. A transaction that uses 95 of its 100 SOQL queries leaves no room for new features or for triggers added by other teams. Keeping transactions well under half the limit lets a solution grow without emergency refactoring.