Resource and Cost Optimization | Well-Architected Framework | Well-Architected Framework

Resource optimization and cost optimization work together for your company to achieve maximum value per cost. Salesforce manages the multitenant infrastructure, enforces the governor limits that keep the platform fair to every tenant, and prices access through licenses and consumption credits. What you optimize is the value you get back: how much business outcome each dollar of spend and each unit of platform capacity returns. Resource optimization is the mechanism: it makes efficient use of what you already pay for. Cost optimization is the outcome: it directs spend deliberately toward what drives competitive advantage. This pillar treats them as one decision because they're two views of the same goal.

This value-per-cost view shapes every architectural decision you make. When you understand the total cost of ownership, you make better trade-offs between capability and investment. You right-size solutions to match business requirements rather than over-provisioning features that go unused or under-investing in capabilities that accelerate value delivery. A license, a consumption credit, an API call, and a sandbox environment are all inputs to the same equation. What matters is the value each returns, not which ledger it lands on. The question is never "is this a cost or a resource," but "does this input have an appropriate payback?"

Neglecting this pillar produces predictable consequences. Companies accumulate unused licenses that consume budget while other capabilities remain unfunded. Inefficient architectures waste API capacity, storage, and development effort on problems that better design prevents. Resource inefficiency in particular compounds over time in predictable ways:

Performance degrades as data volumes grow.
Query timeouts emerge at a few hundred thousand records when non-selective queries scan entire tables.
Heap limit exceptions appear when solutions retrieve unnecessary fields.
CPU timeouts surface when complex calculations run synchronously.
Workarounds multiply as teams patch around each new limit.

Each of these failures is both a reliability problem and a cost problem, because the wasted computation consumes capacity that you pay for. Most critically, teams miss opportunities to invest in innovation because budget and engineering capacity are consumed by waste rather than by strategic initiatives.

Cost-effective solutions maximize value by:

Using platform capabilities that are already purchased
Aligning right-size licensing and consumption with real usage
Modeling complete cost before committing to an approach
Monitoring spending continuously against business outcomes

These practices compound. Teams that build cost awareness and resource efficiency into their design deliver more capability per dollar than teams that treat optimization as a cleanup exercise after spending has already grown.

Resource and Cost Optimization connects to other architectural pillars directly. Operational Excellence reduces ongoing costs with automation that reduces manual effort. Reliability and Trust justify premium investments through business continuity assurance and regulatory compliance value. Together, these pillars help companies to invest confidently because their architecture delivers maximum return.

Use these principles to guide your architectural decisions for resource and cost optimization on the platform.

Optimize for total cost of ownership. Total cost of ownership (TCO) extends beyond subscription fees to consumption credits, implementation costs, operational costs, integration expenses, and change management effort. Evaluate decisions using TCO analysis to reveal the complete investment picture over a solution's lifetime. Sometimes higher upfront investment reduces ongoing operational costs substantially, and TCO analysis surfaces that trade-off. Optimize for long-term value, not short-term cost minimization.
Align spend with business value. Connect every Salesforce investment to a measurable business outcome. License spending enables user productivity measured through adoption and task completion. Data 360 investment powers decision-making measured through conversion and customer lifetime value. Sandbox costs fund development velocity measured through deployment frequency and quality. When spend aligns with value, you invest confidently in what drives success and identify spending that no longer earns its return.
Design within platform limits. Governor limits define what a solution can process per transaction. Treat them as design constraints from the start, not obstacles to work around. Design transactions that operate comfortably within limits under peak load and maximum data volumes, and build margin for future features, other installed packages, and unexpected data patterns. Solutions designed within limits from conception have predictable performance and avoid emergency refactoring later.
Optimize the resources you already pay for. Before buying more capacity, maximize the throughput, efficiency, and value of platform assets already provisioned. Efficient queries, processing records in bulk (bulkification), caching, and disciplined data lifecycle reduce the compute, storage, and API consumption a solution needs. This resource efficiency is the mechanism that drives sustainable cost optimization: waste eliminated from provisioned resources improves both performance and long-term TCO.
Right-size licensing and consumption to actual use. Match each user to the license type their work requires, and design automations and agents to invoke metered services efficiently. Over-licensing and unmonitored consumption credits are among the most common and costly sources of waste. Regular audits of roles, login activity, and feature usage surface rightsizing opportunities, and clear visibility into credit burn keeps consumption-based costs predictable.
Establish financial governance and cost-aware culture. Manage Salesforce spending as a strategic investment through active oversight and shared accountability. Financial governance brings cost-benefit analysis into design decisions rather than discovering costs after deployment. Cost awareness is a shared responsibility across business stakeholders, architects, and developers who weigh cost implications alongside functional requirements, so smart investment decisions happen at every level without centralized bottlenecks.
Practice continuous optimization. Optimization is an ongoing practice, not a one-time exercise. Monitor spending and resource consumption through dashboards accessible to technical and business stakeholders. Configure alerts that fire when consumption spending reaches thresholds before runaway consumption goes unnoticed. Regular reviews uncover waste that accumulates gradually, validate that prior optimization investments delivered their expected return, and surface new opportunities as business priorities and data volumes evolve.

Understanding what Salesforce operates helps you focus optimization effort on what you control. The platform handles infrastructure-level resource management that requires dedicated teams in traditional IT environments:

Multitenant resource allocation: Salesforce ensures fair CPU, memory, and database connection sharing across all customers on shared infrastructure, monitors tenant consumption, and enforces limits that prevent any single tenant from degrading performance for others.
Governor limit architecture: Platform-enforced boundaries (100 SOQL queries per synchronous transaction, 10 seconds CPU time, 6 MB heap size) protect all tenants from resource exhaustion. Salesforce calibrates these limits to multitenant infrastructure capacity. These limits are architectural boundaries, not arbitrary restrictions.
Query optimizer and execution engine: The Salesforce query optimizer generates execution plans, maintains statistics on data distribution, and selects optimal query paths. Platform-managed indexes on standard fields accelerate common query patterns, and the optimizer adapts to data volume changes automatically.
Infrastructure scaling: Salesforce provisions hardware capacity, manages database clusters, distributes load, and scales infrastructure as usage grows. You never provision servers, manage database replication, or configure load balancers.
Platform performance optimization: Salesforce continuously optimizes core platform code, query execution, API response times, and UI framework performance, and delivers infrastructure improvements through its regular releases without requiring customer action.

Salesforce also manages the commercial side of the platform, which is why licensing and consumption belong in the same pillar as compute and storage. The platform defines the editions, license types, add-ons, and consumption-credit models through which capacity is bought, and it meters the usage that draws down those credits. You don't set those prices any more than you provision the servers, but you decide how much of each you consume: which license each user holds, how efficiently an automation invokes a metered service, how many sandboxes stay active.

These platform operations are the foundation you build on. Because Salesforce manages both the infrastructure and the pricing model, your optimization effort goes entirely into the architectural decisions you make on top of them: how efficiently you use the resources provisioned to you, and how deliberately you direct the spend that provisions them.

The Shared Responsibility Model means you own resource efficiency for everything you create within Salesforce. Platform resource management supports your work, but it doesn't replace your need to optimize. An efficient solution returns more business value from the compute, storage, and API capacity you already pay for, and that's the mechanism that keeps cost optimization sustainable rather than a one-time budget cut. Wasteful computation, in contrast, consumes infrastructure resources without delivering business value, and its cost compounds. Performance degrades predictably as data volumes grow, and workarounds multiply as teams patch around limits they could have designed within.

Your optimization responsibilities span four interconnected areas: performance, code organization, packaging, and data. Each is a value-per-cost decision before it's a technical one. This section explains how to make that decision and why it matters. The exact implementation recipes, code-level templates, Setup navigation, and specific tuning thresholds referenced in this section are in the Resource and Cost Optimization pattern library.

Performance optimization begins with a shift in how you regard governor limits. They're not obstacles to work around. They're architectural constraints that, when embraced from initial design, produce solutions with predictable performance characteristics. Every transaction executes within fixed boundaries, and those boundaries exist to enforce fair resource sharing across every tenant on the platform. An Apex transaction consuming 95 of its 100 allowed SOQL queries leaves no margin for future features, triggers added by other teams, or unexpected data patterns. Architects who keep transactions well under half the limit build solutions that can grow without emergency refactoring when a limit is exhausted. The discipline is to design well within limits under peak load and at maximum data volumes, so that adding a feature or another package's automation never pushes a transaction over the edge. A common, expensive failure: the solution works perfectly against 10 records in a Developer Sandbox, but hits governor limits in production. Developer Sandboxes copy only configuration and contain no data. Testing against realistic volumes in a Full Copy Sandbox surfaces scalability problems before customers do.

Query selectivity is the single largest lever on whether a solution scales to millions of records or times out at hundreds of thousands. Selective queries use indexes to locate records efficiently, while non-selective queries scan entire tables, consume excessive database resources, and eventually time out. The platform maintains standard indexes on a defined set of fields, and it applies selectivity thresholds that tighten as an object grows past its first million records. Architecting for selectivity means filtering on indexed fields as your primary criteria and validating with the Query Plan Tool before deploying against large objects, because a query that shows a table scan on a high-volume object is a production incident waiting to happen. Selectivity is capacity you don't have to buy: an efficient query returns in milliseconds and leaves database resources available for every other tenant and every other transaction in your own org.

Bulkification is the foundational scalability pattern that distinguishes Apex that works at scale from Apex that hits limits. The anti-pattern—a query or a DML statement placed inside a loop—works correctly with small record sets but violates governor limits the moment a bulk operation runs. The remedy is to query all needed data in single statements outside loops, organize the results into maps keyed by Id for fast lookup during iteration, and process an entire collection with batched DML. Design every automation to handle the standard 200-record trigger batch without approaching limits, and the same code scales no matter the load in production.

Asynchronous processing exists for work that can't or shouldn't complete within the synchronous limits of a user transaction. Moving that work into an async context roughly doubles the governor limits available to it and prevents long-running operations from blocking users. That headroom is real, but it isn't free, and reaching for async whenever a limit feels close is a mistake. Async is a deliberate architectural trade-off: it introduces eventual consistency, so the result of the work isn't visible in the transaction that requested it, which forces user-experience decisions that don't depend on instant confirmation. It requires explicit error handling and monitoring, because a failure surfaces in a job log rather than to the user who triggered it. And it can complicate the mental model of the system when a single business operation spans several transactions. The value-per-cost decision is to weigh that added complexity against the capacity the work genuinely needs, and to keep work synchronous when it comfortably fits.

When async is the right call, the choice among the mechanisms follows the shape of the work rather than the size of the limit. Batch Apex is for volume. It processes millions of records by dividing them into chunks, each with its own independent governor limits—which is why data migration, data archival, and bulk enrichment belong here. Queueable is for sequence: it handles multi-step workflows that exceed synchronous limits but don't need Batch scale, and it supports chaining one job from another for steps that must run in order. Platform Events are for decoupling: a producer emits an event without knowing or waiting for its consumers. Use this pattern for cross-system notification and for separating work that doesn’t belong in the same transaction, with the consideration that at-least-once delivery requires idempotent subscribers. Future methods cover the narrow case of simple asynchronous work with primitive inputs, most commonly a callout from a synchronous trigger. Their inability to chain or accept complex objects is precisely why they're not a tool for all-purpose async work. Match the async mechanism to the shape of the work. Otherwise, you trade a governor limit problem for consistency and monitoring costs that outweigh the gain.

Caching converts repeated work into capacity you keep. Platform Cache stores serializable data across transaction boundaries, so a cache hit avoids re-executing the query or recomputation that produced the value, directly reducing SOQL and CPU consumption. The decision that makes or breaks a cache is what you choose to put in it and for how long. Cache data that's read far more often than it changes, such as custom metadata, configuration, and picklist values, and set the time-to-live to match the data's volatility rather than to a single default. Reference data that changes monthly can safely cache for hours, while configuration that shifts through the day needs a short window so the cache never serves a stale value long enough to matter. A cache that's too aggressive trades a performance win for a correctness risk, and a cache with a poor hit rate spends storage without returning capacity, which is why hit rate is a metric to monitor rather than a setting to assume. Partition choice is a security decision: use the org partition for data shared across users, use the session partition for user-scoped data that must stay isolated, and never place personally identifiable information in the org partition where every user can read it. Lightning Data Service extends the same idea to the client: it shares cached records across every component on a page and eliminates redundant server round trips. Every cache hit is compute and API capacity you don't have to spend, as long as the value it returns is still correct.

Data skew is a performance hotspot created by unbalanced record distribution. When a single parent record accumulates more than 10,000 children, query performance degrades and row-lock contention emerges during concurrent operations. The threshold is a design signal, not a hard limit. It tells you to distribute load across multiple parents, monitor high-volume objects with scheduled jobs that alert as any parent approaches the boundary, and sort bulk loads by parent Id so that concurrent batches don't fight over the same rows. Ownership skew, where an integration user owns hundreds of thousands of records, produces the same lock contention and deserves the same load distribution.

Salesforce provides tooling to keep performance characteristics healthy as a solution evolves. Scale Center gives transaction-level visibility into long-running operations, row-lock contention, and transactions approaching limits, then names the specific trigger and object involved. ApexGuru applies AI analysis to production runtime telemetry to surface anti-patterns before they reach scale, and Salesforce Code Analyzer performs static analysis in the CI/CD pipeline so builds fail when queries appear inside loops or other performance defects are detected. Event Monitoring reveals consumption trends over time, and Proactive Monitoring, a Signature Success Plan feature, continuously evaluates the org for performance and scalability risks.

Code organization is a cost decision expressed as maintainability. Maintenance typically consumes the majority of development capacity for a mature solution, so the structure you choose determines how much future capacity goes to change rather than to rework. Three patterns carry most of that value. The trigger handler pattern centralizes trigger logic in handler classes and reduces the trigger file itself to a minimal delegation point, which keeps logic testable independent of trigger context and gives recursion control a single home. The service layer pattern encapsulates business logic in classes that expose operations callable from a trigger, a REST endpoint, a Flow invocable, or a batch job, so a business rule lives in one implementation rather than being duplicated across every entry point and drifting out of sync. The selector pattern centralizes SOQL for each object in dedicated classes, which makes query tuning a single-point change and gives every query an explicit, named intent.

Mixed DML errors are a distinct organizational hazard worth designing against explicitly. They occur when one transaction performs DML on both setup objects, such as User and PermissionSet, and non-setup objects, such as Account and custom objects, because setup changes that affect a user's access must be committed in a separate transaction. The failure surfaces at scale in integration jobs, in test setup, and in user-provisioning automation. The architectural remedies are to separate setup and non-setup DML across transaction boundaries using asynchronous processing or Platform Events, to design data models that avoid combining the two operations in a single business step, and to isolate setup DML in tests.

Packaging choices shape long-term development cost and the reuse you can achieve across a company. Second-generation managed packages provide source-driven modular development with namespace protection and are the right choice for Independent Software Vendor (ISV) products distributed through AgentExchange. Unlocked packages give internal teams the same modularity and dependency management without namespace overhead, which suits enterprise applications that need independent deployment but no marketplace listing. First-generation managed packages remain in use for existing products but lack the source-driven workflow that makes new modular development maintainable.

Modularity extends into the components you build. Design Lightning Web Components around a single responsibility with clear property interfaces, favor composition over inheritance so that complex UIs are assembled from small focused components, and use custom events for parent communication rather than reaching directly into a parent. Expose reusable Apex as invocable actions so that administrators can compose automation in Flow Builder from developer-built capabilities, which reduces duplication and bridges the declarative and programmatic worlds. Well-designed modularity is what lets a capability be built once and reused, rather than reimplemented and separately maintained in every place it's needed.

Unmanaged data growth is the most common source of gradual performance degradation, and it drives storage cost and sandbox refresh time in parallel. Two decisions govern data efficiency. The first is data model design. Master-detail relationships provide cascade delete, rollup summaries, and data sharing at the cost of tighter coupling. Lookups provide flexibility at the cost of custom rollup logic, and a deliberate index strategy on the fields you filter keeps queries selective as objects grow. The second is the data lifecycle. Define a complete lifecycle from creation through archival rather than letting objects accumulate records indefinitely, because an object that grows into the millions without an archival strategy eventually produces query timeouts, non-selective queries, and list views that time out.

Choose the archival mechanism only after you settle compliance. Before choosing a mechanism, confirm whether data-residency, right-to-erasure, or retention requirements constrain your options. Big Objects can't be modified after insert, which makes a records-only deletion of archived personal data a delete-and-recreate operation that can affect audit trails. Big Objects store massive historical datasets in storage separate from standard limits and suit completed transactions and audit logs no longer needed for daily work. External storage keeps data queryable through Salesforce Connect while reducing org volume and suits flexible query patterns or integration with an enterprise data warehouse. Monitor storage consumption at the object level so growth is visible before it becomes a problem, use Salesforce Files rather than legacy Attachments, and configure Field Audit Trail retention per field to what compliance requires, rather than applying a blanket maximum that wastes storage.

Cost optimization balances business value against the cost of the solution, and it depends on establishing an accurate cost in the first place. To do that, account for every cost component, because looking at a single component such as license cost leads to an incorrect understanding of what the solution actually costs. A modest license fee can hide implementation, operational, integration, and change costs that dwarf it. A decision made on the visible number alone uses only part of the picture. Total Cost of Ownership is the model that captures the full picture. It encompasses all costs associated with a Salesforce solution over its lifetime and separates them into direct costs, which are clearly associated with the solution, and indirect costs, which are real but easy to overlook. Modeling both turns a cost estimate into an informed architecture decision that weighs long-term value rather than just initial expense.

Direct costs are incurred by the implementation, operation, and maintenance of the system:

License and consumption costs are ongoing subscription fees that vary by edition, user type, and feature set, plus consumption-based credits. Edition choice is a foundational cost decision because per-user differences are significant. Consumption costs are hard to model early, so revisit those estimates as design decisions are made.
Implementation costs cover solution design, development, testing, data migration, and training. They're predominantly one-time but create ongoing maintenance obligations proportional to complexity. Companies systematically underestimate implementation effort because they focus on development and undervalue testing and training.
Operational costs cover administration, user support, monitoring, incident response, and operational tooling. They grow with solution complexity and are often invisible in planning because they manifest as internal effort rather than external invoices.
Maintenance costs cover enhancement, technical debt remediation, release adaptation, and configuration changes. Maintenance typically consumes 60–80% of development capacity for mature solutions, which makes it the largest ongoing cost category.
Integration costs include integration platform licenses, API consumption, synchronization development, and ongoing maintenance. They grow with ecosystem complexity because point-to-point integration maintenance compounds as system count increases.
Change costs cover business process redesign, change management, adoption, and stakeholder coordination. They increase with reach across business units and regions, and are frequently omitted because they manifest as business team effort.

Indirect costs aren't immediately visible in initial planning but accumulate significantly over a solution's lifetime, and for mature implementations they often exceed direct costs. A company that optimizes only its direct costs while ignoring indirect spending misses the majority of its total investment. Several categories deserve explicit attention.

Organizational costs are the investments that drive Salesforce success but never appear on a Salesforce invoice. They include internal team salaries for administrators, developers, and architects, development infrastructure such as version control and CI/CD tooling, training and certification maintenance and skill development, and the opportunity cost of development capacity allocated to maintenance rather than to innovation. That last item is difficult to detect, because it doesn't show up as spent at all. It shows up as the innovation that never shipped.

Technical debt interest is the compounding cost of architectural shortcuts. Shortcuts taken to meet a launch deadline create a maintenance burden that can require several times the original effort to resolve later, and every sprint spent remediating debt is a sprint not delivering new business value. Teams that defer architecture improvements long enough eventually find that most of their capacity goes to maintenance rather than to new capability.

Governance overhead consumes time through approval processes, coordination meetings, and manual reviews. Governance delivers real value through risk reduction and consistency, but excessive governance creates hidden costs through delayed decisions and duplicated effort, which is why the aim is to design systems that promote safe autonomy rather than requiring a centralized approval bottleneck for every change.

Unused functionality accumulates when features are implemented but never fully adopted. A partially deployed solution consumes ongoing maintenance without delivering proportional value, and license-utilization and feature-adoption monitoring reveals capabilities to invest in further or retire to redirect capacity.

Comprehensive cost visibility requires attributing both direct line items and these indirect ones, because only the full picture supports a sound investment decision.

Build TCO models for your baseline and for optimized architectural alternatives before committing to an approach. Models that project 3–5 year costs with documented assumptions let you compare options systematically. Run sensitivity analysis on the assumptions that matter most to determine the variances and boundaries of the cost estimates. Plan to revisit decisions as conditions change. The discipline of writing the assumptions down is part of the value, because it makes a later reassessment an evidence-based comparison rather than a fresh argument.

Evaluate commercially available solutions against custom development using comprehensive TCO comparison rather than initial cost alone. Build-versus-buy decisions shape long-term investment through either ongoing subscription fees or ongoing maintenance obligations, and the two paths carry fundamentally different investment profiles.

AgentExchange (formerly known as AppExchange) is the leading source of ready-made solutions from the Salesforce ISV community. Its investment profile favors speed and shared maintenance. Deployment is measured in weeks rather than the months a comparable custom build requires. The vendor maintains functionality, including platform release compatibility, without customer effort. Functionality is proven by an existing customer base, which reduces implementation risk. Specialized capabilities benefit from vendor domain expertise and research investment that exceeds what a single company would fund on its own. Support availability varies by ISV, typically with a defined escalation path for issues, and it carries an ongoing subscription cost to model.

Custom development favors fit and control. It aligns precisely to unique organizational requirements without compromising generic solution patterns, gives full control over functionality and roadmap priorities, carries no ongoing subscription beyond base platform licenses, and can create competitive advantage through capabilities unavailable to competitors using the same off-the-shelf solutions. The trade-off is that the company takes on full responsibility for maintenance and for keeping the solution compatible with each Salesforce release.

A long-term TCO comparison turns those profiles into a decision. Ready-made solutions carry compounding annual subscription fees but include vendor-provided maintenance, enhancement, and compatibility updates. Custom solutions require a one-time development investment but carry ongoing maintenance costs plus full responsibility for release compatibility. Project 3–5 year totals for both so that the comparison reflects the complete investment rather than the initial expense, which usually favors whichever option looked cheaper on day one.

Beyond raw cost, four factors shape the build vs. buy decision.

Strategic differentiation determines whether a capability is a competitive advantage worth building or a commodity better purchased.
Time to value favors buying when a capability is needed immediately to capture an opportunity or respond to competitive pressure, because substantial custom functionality takes months.
Organizational capability favors building only where a capable internal team exists with the capacity to maintain and evolve the solution over time, and favors buying when that capability is absent.
Exit cost favors options that preserve flexibility, because a solution that creates deep lock-in through proprietary formats or extensive customization is a risk if requirements change.

Systematize the decision so it rests on consistent evaluation rather than ad hoc judgment.

Licensing and consumption are inputs to the value-per-cost equation just like compute and storage, and they're among the most common sources of waste. Optimizing them isn't about blunt reductions. It's about matching every user to the right license for their work and invoking every metered service efficiently.

License optimization matches every user to the correct license type. At its core, it's about matching each user in the company to the license their work requires. Over-licensing, such as assigning full platform licenses to users who need only limited functionality (read-only access or simple workflow approvals), is one of the most common and costly mistakes companies make, and it's invisible until someone looks. A regular audit of user roles, login activity, and feature usage surfaces significant savings by rightsizing assignments across the user base. Run it on a cadence, not just at renewal — mismatches grow quietly as roles change and people change positions in the company.

Consumption credit optimization matters increasingly as companies adopt Agentforce, Data 360, and other AI-powered capabilities that price by usage rather than by seat. Credit pools can deplete surprisingly quickly when teams design their processes inefficiently or don’t monitor their usage patterns. Unlike a fixed license count, consumption can spike without any provisioning decision being made. Establish clear visibility into credit burn rates, set consumption thresholds that trigger review, and design automations and agents to be efficient in how they invoke metered services. The same efficiency work that keeps a transaction within governor limits keeps a metered service within its credit budget. That’s the same value-per-cost idea, expressed in consumption terms.

Environment and sandbox strategy is a resource decision with direct cost consequences, and a mature Salesforce delivery model requires a well-structured environment strategy. Development, testing, staging, and production environments each serve a distinct purpose, and the right mix of sandbox types lets teams build and validate changes safely before they reach production. The challenge is that without deliberate governance, the number of active sandboxes proliferates rapidly, especially on large or long-running programs, and drives up cost in ways that catch companies off guard. The remedy is to treat sandbox provisioning with the same intentionality as any other resource. Refresh or deprovision sandboxes that are no longer actively in use rather than leaving them idle, let the choice of sandbox type be driven by actual data-fidelity need rather than convenience, and set clear policies for ownership, refresh cadence, and decommissioning so the estate stays sized to the work.

Multi-org architecture multiplies cost. A single-org architecture benefits from consolidated licensing, shared platform infrastructure, and reduced administrative overhead, because there's simply less to manage, configure, and maintain. When all business units operate within one org, integrations are internal rather than cross-org, data sharing is native, and the total footprint of sandboxes, support, and governance tooling stays proportionally smaller. Multi-org architectures, although sometimes necessary for geography, regulatory compliance, or organizational separation, introduce a multiplier effect on some cost categories. Each additional org brings its own licensing requirements, its own sandbox estate, its own integration overhead, and its own administrative effort, and it demands more sophisticated tooling to manage cross-org deployment, identity federation, and data synchronization. Understand the true total cost of ownership for each additional org before making an architectural decision that's difficult and expensive to reverse.

API and integration costs are among the most underestimated cost drivers in a Salesforce ecosystem. Connecting Salesforce to an external system can look straightforward, but complex integration requirements quickly accumulate cost across middleware licensing, development effort, ongoing maintenance, and the API consumption that flows from every data exchange. Companies with many integrated systems, high data volumes, or near-real-time synchronization requirements are especially exposed. The architectural approach matters here. Chatty, fine-grained integrations that make frequent small API calls are more expensive and more fragile than well-designed bulk or event-driven patterns that minimize round trips, and the difference compounds as connected applications multiply. Govern integration design standards, consolidate integration platforms where possible, and regularly review whether existing integrations still operate as efficiently as they were originally designed.

A sustainable architecture requires more than initial design optimizations. It demands continuous oversight and structured accountability. Cost monitoring and governance are the framework that turns optimization from a one-time exercise into an ongoing operational practice. Consistent tracking and clear ownership reduce the risk of unexpected cost overages so that every dollar spent aligns with business value.

Create visibility into spending patterns through dashboards accessible to both technical teams and business stakeholders, so that investment conversations rest on data rather than on invoices. Cost visibility starts a data-driven conversation about investment priorities and optimization opportunities, and it works best when three distinct views are available. License utilization dashboards reveal inactive users, over-licensed users, and license-type mismatches, which are the optimization opportunities that hide inside a flat headcount. Capacity dashboards show storage, API, and processing consumption with growth trends, so that teams optimize before a limit causes an outage rather than after. Investment dashboards show spending by business unit, environment costs by the owning team, add-on costs against their utilization, and projected spend based on current growth, which turns a budget conversation into an allocation conversation.

These dashboards can come from a variety of tools, including Digital Wallet and custom reports that query metadata. The tool matters less than the discipline of surfacing the data where decisions are made. Share the dashboards with business stakeholders and leadership to create the transparency for an informed investment discussion rather than a reactive budget debate. A finance team that sees utilization patterns can optimize spend. A team that sees only a total invoice can only cut it.

Implement spending awareness throughout the company, including proactive alerts that flag optimization before you exceed limits:

License budgets set allocation targets by department with alerts as they approach capacity, so uncontrolled provisioning isn't discovered only at renewal.
Storage budgets monitor growth rate with alerts when trends project exceeding limits before the next renewal cycle. These alerts give advance warning so archival can be implemented before overages occur.
API budgets track consumption against limits with alerts at example utilization thresholds such as 70% and 85%, so optimization is proactive rather than an emergency response after limits cause failures.
Sandbox budgets control environment proliferation through allocation limits and approval processes.

Budget controls create cost awareness without blocking necessary investment. Alert thresholds provide early warnings that enable thoughtful optimization rather than reactive scrambling.

Cost allocation creates accountability and informed decision-making across business units, and companies implement it through one of two models that differ in how much accountability they impose. Showback reports costs by business unit without applying an actual financial charge. It creates transparency and promotes cost-aware discussion and optimization prioritization without the contention of internal billing, which suits a company that prefers collaborative cost management over financial accountability. Chargeback allocates actual costs to business units and creates direct financial accountability for consumption decisions. It drives stronger optimization behavior because costs affect departmental budgets directly, but it requires an accurate allocation methodology to prevent disputes about who pays for what. Either way, the allocation rules follow the same logic: license costs by user department, environment costs by owning the development team, integration costs by the business process consuming the integration, and development costs by the initiative funding the work. When those rules are absent, every cost lands in a central IT budget and business stakeholders treat the platform as free, which is precisely the condition that produces requests made without cost awareness.

Adapt cloud FinOps practices to Salesforce platform economics to create a continuous optimization capability rather than a periodic cleanup. Five practices carry the weight.

Cross-functional collaboration between finance, architecture, and business stakeholders ensures that cost decisions weigh business value alongside spend. It brings finance expertise into architecture discussions and technical understanding into budget planning.
A continuous optimization cadence prevents cost drift through regular review cycles: a monthly anomaly review that catches spending spikes, a quarterly utilization audit that validates license assignments and capacity usage, and an annual comprehensive TCO assessment that realigns spending with strategic priorities.
Data-driven investment decisions use utilization data and TCO models rather than assumptions or historical habits. These decisions replace "we have always done it this way" with analysis of whether current spending delivers optimal value.
Automation of cost monitoring reduces manual effort in tracking utilization, identifying optimization opportunities, and generating reports, so the practice scales with organizational complexity without linear headcount growth.
Cost-awareness education helps teams understand how architectural decisions affect total cost of ownership, because an architect who understands cost designs better trade-offs and a developer who understands platform economics writes more efficient automation.

Integrate cost awareness into the architecture review process so that investment implications are visible alongside functional and technical considerations rather than discovered after deployment. Include a cost impact assessment in the Architecture Decision Records that document major design choices. Require a TCO projection for solutions that exceed a defined investment threshold. Evaluate license implications during design, determining whether an approach requires premium licenses or add-ons before it's committed to. Assess integration cost before adopting a pattern that affects API consumption or middleware licensing. An Architecture Review Board that carries a cost perspective alongside functional and non-functional requirements produces better-aligned investment decisions. Treat cost as one input to an architectural decision rather than its sole driver, so that companies invest appropriately in what matters while avoiding waste on what doesn't.

Cloud computing sustainability focuses on minimizing the environmental impact of digital infrastructure through efficient resource use, and it aligns naturally with value per cost: the same efficiency that lowers resource consumption also lowers cost. Salesforce and architects share responsibility for sustainability outcomes. Salesforce manages the data center infrastructure, including power usage effectiveness optimization, cooling efficiency, and hardware lifecycle management, along with multitenant resource pooling and platform-level efficiency improvements. You influence the resource consumption patterns of your solutions within that multitenant environment.

The relationship between an individual solution and data center emissions is indirect, and being precise about it matters. A single tenant's optimizations don't directly reduce data center emissions. What they do is contribute to an aggregate effect: efficiency gains across all tenants let Salesforce operate its infrastructure at higher utilization and defer capacity expansion. Resource efficiency metrics, including SOQL queries, CPU time, heap consumption, and storage, therefore serve as proxy indicators for sustainability. Eliminating computational waste improves performance and cost, and it contributes to platform-wide efficiency objectives. The design principles in this pillar, including bulkification, selective queries, caching, asynchronous processing, and disciplined data lifecycle, create solutions that consume fewer resources. Sustainability isn't a separate initiative bolted onto architecture. It's what resource efficiency looks like when you measure it against environmental impact rather than only against financial cost.

Several architectural practices carry most of the sustainability value, and each one also improves performance or cost, which is why they belong in the same pillar.

Inactive automation consumes infrastructure resources without delivering any business value. Triggers that process irrelevant records, workflows that execute unnecessarily, and scheduled jobs that run when no work exists all waste computation, storage, and energy. The remedy is a quarterly automation audit with explicit criteria for what counts as unused: no executions in the past 90 days, batch jobs that consistently process zero records, and automation replaced by newer implementations but never deactivated. Document each deactivation so it can be rolled back if a business requirement resurfaces. A company carrying dozens of Process Builders left over from prior implementations, most with no executions in the past year, pays to evaluate every one of them on every relevant record save.

Scheduling resource-intensive operations during off-peak hours distributes load across time windows. In a multitenant environment, this discipline improves platform responsiveness during business hours and, in aggregate across tenants, lets Salesforce operate infrastructure at higher average utilization. Schedule batch archival, enrichment, and cleanup for low-usage windows, stagger jobs rather than launching 20 at midnight and causing a processing spike, and prefer event-driven patterns over scheduled polling so that no cycles are spent checking for work that isn't there.

Computing the same value repeatedly wastes CPU cycles and infrastructure capacity. Calculate once, cache the result, and reuse it across transactions and users. Platform Cache serves reference data queried repeatedly, cached rollup values avoid real-time aggregate queries where near-real-time accuracy is sufficient, formula fields recalculate dynamically on record access rather than storing a value and requiring automation to maintain it, and Lightning Data Service eliminates redundant server requests on the client. Each avoided computation is capacity returned to the platform.

Data storage consumes infrastructure resources and degrades query performance as it grows. Retention policies that archive or delete data no longer needed for active operations keep active tables small and queries fast. Archive aged records to Big Objects or external storage on a scheduled job, hard delete when compliant rather than relying on soft deletion that continues to consume storage, and configure Field Audit Trail retention per field rather than applying a maximum that stores far more history than compliance requires. As with scheduled processing, individual archival decisions don't directly reduce data center energy use, but aggregate data-lifecycle discipline across all tenants improves platform efficiency and defers storage infrastructure expansion.

External integrations consume resources in both Salesforce and the systems they connect to. Change Data Capture and other event-driven patterns eliminate the polling calls that repeatedly check for changes and find none, which reduces API consumption, benefits governor limits, and removes wasteful computation. Composite API patterns aggregate multiple operations into a single call, Bulk API v2 processes large volumes far more efficiently than thousands of individual REST calls, and retry logic with exponential backoff avoids hammering a struggling external system. A single integration that polls every five minutes and finds nothing to do most of the time is pure waste, while the same integration driven by change events processes only real changes.

Agent architectures consume computational resources through large language model inference, and the same efficiency mindset applies. Minimize prompt length, summarize conversation history rather than carrying full verbatim transcripts that grow without bound, use the smallest model sufficient for a task rather than defaulting to the most capable, and cache reference data and deterministic responses. Retrieving 50 vector-search results when only 5 are evaluated spends inference and retrieval resources with no added value, so configure retrieval limits to match actual usage.

Sustainability, like the rest of this pillar, requires ongoing monitoring rather than a one-time pass, because resource consumption patterns change as solutions evolve, data volumes grow, and user populations expand. Monitoring matters only when it triggers action. Define actionable thresholds for each metric—SOQL query count that exceeds a target per transaction, storage growth beyond a monthly percentage, or a cache hit rate that falls below a target—and document which optimizations to pursue first. Focus effort on high-volume transactions and frequently executed automation, where efficiency improvements have the greatest aggregate impact. Process Builder reached end of support on December 31, 2025. Migrate remaining Process Builders to Flow; don’t just deactivate them.

Use this checklist to assess whether a solution returns maximum value per cost. It combines the resource-efficiency and cost-discipline practices from this pillar into one review, because the two are a single decision.

Value and cost modeling

Connect every significant Salesforce investment to a measurable business outcome.
Model total cost of ownership across direct, indirect, one-time, and ongoing categories before committing to an approach.
Compare TCO for the baseline and for optimized architectural alternatives over a 3–5 year horizon.
Apply a consistent build-vs-buy evaluation that weighs strategic differentiation, time to value, and exit cost rather than relying on ad hoc judgment.

Resource efficiency

Design transactions to operate comfortably within governor limits under peak load and maximum data volumes.
Make queries selective against indexed fields and validate with the Query Plan Tool before deploying against large objects.
Bulkify all data operations and choose asynchronous processing deliberately where synchronous limits require it.
Cache reference data through Platform Cache and Lightning Data Service to avoid repeated queries and recomputation.
Prevent data skew by distributing load and monitoring high-volume objects.
Centralize trigger, service, and selector logic so business logic stays testable and cheap to change.
Define a complete data lifecycle from creation through archival, and monitor storage consumption at the object level.

Licensing and consumption

Match each user to the license type their work requires, and audit roles, login activity, and feature usage regularly.
Establish visibility into consumption credit burn rates and design automations and agents to invoke metered services efficiently.
Govern sandbox provisioning with clear ownership, refresh cadence, and decommissioning policies.
Understand the full multi-org cost multiplier before adding an org, and favor bulk or event-driven integration over chatty patterns.

Monitoring and governance

Provide cost and capacity dashboards accessible to both technical teams and business stakeholders.
Set budget alerts for licenses, storage, API consumption, and sandboxes so optimization is proactive rather than reactive.
Establish showback or chargeback so cost allocation creates accountability across business units.
Adopt a FinOps cadence: monthly anomaly review, quarterly utilization audit, and annual comprehensive TCO assessment.
Integrate cost impact assessment into architecture reviews and Architecture Decision Records.

Continuous optimization and sustainability

Treat optimization as an ongoing practice, and validate that prior optimization investments delivered their expected return.
Eliminate unused automation and redundant computation through regular audits.
Track resource consumption over time and define actionable thresholds that trigger optimization when a metric crosses them.

Share your feedback on the Well-Architected Framework.