Winter ’27 Release Architect Highlights: Security, Agentic Architecture, and Governance

The Winter ’27 Release retires legacy capabilities and introduces new platform features that can strengthen your security posture and open new ways to solve business needs. As your org’s architect, you need to make coordinated decisions about security, capacity, agentic architecture, and governance that apply to your environments.

Use this guide to focus your Winter ’27 review on four areas: mandatory security enforcements, capacity and automation updates, agentic architecture, and governance and observability. Start by mitigating operational risk, then evaluate where new platform capabilities may help your current configurations scale and influence your architecture roadmap. 

Mitigate operational risk by resolving upcoming security enforcements

Several Winter ’27 changes raise the security floor. Legacy authentication methods retire to close weak entry points, while refresh tokens now expire after inactivity so forgotten credentials can’t linger. External client apps expose less by default and replace connected apps, which require action to restrict user access. 

These changes can reduce security risk across your org, but integrations that still rely on a retired method may stop working if you don’t take action.

• Plan for refresh token inactivity expiration: Starting November 4, 2026, production refresh token idle time-to-live (TTL) expires after 30 days of inactivity, which may break low-frequency integrations that assume a token will remain valid indefinitely. Identify integrations with infrequent execution patterns, confirm how they renew credentials, and design for token rotation or reauthentication so credential lifecycle does not become an unexpected availability risk.
• Legacy authentication patterns are being retired: Inventory the authentication pattern used by each integration and move it to the most secure option its integration system can support. Prioritize migrations by enforcement date: the OAuth 2.0 device flow is restricted beginning November 30, 2026, while the username-password, user-agent, and hybrid user-agent flows are retired on February 20, 2027. Because authentication requirements will continue to tighten, treat the replacement as a resilient architecture decision, not a stopgap; avoid migrating to another pattern that is already moving on a path toward restriction.
• Salesforce Connect cross-org adapter & Salesforce to Salesforce retirement: Both changes take effect in Spring ’27: Salesforce to Salesforce will fully retired and will no longer function, while legacy cross-org adapter authentication must move to named credentials. Treat the new authentication choices as an architecture decision and review how credentials are stored, rotated, and protected. Select the strongest pattern both orgs can support so the design has greater longevity as Salesforce continues to restrict less-secure authentication mechanisms.  
• Connected apps: Support ends by Summer ‘27, so start migrating to external client apps soon. External Client Apps use a default-closed security posture and separate application settings from administrative policies, creating clearer ownership and more deliberate governance. Use the migration to define the trust boundary for each inbound integration: who owns the application, which identity model it uses, what minimum scopes it requires, who can approve access, and how credentials and policies will be managed over time. Standardize those decisions where possible rather than carrying each existing Connected App forward as a one-off design.

Your goal is to understand your full exposure, prioritize migrations by risk and deadline, and ensure every retired authentication method has a supported replacement before enforcement. In the Well-Architected Framework, trusted solutions treat security management as a foundational control. Once you have a migration plan for the mandatory changes, revisit the limits and automation constraints that may no longer require the same design decisions.

Revisit capacity and automation decisions as platform limits shift 

You have designed solutions around platform constraints that now give you more room to scale and support higher-capacity workloads. Higher Apex heap limits create more processing headroom, Elastic Async Apex Jobs (Beta) expands capacity for seasonal or unplanned demand spikes, and Flow and sharing improvements can reduce custom automation built to work around previous platform behavior. 

These Winter ‘27 shifts give you reason to revisit capacity assumptions and architectural decisions that were shaped by previous constraints.

• Apex heap limits: Synchronous heap increases from 6 MB to 10 MB and asynchronous heap from 12 MB to 25 MB. Revisit code that chunks or streams data primarily to stay under the old ceiling, and simplify it where the added headroom makes those workarounds unnecessary.
• Elastic Async Apex Jobs (Beta): Now covers batch jobs in addition to future methods and Queueable jobs. Additional capacity is capped at either your licensed asynchronous Apex job limit or 2 million jobs, whichever is lower. Evaluate whether it can absorb your seasonal or spike async demand, and recheck the ceiling if your contract or standard limits change. 
• Override async Apex jobs in non-production: Use this feature to override the standard async Apex limit and test how workloads are processed within the elastic limit. Review your SLAs and validate the capacity model that works for your org before relying on elastic capacity in production.
• Flow record-lock retry and loop-free filtering: Review automation implemented in Apex specifically to work around Flow CPU, collection-processing, or record-locking constraints. Some of those decisions may still be correct, but this release gives you reason to revisit them rather than carrying the original constraint forward indefinitely.
• Keep Manual Shares When Transferring Records: Sharing Settings now allow the org to retain manual shares when record ownership changes. This is your opportunity to revisit Apex, Flow, batch, or scheduled processes that recreate shares after transfers, and replace that customization where the native behavior now matches the intended access model. Before enabling it, confirm which business processes rely on ownership changes to remove access, document any exceptions, and make sure retained manual shares align with your broader sharing and least-privilege strategy.

Wherever you rely on these limits or platform behaviors today, validate the assumption before you build on the new headroom. Preserving platform capacity can help ensure your agents have the headroom they need for their workloads. Review the next set of features with that in mind as you design for the Agentic Enterprise.

Design your Agentforce architecture as you scale agents

You have the building blocks for agentic systems that matter most at design time: how agents compose, what they can reach, and what they reason over. Most of these capabilities arrive in Winter ’27, with Multi-Agent Orchestration already generally available as of August 2026. Decide how these features fit into your architecture early, because they can be harder to retrofit once agents are in production. 

• Multi-Agent Orchestration (GA): Compose specialist agents as a supported pattern instead of relying on custom glue code, with streaming responses and handoff or escalation across channels, including Embedded Chat v2, WhatsApp, and mobile. Treat agent topology as a design-time decision, similar to how you would define service boundaries.
• API Catalog: Register and activate the Model Context Protocol (MCP) servers and APIs that your agents are allowed to call, including those for MuleSoft, Heroku, and Apex. Treat the catalog as a control point for agent tool access, and govern what goes in it deliberately rather than letting it accumulate over time.
• Resolve parent-child relationships in Data 360: Ground agents on full related-record hierarchies, spanning zero-copy data model objects (DMOs) from BigQuery, Databricks, and Snowflake. Because grounding quality is a data-architecture decision, not a prompt-tuning one, plan the hierarchy your agents need before you wire them up.
• Salesforce Lightning Design System (SLDS) AI Skills and ApexGuru: Standardize how AI-generated code enters your codebase, using portable AI Skills and static analysis that now run inside agentic development environments. As more code is machine-written, use these capabilities to make quality and consistency more visible and repeatable.

Use these new capabilities to design a resilient agentic architecture. Every agent deployed to production widens the surface you need to monitor and secure. 

Weigh new governance features against potential fallbacks

Winter ‘27 introduces dedicated control points for continuous security posture, oversight of agent connections, and org-wide performance. Availability varies by edition, license, and support plan. Start with the control you need, then decide whether the expanded features justify the investment or whether your existing tooling and operational processes provide sufficient coverage.

• Security Health Review: Replaces the point-in-time Health Check PDF with continuous, in-Setup findings, remediation, and an audit trail. It’s limited to Signature Success Plan customers, and the Health Assessments Agent requires the Salesforce Foundations add-on. If you do not have access, continue using Health Check in Setup on a scheduled manual cadence.
• Monitor Org Health with Scale Center: Surfaces org-health alerts and Agentforce-assisted root-cause analysis in Slack, with deep-linked Apex investigations and usage insights to where teams already work. Availability depends on edition and support plan, and the feature isn’t supported in Government Cloud Plus. If Scale Center does not fit your support model, continue using debug logs, ApexGuru, Setup-based usage insights, and your existing application performance monitoring or observability tools to investigate the same signals.

Both capabilities became available in mid-September 2026, expanding Security Center with new ways to govern external connections and unify security signals across your Salesforce environment.

• Security Center MCP Server Monitoring (Beta): Centralize visibility into configured MCP servers across connected Salesforce tenants, including risk scores, suspicious server URLs, configuration changes, and who added or modified each server. Use the risk score to prioritize review of servers and individual tools for potential tool poisoning, but treat it as one input to your governance process rather than an approval decision. Architects should define how MCP servers are evaluated before use, who can approve them, and how changes are monitored over time as agents gain access to more external tools and data.
• Security Mesh: Unifies security data from Salesforce and external sources into a common format in Security Center so teams can analyze security signals in one place. For architects, the decision is less about enabling another dashboard and more about whether Security Mesh should become part of your security data architecture and operating model. Consider which sources should feed it, how findings will be governed and acted on, and whether the added visibility justifies the required Security Center, Data 360, and supporting licenses.

Dedicated capabilities can provide stronger visibility into security posture, agent connections, and platform scale than the alternatives. For each one, confirm what your org can enable, then weigh whether the added functionality justifies the investment or whether your existing tooling is still sufficient for the use case.

From there, carry the decisions that matter into your architecture roadmap alongside the mandatory changes and new capabilities you’ve identified across the release.

Extend your roadmap to incorporate key features

For every feature or change in the Winter ’27 Release notes that requires you to make an architectural decision, whether a mandatory enforcement or a new capability on your roadmap, create an architectural decision record. Capture the question you are answering, the assumptions behind it, the option you chose, and the business outcome it is meant to support. These records, more than any one feature, are the architectural throughline that turns a release full of options into a plan your implementation teams can execute.

Focus your Winter ’27 review on four areas, starting with the enforcements that carry deadlines:

1. Security: Audit your org to identify where the retiring mechanisms are still in use, then create a single inventory of the affected integrations and the authentication pattern each one supports.
2. Capacity and automation: Revisit the heap, async, and Flow workarounds you built around the previous limits, and simplify the ones the new headroom makes unnecessary.
3. Agentforce architecture: Before you scale agents, decide how they compose through Multi-Agent Orchestration, what they can reach through the API Catalog, and what data grounds them in Data 360.
4. Governance and observability: For each control point, weigh whether your existing tooling is sufficient or the new capability adds enough value to justify it.