Summer ’26 Release Architect Highlights: Sharing, Security, and Agentic Integration

Every Salesforce release requires an architect’s attention. Your mandate is not to read everything, but to immediately identify changes that invalidate existing decisions, break production systems, or unlock new design possibilities. 

We will review the Summer ’26 Release in order of architectural priority: 

1. Act now
2. Rethink design decisions
3. Explore design opportunities 

This release delivers substantial opportunities in the third category, but it also contains more critical items in the first two than a typical release.

1. Act now: Security changes with hard enforcement dates

This category covers critical updates across authentication, security, and platform architecture that require immediate action and testing. Start these conversations with your customers now, because each of these requires architectural change beyond a configuration toggle.

Review the Apex security model changes in API version 67.0

Three changes arrive together in API version 67.0 (v67.0), representing the most significant shift to the Apex security model in years.

1. Database operations now run in user mode by default. Previously, SOQL, SOSL, DML, and Database methods defaulted to system mode, bypassing the current user’s field-level security (FLS) and object permissions. From v67.0 onward, those same operations enforce the running user’s permissions. Review any code written with an implicit assumption of system mode access before incrementing the API version.
2. Apex classes without an explicit sharing declaration now default to with sharing. Previously, Apex defaulted to without sharing in most cases. Classes relying on that implicit bypass of sharing rules will behave differently on v67.0. In some cases, they may expose less data than expected. In others, they may surface access errors that were previously silent.
3. The WITH SECURITY_ENFORCED SOQL clause is entirely removed in v67.0, replaced by WITH USER_MODE. Any class still using the old clause on v67.0 will not compile. This change is not just syntactic; it is a security shift. While v66.0 defaults database operations to system mode, v67.0 flips the default to user mode, and WITH SECURITY_ENFORCED becomes a compiler error. Audit all Apex for uses of WITH SECURITY_ENFORCED. For new code, explicitly declare access mode using WITH USER_MODE to make intent clear and avoid relying on implicit defaults. Any query that requires system-mode execution must include WITH SYSTEM_MODE. 

Queries now enforce both sharing rules and FLS through the running user context. If the running user is an integration user with broad access, the behavior may not change. If the running user is a standard end user with restricted visibility, records and fields that were previously returned will now be filtered. Test both scenarios.

Apex triggers are a deliberate exception: they always run in system mode and always will. But the handler classes that triggers call are affected if they lack explicit sharing declarations. The standard pattern of delegating trigger logic to a handler class needs an audit pass for any class currently relying on implicit without sharing behavior.

The architectural implication is not just about the code itself. It is about testing strategy. Your existing Apex test coverage was written against the old security defaults. Tests passing in v66.0 do not guarantee correct behavior in v67.0. Add test scenarios that run as restricted users and assert the correct data visibility before upgrading any class to the new API version. For managed packages in particular, this review is nonnegotiable before deployment.

Plan now for the OAuth and retirement deadlines

Critical retirement deadlines for authentication patterns, legacy API versions, and core features like Salesforce to Salesforce (S2S) demand architectural attention. Review these sunset dates and prioritize migration strategies now to prevent production outages and maintain integration continuity across your landscape.

Retirement 1: The OAuth 2.0 username-password flow for connected apps is retired in Winter ’27. 

Any integration authenticating with a username and password embedded in the configuration needs to migrate. The two supported replacements are the OAuth 2.0 web server flow and the OAuth 2.0 client credentials flow, and the right choice depends on the integration pattern. 

• Use the web server flow for user-facing integrations where a named user context matters. The flow authenticates on behalf of a specific user and returns a token scoped to that user’s permissions. 
• Use the client credentials flow for server-to-server integrations where no user context is needed. In this case, authentication occurs as the connected app itself using a client ID and secret, making it better suited to background jobs, ETL processes, and middleware connections. 

If you have integrations currently using a single username-password that run as an integration user specifically to control data access, the client credentials flow with a carefully scoped permission set is the right migration target.

Retirement 2: SOAP API login() is fully retired in Summer ’27 

The SOAP API login() call in versions 31.0 through 64.0 retires in Summer ’27. Summer ’26 introduces additional controls around SOAP API login(): newly created orgs require explicit enablement, and a new permission-based enforcement model can also be enabled in existing orgs. Older enterprise integrations, middleware platforms, and legacy ERP connectors are the most likely surface area here. The migration path is REST API with OAuth, which is more performant and better supported. 

Retirement 3: Salesforce to Salesforce (S2S) is retired in Spring ’27 

The recommended replacements are Data Cloud One, Partner Cloud, MuleSoft Anypoint Platform, and MuleSoft for Flow. The recommended replacement depends on the requirement:

• Data Cloud One when the requirement is unified data access across orgs with semantic consistency. The right choice when you need a single view of the customer across org boundaries, not just record exchange.
• Partner Cloud when the requirement is sharing information and collaborating with external partners. The right choice when needing a full-featured Partner Relationship Management solution. Partner Cloud (released in 2024) uses an alternative to S2S for data sharing.
• MuleSoft Anypoint Platform when the integration requires transformation, routing, error handling, or orchestration. The appropriate path for complex, bidirectional integration where Salesforce to Salesforce was being used as a shortcut for an integration that always needed proper middleware.
• MuleSoft for Flow when the use case is process-level and the team is declarative-first. Replaces workflow handoff patterns without requiring full Anypoint Platform investment.

Salesforce to Salesforce was often used as a low-friction shortcut for scenarios that genuinely needed one of these more structured patterns. The retirement creates an opportunity to make that architectural choice explicitly rather than inherit it, but it will require substantial change and planning.

Act before this release ships: SAML and domain changes

The single-configuration SAML framework retirement is enforced in Summer ’26. If your org is still using the original framework, which supports SSO with only one identity provider, your SSO configurations will stop working when this release lands. The migration to the multiple-configuration SAML framework is documented and manageable, but it is not something to leave until the day before sandbox preview, and must be completed before the Summer ‘26 release date. 

Salesforce will also require routing domain URLs through the Salesforce Edge Network. If your org uses custom My Domain configurations or instanced URLs in API traffic, verify your domain setup is compliant before the release hits your instance. Note that this is a separate requirement from the Update Instanced URLs release update, which was postponed to Winter ’27. The Edge Network domain adoption follows a separate and earlier enforcement time. 

Understand the IPv6 preparation window

Salesforce is rolling out IPv6 support progressively, starting with Government Cloud orgs in 2026. The architectural concern is IP allowlists. If your clients restrict network access to Salesforce using IP address ranges on profiles or at the network perimeter, those allowlists need to include IPv6 addresses before IPv6 is live for their org. IPv4 and IPv6 ranges cannot coexist in a single profile-level login IP range entry; they are separate rules.

Salesforce has committed to giving at least two months’ notice before enabling IPv6 for each affected org. But two months is not much runway when the change requires network team engagement, firewall rule updates, and change control approval. Start now by identifying which clients are running IP-based network restrictions, confirming whether their network teams have IPv6 address ranges available, and building that update into the roadmap. Domain allowlists are the more future-proof architecture here: they are protocol-agnostic and sidestep the IPv4/IPv6 split entirely.

2. Rethink: Platform changes that affect existing design decisions

The items in this category are not breaking changes, but they should influence future recommendations and may prompt you to revisit existing decisions.

Reconsider async governor limit architecture

The Elastic Limits for Asynchronous Jobs feature, now in Beta, changes the calculus for high-volume async patterns. Orgs that exceed their daily asynchronous job limit can now enqueue Queueable and future method jobs up to an elastic limit set at twice the licensed daily limit. Jobs above the licensed threshold are processed at a throttled rate rather than failing outright.

The previous architectural response to async limit pressure was to consolidate jobs, redesign batch patterns, or route work through Platform Events as an alternative queue mechanism. Those approaches are still valid and often the right choice for other reasons. But the elastic limit changes the failure mode in a way you need to design for explicitly. Hard stops surface immediately and loudly in monitoring. Throttling is quieter. An org running above its licensed limit but below the elastic ceiling will continue processing, just more slowly, and that degradation can be easy to miss if your alerting is built around failures rather than throughput. If you plan to rely on elastic limits as a buffer, build monitoring around queue depth and processing latency, not just error rates.

Build observability into agent designs from the start

Agentforce Observability gets a significant upgrade this release. Refined Agent Analytics unifies Service Agent Analytics and Employee Agent Analytics into a single dashboard with more than 40 metrics across Quality, Health, Effectiveness, and Usage. Custom Scorers, now in Beta, let you define evaluation criteria specific to your business context, including Sentiment Score, Tone of Voice, Product Interest, Escalation Trigger, and Politeness, alongside standard quality metrics.

The architectural implication is that observability can no longer be treated as a post-deployment concern. If you are scoping an Agentforce implementation now, include the metrics framework in the design. What does a healthy session look like for this specific use case? What signals indicate the agent deflected when it should have escalated? What patterns suggest the agent’s instructions are too broad or too narrow? These questions are much harder to answer retrospectively from raw session logs than when you have defined scorers running against live sessions from day one.

The right approach is to define your quality criteria before you build. Write them as scorer definitions, even if you are not yet ready to activate them. They prompt an important conversation with stakeholders about what good looks like before deployment, rather than after the first customer escalation caused by an incorrect response. 

Note: legacy Agent Analytics reached end of support in May 2026. If your clients have agents deployed on the old analytics setup, migrate to the new experience to ensure long-term support.

Account for Hyperforce expansion in resilience design

Advanced Cross-Region Continuity (ACRC) is now available in the EU, with faster recovery time objectives across all available regions. Salesforce B2C Commerce is available on Hyperforce in the US.

For architects working with EU-based clients who have been deferring resilience architecture conversations pending ACRC availability, that blocker is removed. In the Well-Architected Framework, resilient solutions are designed with recovery objectives and continuity requirements in mind. Previously, EU clients had to accept a different answer on ACRC questions than their US counterparts. That asymmetry is gone. The resilience conversation, and specifically whether to design for ACRC or accept single-region recovery objectives, can now be had with complete options on the table for EU deployments.

3. Design: Agentic integration architecture

This is where Summer ’26 opens the most new design space. The Model Context Protocol (MCP) integration changes how agents connect to external systems, and the governance and orchestration capabilities introduced alongside it require architects to think holistically, not feature by feature.

Understand what MCP for Agentforce actually changes

Salesforce has built an MCP client into Agentforce, generally available now. MCP is an open standard that connects AI models to external tools and systems through self-describing interfaces. Instead of building a custom callout action for every external capability your agent needs, you register an MCP server and the agent discovers what that server can do.

In practice, you register a third-party MCP server in Agentforce Registry, or discover and add one from AgentExchange. Allowlist the tools you want available. Those tools are automatically registered as agent actions in the Agentforce asset library and can be added to any agent in Agentforce Builder exactly as you would add any other action. The MCP client layer handles integration plumbing, API connectivity, authentication, and data access. This registry also detects description changes at both session start and invocation. If any significant modification is detected, the action is blocked and the administrator is alerted.  This defense mechanism protects agents from the threat of attackers modifying previously trusted servers to execute malicious actions.

MuleSoft is the bridge for systems that do not have native MCP servers. MuleSoft MCP servers can now be brought into API Catalog. For enterprise architectures with existing MuleSoft investment, this is the integration pattern that makes MCP viable at scale without requiring every connected system to publish its own MCP server.

Architects will need to decide when to use MCP instead of a standard API callout action, and when MuleSoft should continue to own the integration.

• Use MCP when the external system already has a published MCP server and the tools you need are available in it. Registration is a one-time step and gives the agent native tool discovery instead of a fixed set of predefined actions. This approach is particularly valuable when the external system’s capabilities evolve frequently.
• Use a standard API callout action when you need precise control over how the request is constructed, when data sensitivity requires you to own the full request/response pipeline, or when the integration is already built and working well. There is no architectural reason to introduce MCP for a stable, well-understood point-to-point integration.
• Use MuleSoft when the external system does not have an MCP server and you need transformation, routing, error handling, or orchestration logic between Salesforce and the target system. MuleSoft can then surface through API Catalog as an MCP server in Agentforce, combining enterprise integration capability with MCP-based agent accessibility.

Apply Agentforce Gateway policies to every MCP integration

Agentforce Gateway policies are available alongside MCP for Agentforce and they are not optional architecture. Policies let you control which agents can access which MCP server tools, set usage limits, and enforce governance rules. They can be applied manually to specific connections or automatically through matching criteria based on connection source or name.

Think of these policies as the equivalent of what named credentials and permission sets are to API integration: the governance layer that separates “technically possible” from “architecturally permitted.” Every MCP integration you design should have a corresponding policy decision: which agents get access to which tools, under what conditions, and with what usage constraints. Treating this as a post-build concern creates the same kind of unmanageable sprawl that uncontrolled connected apps proliferation created.

Build with Hosted MCP Servers and new front-end capabilities

Hosted MCP Servers are available this release, using Connect API under the hood. This means you can expose Salesforce capabilities as MCP tools for consumption by non-Salesforce agents and AI systems. Salesforce becomes a tool provider in the broader agentic ecosystem, not just a consumer. For organizations building multivendor AI architectures, this significantly changes the integration topology. While prebuilt standard servers are available for immediate use, the architecture also supports custom MCP servers that expose your specific business logic through flows, Apex methods, or even named queries.

On the front-end side, two new capabilities are worth highlighting for teams building agent-embedded experiences. Multi-Framework extends Lightning development to support industry-standard JavaScript frameworks, starting with React (currently in Beta). This is relevant if your team has been managing a skills gap between Salesforce-native and web-native developers. The Headless Experience Layer addresses the “build once, deploy everywhere” challenge by allowing a single experience definition to surface across web, mobile, and embedded agent interfaces without rebuilding per channel. If clients are asking how agent interactions surface in existing UI contexts, this is the answer to have ready.

Plan your multi-agent architecture

Multi-Agent Orchestration for Agentforce, in Beta, lets you connect a primary agent to specialized agents within the same org. The primary agent handles intent routing; the specialized agents handle domain-specific complexity. The practical result is a reduction in instruction set size per agent, clearer testing boundaries, and reusable specialized agents that can be invoked from more than one primary agent.

Consider a service agent that handles returns, billing inquiries, and order status. Loading all three domains into a single agent means a large instruction set, a wide scope for the model to reason across, and escalation logic that has to account for all three failure modes at once. A better approach is to use three specialized agents, each scoped to a single domain with focused instructions, actions, and guardrails, connected to a lightweight primary agent that routes intent. This is more reliable, easier to test in isolation, and easier to extend when a fourth domain is added.

The design decision that matters at scoping time is how to draw the agent boundaries. The right boundary is usually a domain of business logic that has a coherent set of data, actions, and escalation paths. Returns is a good boundary because it has its own eligibility rules, fulfilment steps, and exception handling. Poor boundaries include those split arbitrarily by channel or by the team that owns the feature, because the agent then has to rely on context passed from the primary agent to function correctly. Agents that require extensive context passing to complete a task are a sign that the boundary is in the wrong place.

Multi-Agent Orchestration is Beta and design patterns will evolve before GA. But the architectural direction is clear enough to design toward now. A monolithic agent is harder to observe, harder to test, and harder to extend than a composed architecture. Custom Scorers in Agentforce Observability are also more powerful in a composed architecture because you can run different scorers against different specialized agents and get a signal at the domain level, not just at the session level.

Where to go from here

Start with these three actions this week:

1. Open the Release Updates page in Setup and filter for anything enforced in Summer ’26 or Winter ’27. Triage each one: is this a configuration change, a code change, or an architectural conversation?
2. Identify Apex classes in active development or recently deployed that lack an explicit sharing declaration, along with any SOQL queries still using WITH SECURITY_ENFORCED. Flag them before the next API version increment.
3. Read more on MCP for Agentforce before your next client conversation about Agentforce integration. Questions about when to use MCP versus a standard API action versus MuleSoft will come up. Having a considered answer, and understanding which approach fits your client’s current integration landscape, is the difference between advising and guessing.