Salesforce Winter 27 Release, Dates and What Changes
Release notes went live on August 19, sandbox preview opened August 28, and the first production wave lands the weekend of September 4. Salesforce’s Winter ’27 release notes published August 19, 2026, sandbox preview opened August 28, and production upgrades roll out across three weekends — September 4, October 2, and October 9, assigned by instance. The most useful thing an admin can do this week is find their own org’s exact date, since two changes in this release can quietly break something before anyone notices. WINTER ’27 RELEASE TIMELINE AUG 19 Release notes AUG 28 Sandbox preview SEP 4 Production wave 1 OCT 2 Production wave 2 OCT 9 Production wave 3 Enable Profile Filtering ENFORCES THIS CYCLE Users without View All Profiles can now see only their own profile name. Apex or Flow logic querying another user’s Profile now returns empty for them. OAuth Username-Password POSTPONED TO FEB 20, 2027 Scheduled for Winter ’27, then pushed back. Delayed, not cancelled. Integrations still using username and password logins are worth auditing now. Find your org’s exact weekend on Salesforce Trust, under Maintenance. Five dates, one permission change, one deadline that moved to February 2027. The permission change worth flagging to your team Enable Profile Filtering enforces this cycle. Users without the View All Profiles permission can now see only their own profile name. If any Apex or Flow logic queries the Profile of a user other than the one running it, that query now returns empty for anyone without the permission. Worth checking before the upgrade weekend, not after a report or an automation quietly stops working and nobody can figure out why. The API login change that got a reprieve Here’s a correction worth knowing before it spreads further. The retirement of the OAuth 2.0 username-password flow — the one where an integration logs in with a username, password, and security token — was originally scheduled to enforce in Winter ’27. Salesforce postponed the enforcement date to February 20, 2027. Treat that as delayed, not cancelled. Any integration still authenticating that way will stop getting a token on the later date, and finding every affected integration takes real time, so the extra months are worth spending now rather than in January. Check Login History filtered for OAuth password logins, and review Connected Apps OAuth Usage in Setup, to see what’s actually exposed in your org. What’s actually new to use this cycle 🧩Flow Builder — grouped sections, edit history, beta Test ModeCollapsible grouped sections with their own labels, an edit history timeline that shows every save and lets you restore older versions, and a new beta Flow Test Mode that splits Build and Test inside the builder with code coverage and mock outputs. 🤖Agentforce — beta Custom Scorers, Hosted MCP ServersLets a team define its own pass or fail evaluation logic for an agent session instead of relying only on Salesforce’s built-in quality metrics, plus expanded interoperability through Hosted MCP Servers. 🌐Experience Cloud — LWR sites embed real Lightning reportsCloses a long-standing gap: LWR sites can now embed an actual Lightning report, with charts, tables, and record editing, without falling back to the older Aura framework to get it. Find your exact upgrade weekend Production dates are assigned per instance, not per org type or edition. Check Salesforce Trust, search by instance name or domain, and open the Maintenance tab to see the exact weekend for that specific org. Writer note Dates above reflect Salesforce’s published Winter ’27 schedule and Trust status as of late August 2026. Production weekends are assigned per instance, so confirm the exact date on Salesforce Trust before publishing or promising a client a timeline. Two changes in this release can quietly break something before anyone notices. Finding your org’s exact date is the highest-leverage five minutes an admin can spend this week. Book a pre-upgrade Health Check through our contact form to catch breaking integrations before your org’s wave hits, and follow TrueSolv on LinkedIn for release coverage like this. Salesforce Winter ’27Salesforce ReleaseSalesforce AdminSalesforce SecurityTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Enable Profile Filtering 02OAuth password flow — postponed 03What’s new this cycle 04Find your upgrade weekend Key dates Aug 19Release notes published Aug 28Sandbox preview opens Sep 4Production wave 1 Oct 2Production wave 2 Oct 9Production wave 3 Feb 20OAuth password flow retires (2027) Not sure what breaks in your org? Book a pre-upgrade Health Check before your production wave hits. Book a Health Check → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Dashboards for Leaders Worth Checking Weekly
Most Salesforce dashboards look great and get opened once a quarter. Good Salesforce dashboards for leaders get checked weekly, not quarterly, and they answer three questions in under five minutes. Are deals actually moving or just sitting there. Is the team working the accounts that matter. Is the forecast something to trust or optimism with a dollar sign on it. MONDAY DASHBOARD ROUTINE Pipeline velocity THE TAKEAWAY Speed through the pipeline matters more than its size. Team activity LAST TOUCH, OPEN DEALS ! 14 days quiet, no logged activity THE TAKEAWAY Silence is the warning sign, not the lost reason. Forecast accuracy Forecast Actual THE TAKEAWAY Watch the gap’s pattern, not one quarter’s number. 10 MIN, EVERY MONDAY Three reports, one takeaway each, ten minutes every Monday before the week starts. Pipeline velocity report The takeaway How fast money moves through the pipeline matters more than how much sits in it. Pipeline velocity is calculated from the number of open opportunities, average deal value, win rate, and average sales cycle length. A pipeline that looks full but moves slowly is a warning sign a quarterly review won’t catch until the quarter is already lost. Team activity report The takeaway A stalled deal shows up in activity long before it shows up in a lost reason. This report tracks calls, emails, and meetings logged against each open opportunity, sorted by days since last activity. A deal with nothing logged in two weeks deserves a manager’s attention regardless of what stage it’s sitting in. Forecast accuracy report The takeaway The number worth watching isn’t this quarter’s forecast, it’s how often last quarter’s forecast was wrong. This report compares the committed and best case numbers reps submitted against what actually closed, tracked over time. It flags who is consistently over-optimistic and who is sandbagging, which matters more than any single quarter’s total, since both patterns repeat. One dashboard, one Monday routine All three reports drop onto one dashboard, filtered to the current quarter. Ten minutes every Monday, before the week gets going, catches a stalling deal or a shaky forecast while there’s still time to do something about it, instead of finding out at quarter close when the only option left is explaining it. A dashboard checked quarterly tells you what already happened. A dashboard checked weekly gives you time to change what happens next. Send us your current reports through the contact form and we’ll help set this dashboard up. Follow TrueSolv on LinkedIn for more notes like this one. Salesforce DashboardsSalesforce ReportsSales LeadershipCRM AnalyticsTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Pipeline velocity report 02Team activity report 03Forecast accuracy report 04One dashboard, one routine 3 questions in 5 minutes Moving or sitting?Are deals actually moving or just sitting there Right accounts?Is the team working the accounts that matter Trust the number?Is the forecast trustworthy or optimism with a dollar sign Still checking dashboards quarterly? Send your current reports and we’ll help set up the weekly routine. Set up the dashboard → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Health Check Signs Your Org Needs an Audit
The org keeps growing, automations keep piling up, and nobody has reviewed access permissions in years. You know an org needs a Salesforce Health Check when the same handful of symptoms start showing up together. Reports that give a different number depending on who pulls them. Permission sets nobody remembers granting. Flows nobody wants to touch because nobody is sure what they’d break. If two or three of those sound familiar, the org is already overdue. INSIDE THE ORG ! Unused field ! Orphaned Flow ! Permission creep ! Duplicate records Health Check HEALTH CHECK REPORT Security & access Data quality Performance & scale Org structure Licenses & contracts Integrations & API Six domains, one report, no guessing what’s actually wrong. Four warning signs inside the org — one six-domain Health Check report that names every one of them. What an unaudited org tends to look like Custom fields nobody remembers the purpose ofStill sitting on every page layout, slowing down load times, and appearing on reports where they were never meant to. Orphaned Flows referencing deleted objects or fieldsActive automations pointing at things that no longer exist — running silently, failing silently, or doing nothing at all. Permission sets that have grown broader with every hire and never been trimmedThe easiest fix at onboarding time becomes a security exposure the moment someone changes roles or leaves the company. Duplicate records quietly skewing every report that touches themTwo records for the same account mean two pipelines, two activity histories, and one number nobody fully trusts. Why this is a risk now, not a someday problem None of this happens on purpose. It happens because Salesforce is flexible enough to absorb years of quick fixes without ever forcing a cleanup, so the org keeps working just well enough that nobody schedules the review. A former employee with an active login is a live exposure the moment they leave, not a theoretical one. Reports that take too long to load or automations that quietly conflict cost real working hours every single week, not just at renewal time. The longer the mess sits, the more new work gets built on top of it, and the more expensive the eventual cleanup gets. What a Salesforce Health Check covers A TrueSolv Health Check reviews six domains in one pass: Security and access controls. Data quality and management. System performance and scalability. Org structure and customization. License and contract usage. Integrations and API health. The client walks away with a findings report running twenty to forty pages, each issue rated by severity with a plain language explanation and a specific fix. An executive summary condenses the top priorities for anyone who wasn’t in the weeds. An action item list with effort estimates plugs straight into a sprint, and a quick wins checklist flags what an admin can fix the same afternoon. The org keeps working just well enough that nobody schedules the review. That’s what makes the mess expensive — it compounds every week you don’t look at it. Run the free Salesforce Health Check self-assessment for an instant score, or book the full audit through the contact form. Follow TrueSolv on LinkedIn for more org cleanup notes. Salesforce Health CheckSalesforce SecurityCRM AuditSalesforce AdminTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What an unaudited org looks like 02Why this is a risk now 03What the Health Check covers 6 audit domains 🔐Security & access 🗄️Data quality ⚡Performance & scale 🏗️Org structure 📋Licenses & contracts 🔌Integrations & API Not sure where the org stands? Book the full six-domain audit or run the free self-assessment for an instant score. Book the Health Check → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
We Celebrated Seven Years the Way We Do Most Things
We are a distributed team across Tbilisi and Dubai, so there was never going to be one office with balloons taped to the ceiling. Instead, seven years got celebrated the way most of our workdays already happen — on a call, across time zones, and somehow still louder than expected. Here is what actually went down. TrueSolv — Year 7 Anniversary CallAugust 2026 · Full team · 1 video call 🎂7 years of Salesforce work 2countries on one call 3hours, no formal agenda 🇬🇪 Tbilisi, Georgia·🇦🇪 Dubai, UAE The format: games, not an agenda We made a deliberate decision not to structure the anniversary call around a retrospective deck or a metrics review. Seven years of those exist already. This one was structured around games, which turned out to be the right call. The format was loose: a full-team video call, a mix of people from both offices in the same frame, and three blocks of activity with no formal agenda between them. What we actually played The first block was company trivia — questions about the project history, the early years, the decisions that look obvious in retrospect and were genuinely uncertain at the time. The format was simple: a question, everyone answers, the person who gets it right gets to ask the follow-up question. Some questions were easy. Some were not. The one about which client project arrived with the strangest technical requirement — a Salesforce org that needed to track inventory for a museum, including items that had not been catalogued yet — produced a genuine debate about whether “null but billable” is a real data state. (The answer is yes, apparently, if the contract says so.) The second block was an online quiz platform — faster, more competitive, not limited to people who had been around long enough to know the company history. This levelled the playing field significantly and produced the discovery that our most competitive team member on a quiz platform is not the person anyone would have predicted. The third block was show-and-tell. Each person picked one thing from the past year — a project, a technical problem, a moment — and described it in two minutes. No slides. No preparation required. The two-minute constraint was the part that made it work: enough time to say something specific, not enough time to turn it into a presentation. Best moments from the anniversary callCompany trivia, unexpected answers, and the quiz that humbled some of us From company trivia 🏛️Which project had the strangest technical requirement?A museum inventory system that needed to track items that had not been catalogued yet. The resulting 20-minute discussion about whether “null but billable” is a valid CRM data state is now a recurring reference. 🤔What was the first Salesforce object we ever built a custom trigger for?Nobody got this right on the first guess. The people who joined in years 4 through 7 had to take it on faith that the answer was accurate. From the online quiz 🏆Most competitive team member on a quiz platformNot the person anyone would have predicted. They were very calm about winning. Suspiciously calm. 😐Highest-scoring moment in show-and-tell (informal)Someone sharing a debugging session where the bug turned out to be a missing comma in a JSON payload that took four hours to find. The room recognised it immediately. General observation 💡What a distributed team celebration actually isIt is not a party. It is a few hours where the work stops being the only thing people share. Seven years of that is a lot of shared context — and it turns out to be louder than expected when you put it all in one call. The part that is hard to describe to people who have not worked distributed A distributed team that has been working together for years accumulates shared context in a specific, gradual way. There are no hallway conversations. There are no off-the-cuff lunches. The shared context that builds in a co-located office — the running jokes, the inside references, the “you had to be there” stories — has to be built intentionally in a distributed one. What struck me about the anniversary call was how much of that context exists without anyone having planned it. Stories about the same project told from different angles by people who worked on it at different times. References to client situations that everyone understood without explanation. A team that has been doing good work together for long enough that the good work has become its own kind of shared language. That is not something you schedule into a company retrospective. It builds in the work, over time. Seven years is enough time to accumulate a lot of it. To everyone who has been part of this in any form — client, partner, or team member who moved on to something else — thank you. Seven years of this kind of work is not small. Follow us on LinkedIn and Instagram for more of what it is actually like working with a distributed Salesforce team. TrueSolvTeam CultureSalesforce Consulting7 Year Anniversary Share: LinkedIn Twitter / X Copy link In this article 01Games, not an agenda 02What we actually played 03Working distributed Anniversary call, at a glance 7 years of TrueSolv 2 countries, 1 call 3 game blocks, 0 slides About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
Hire a Salesforce Admin or Stay With a Partner?
At some point between 25 and 50 employees, almost every SaaS company asks the same question: do we hire a Salesforce admin, or do we keep working with a partner? It sounds like a resourcing question. It is actually a maturity question. And getting the answer wrong in either direction costs money, time, and six months of technical debt that lands on whoever comes next. Here is the framework for making that decision deliberately rather than reactively. Factor In-house admin Salesforce partner Hybrid model Primary work type Operational — reports, users, data cleanup, routine flows, responding to business requests daily Architectural — new objects, integrations, Agentforce, data model redesign, CRM migration Both simultaneously — admin handles daily operations; partner handles quarterly project work Team size signal 25–50+ employees generating 8–12+ consistent admin tickets per week filling 75%+ of a full-time role Under 25 employees, or project-based Salesforce needs that don’t fill a full-time role consistently 40–100 employees where daily operations and quarterly architectural projects co-exist without clean separation Org documentation Org is well-documented — new admin can understand decisions made before they arrived Org undocumented or partially documented — partner can produce documentation as a deliverable before the admin hire Documented enough for daily admin; partner handles architecture decisions that require deeper platform knowledge Business context value High — admin who knows the business deeply diagnoses problems faster and avoids well-intentioned changes that don’t match reality Lower — partner needs context per project and works better on scoped work where requirements can be specified upfront Admin provides business context for daily requests; partner applies platform depth to defined project scope Typical annual cost $80K–$120K salary + benefits + management overhead $28K–$44K for 4 substantial projects at 40 hours each at $175–$275/hr $55K–$80K admin salary + $15K–$25K annual retained partner — total often less than senior admin alone When this works best Stable org that needs consistent daily availability more than platform depth Orgs where Salesforce work is project-based and architectural depth matters more than business context Orgs where the types of work are genuinely different and the division of responsibility is explicitly defined The case for hiring in-house sooner An in-house Salesforce admin makes economic sense when the Salesforce work is primarily operational — the org is stable, well-documented, and requires ongoing maintenance rather than architectural change. The specific tasks that benefit from an in-house resource are report building, user management, data cleanup, routine flow modifications, and responding to user requests in real time. The value that an internal resource adds that a partner cannot replicate is business context at low latency. An in-house admin who has sat in two dozen pipeline reviews understands why a field exists, why a certain report is broken differently than it looks, and what the revenue team actually means when they say “the CRM is wrong.” The breakeven for an in-house hire typically occurs when the org is generating more than eight to twelve admin tickets per week with enough consistency that the work fills 75% or more of a full-time role. Below that threshold, the cost per ticket is lower with a partner. The case for staying with a partner longer A Salesforce partner makes economic sense when the Salesforce work is project-based and architectural: building new objects and relationships, configuring third-system integrations, deploying Agentforce or other AI capabilities, migrating from another CRM, or redesigning the revenue operations data model. These are not tasks that benefit from low-latency business context. They require Salesforce depth — knowledge of how the platform behaves at implementation boundaries, what breaks in governor limits, how the data model will perform at scale, and what the configuration choices made today will cost in flexibility six months later. A senior Salesforce consultant at a partner firm costs $175 to $275 per hour. Four substantial architectural projects per year at 40 hours each totals $28,000 to $44,000. A senior in-house admin costs $80,000 to $120,000 per year in salary plus benefits. For companies doing four projects per year with mostly operational maintenance in between, the partner model is often less expensive — even before accounting for the depth differential. The three mistakes most SaaS companies make Mistake 1: Hiring an admin to fix a problem that requires an architect The presenting symptom is “our Salesforce is broken.” The actual problem is that the data model does not reflect how the business works, the integrations are unreliable, or the objects were configured for a different business model than the current one. Hiring a mid-level admin to fix an architectural problem produces months of workarounds that make the underlying problem harder to fix later. Mistake 2: Paying an architect-level partner for admin tasks The reverse problem: a company stays with a sophisticated Salesforce partner after the org stabilises, paying project rates for report building, user management, and minor flow modifications that any mid-level admin could handle. This often happens because the decision to hire was never formally revisited. The partner was right for the implementation phase; staying with them indefinitely for operational maintenance is a default, not a decision. Mistake 3: Treating the decision as permanent The right answer at 30 employees is rarely the right answer at 80 employees. The maturity of the org, the complexity of the Salesforce environment, and the ratio of architectural to operational work all shift as the company grows. A decision made correctly at one stage needs to be revisited at the next one. Three diagnostic questions to answer before deciding Three diagnostic questions before making the decisionAnswer all three honestly — not aspirationally 1What is the primary type of Salesforce work needed in the next six months?New objects, integrations, Agentforce configuration, or data model changes = architectural work. Reports, users, data hygiene, flow tweaks = operational work. Be honest about which is primary, not which you aspire to be doing.→ Primarily architectural: partner. Primarily operational: in-house. Both significantly: hybrid. 2What is the current state of org documentation?An undocumented org transferred to a new in-house admin
Salesforce Data 360 MCP Server Is in Developer Preview
On May 26, Salesforce announced that the Data 360 MCP Server is now in Developer Preview. The idea is direct: every piece of data in your Salesforce Data Cloud is now reachable by any AI agent that speaks Model Context Protocol. Your CRM context, unified customer profiles, real-time data streams — accessible from Claude Code, Cursor, or any MCP-compatible agent tool without writing a custom API wrapper. Data 360 MCP Server — How Data Cloud Connects to AI Agents Salesforce Data Cloud • Unified customer profiles • Audience segments • Calculated insights • Data streams • Identity resolution exposes Data 360 MCP Server Developer Preview Trust Layer protected tool calls MCP-compatible AI agents Claude Code Cursor / Codex Agentforce Studio Custom MCP clients Any agent that speaks MCP No custom API wrapper required. Data arrives through the same trust layer as other Agentforce data access. What the Data 360 MCP Server actually exposes The server gives AI agents structured access to Data Cloud data — unified customer profiles, audience segments, data streams, calculated insights, and identity resolution outputs. These are the data objects that previously required SOQL-like queries against the Data Cloud query engine or custom API development to surface. Through the MCP interface, an agent can retrieve a unified customer profile by identity, query segment membership for a specific individual, pull calculated insight values for an account, or read real-time data stream events — using the same tool-call pattern it would use to interact with any other MCP server, without learning a proprietary API. The significance is in the combination. An agent building a renewal recommendation previously had access to Salesforce CRM data — the account record, the opportunity history, the activity log. What it did not have was the Data Cloud layer: the calculated health score from product usage, the segment membership that reflects behavioural patterns, the cross-channel identity resolution that unifies how the same customer appears across touchpoints. The Data 360 MCP Server adds that layer. Why this changes how agents reason The practical difference between an agent with CRM access and an agent with CRM plus Data Cloud access is the difference between structured records and contextualised customer intelligence. An agent reviewing a renewal opportunity can currently see: account name, ACV, contract end date, last activity log, open support tickets. With the Data 360 MCP Server, that same agent can also see: the customer’s health score calculated from product usage patterns, their segment membership indicating they are in a high-churn-risk cohort, and their identity resolution confirming that two separate records in the CRM are the same individual. Because the data arrives through the MCP interface with the same trust layer protections as other Agentforce data access, the agent’s data handling governance applies uniformly — no separate security configuration needed for the Data Cloud layer. What is available in Developer Preview vs. what is coming Capability Available in Developer Preview Expected at GA Unified customer profile retrieval ✓ Query by identity, return full profile with attributes — Audience segment membership ✓ Query segment membership for a specific individual or account — Calculated insights reads ✓ Return health scores, propensity scores per record — Identity resolution queries ✓ Cross-reference unified identity across touchpoints — Data stream reads ✓ Basic event stream data — subject to Data Cloud sync latency Real-time streaming subscriptions Write-back to Data Cloud ✗ Not yet available Agents will be able to update Data Cloud records based on reasoning output Complex data stream subscriptions ✗ Not yet available Subscribe to data stream events as part of agent trigger logic Production org access ✗ Developer Edition orgs with Data Cloud only Full production org access at GA Developer Preview gives access to the core unified profile retrieval, segment queries, and calculated insight reads. The key constraint is data freshness: Data Cloud data surfaces through the MCP Server with the same refresh latency as the underlying Data Cloud sync. For most use cases this is acceptable. For agents reasoning about real-time events, it is worth understanding the lag characteristics of your specific data streams before building workflows that depend on sub-second freshness. Developer Preview access path Data 360 MCP Server — Developer Preview Access Path4 steps 1Confirm your org has Data Cloud enabledDeveloper Edition orgs with Data Cloud access qualify for Developer Preview. If you do not have a Data Cloud-enabled org, spin up a Developer Edition at developer.salesforce.com — the fastest path to experimenting. 2Enable the Data 360 MCP Server in SetupOpen Setup → search for MCP Servers. The Data 360 MCP Server appears in the available server list for Developer Preview-enrolled orgs. Enable it and configure which agents have access to which data objects.Setup → MCP Servers → Data 360 MCP Server → Enable 3Connect an MCP-compatible clientClaude Code, Cursor, Agentforce Studio, or any MCP-compatible development environment can connect once the server is enabled. The server returns a tool manifest — no custom authentication code required beyond the standard MCP handshake. 4Test with a unified profile retrievalPull a known profile by ID, confirm the MCP Server returns the same data as the Data Cloud UI, and verify that segment membership and calculated insights are included in the response. This confirms the data path is working before building agent logic on top of it. Developer Preview is the right time to experiment, not the right time to build production workflows. Map your architecture, test your data access patterns, and identify what works before GA removes the preview caveats. The orgs that move through this now will deploy faster when GA lands. Data 360MCPData CloudSalesforce DevAgentforce Share: LinkedIn Twitter / X Copy link In this article 01What it exposes 02Why it changes agent reasoning 03Preview vs. GA capabilities 04Access path — 4 steps Developer Preview status Unified profilesQuery by identity — live Segment membershipPer individual — live Calculated insightsHealth scores — live Write-backExpected at GA Production orgsDev Edition only now Quick access path 1️⃣Enable Data Cloud in org 2️⃣Setup → MCP Servers → Enable 3️⃣Connect MCP
Standard Omni-Channel Retirement Salesforce
Today is June 1. Standard Omni-Channel in Salesforce is officially retired. If your org has not migrated to Enhanced Omni-Channel Routing and your production instance hits the Summer ’26 upgrade before you are ready, your agents will not be able to log in to Omni-Channel and work items will stop routing entirely. This is not a beta warning. This is now. ⚠What breaks if your org upgrades without completing the migration Agent loginAgents see an error when attempting to log in to Omni-Channel. They cannot set themselves as Available and cannot receive routed work items until the migration is completed. Work routingIncoming cases, chats, and calls stop routing entirely to any queue using Standard Omni-Channel logic. Work items queue without assignment until an admin completes the migration. Specific channelsLive Agent (Chat), standard SMS, and Facebook Messenger queues are the highest-risk channels. Each requires individual migration before Enhanced routing is enabled — enabling Enhanced routing first on these breaks them even if the main switch was working. ResolutionThe fix requires completing migration steps in production under time pressure, potentially during a service outage. The correct time to do this is now, in a sandbox, not after the upgrade breaks routing. Step 1: Check your current Omni-Channel status Open Setup and search for Omni-Channel Settings. If your org shows Standard Omni-Channel Routing as active, you have not completed the migration. If Enhanced Omni-Channel Routing is enabled, check whether all service channels have been migrated — it is possible to have Enhanced routing active but individual channels still on the legacy configuration. The specific channels that require individual migration steps before you enable Enhanced routing are: Live Agent (Chat), standard SMS channels, and Facebook Messenger. Enabling Enhanced Omni-Channel routing before migrating these channels will break routing for those specific queues. Step 2: Check your production upgrade date Not all production orgs upgrade on the same weekend. The Summer ’26 production upgrade runs across three windows: some instances upgraded May 15, the main production wave is June 5, and the final wave is June 12. Your upgrade date determines how much time you have. Find your instance: Setup → Company Information → Instance field. Then check your specific upgrade date at status.salesforce.com. If your instance upgrades June 5, you have four days from today. If it upgrades June 12, you have eleven. How to find your production upgrade date 1Open Salesforce Setup → search for Company InformationSetup → Company Information → Instance 2Note the instance name (e.g. NA87, EU15, AP5) 3Go to trust.salesforce.com → select your instance → find the Summer ’26 maintenance windowtrust.salesforce.com/status/maintenance Summer ’26 Production Upgrade Waves May 15First wave — selected instances already upgraded. If your org is on this wave, you are already on Summer ’26.Already live June 5Main production wave — majority of orgs. This is Thursday. The window to prepare is today.Tomorrow June 12Final wave — remaining instances. You have until June 11 EOD if your instance is in this wave.7 days left Step 3: Migrate in the correct sequence Enhanced Omni-Channel Migration — Correct SequenceDo in this order 1Migrate individual service channels firstLive Agent (Chat), standard SMS channels, and Facebook Messenger must be individually migrated before you enable Enhanced routing. Enabling Enhanced routing before these migrations breaks them. This is the step most orgs get wrong.Do this before anything else 2Enable Enhanced Omni-Channel RoutingAfter channel migrations in Step 1 are complete, open Omni-Channel Settings in Setup and enable Enhanced Omni-Channel Routing. This is the main routing switch — only flip it after Step 1 is confirmed complete.Only after Step 1 3Verify agent capacity model settingsEnhanced routing uses capacity-based logic that may differ from your Standard configuration. Review queue settings and capacity model assignments in your Summer ’26 sandbox. Confirm routing rules behave as expected with simulated work items.In sandbox first 4Test full agent login and work item routing end-to-endHave a test user log into Omni-Channel in the Summer ’26 sandbox, set status to Available, and accept a routed work item through the full flow. Confirm the item closes and activity is logged correctly before applying these settings to production.Verify before production Step 4: Check for exemptions Two specific scenarios may affect your migration timeline. If your org has a legacy Chat implementation that qualified for a legacy-chat exemption, you may have additional transition time — check your org’s Salesforce communication history for any exemption notification. If your org has not yet agreed to Hyperforce AWS terms, certain Enhanced Omni-Channel features may be unavailable until those terms are accepted. If your production org upgrades before this migration is complete: agents will see an error when attempting to log into Omni-Channel, and work items will not route. The fix requires completing the migration steps under time pressure in a production environment. Completing them now, in a sandbox, is the better version of this conversation. Salesforce Admin Omni-Channel Summer ’26 Service Cloud Share: LinkedIn Twitter / X Copy link In this article 01Check your Omni-Channel status 02Find your upgrade date 03Migrate in the correct sequence 04Check for exemptions ⚠ What breaks if you skip this Agents can’t log in to Omni-Channel All work items stop routing Chat, SMS, Messenger break individually Fix in production = outage pressure Migration sequence 1Migrate channels first 2Enable Enhanced routing 3Verify capacity model 4Test end-to-end in sandbox About the Author ST Sergey Trusov CEO & Salesforce Architect at TrueSolv
How to Use Agentforce to Automate SaaS Renewal Protection
Most SaaS companies do not lose renewals because the product failed. They lose them because nobody noticed the signals in time — usage dropping, a key contact going quiet, a support ticket that never fully resolved. By the time the CS team follows up, the customer has already decided. Agentforce inside Salesforce changes this from a reactive problem to a proactive workflow. Proactive CS motions outperform reactive ones at every stage The signal arrives weeks before the decision. The question is whether your system is watching for it. 67%Higher renewal rate when CS reaches out proactively vs. waiting for the customer to initiate 14 daysAverage time between detectable usage decline and churn — the intervention window most teams miss 80+Accounts per CS rep at a 30-person SaaS company — volume that makes manual monitoring impossible SaaS industry renewal benchmarks. Specific percentages vary by product category, deal size, and CS team structure. Part 1: Why SaaS renewal churn is a data problem, not a people problem The CS team at a 30-person SaaS company is usually one or two people managing 80 or more accounts. They are good at their jobs. They are not able to proactively review every account monthly while simultaneously handling onboarding calls, support escalations, and renewal negotiations. The signals that predict churn are not hidden. Usage declining by 40 percent over two weeks is visible in your product analytics. A key contact going silent for 45 days is visible in your activity log. A support ticket that stayed open for 12 days before resolution is visible in your case management. The problem is that nobody is watching all of these signals simultaneously across 80 accounts. Agentforce agents can. They run continuously against your Salesforce data, evaluate conditions against defined thresholds, and take action when those thresholds are crossed — without requiring a CS rep to remember to check. The data advantage compounds over time. As agents surface patterns — which usage drops correlate with churn, which onboarding milestones predict expansion — your renewal playbook becomes more precise with each cycle. Part 2: What an Agentforce renewal agent actually does An Agentforce renewal agent is an automated system that monitors account health signals, evaluates them against configured thresholds, and takes a defined action when a threshold is crossed — without human initiation. Agentforce Renewal Workflow — How a churn signal becomes a CS action Data Signals • Usage −40% / 14d • No contact 45+ days • Open support tickets • Contract 60d away Monitors Agentforce Renewal Agent Evaluates all signals simultaneously • 24/7 Triggers Autonomous Actions Priority CS task assigned to account owner Account summary usage + contacts + tickets Churn risk flag renewal dashboard alert Draft renewal email queued for CS review No human initiation required. Agent runs continuously against Salesforce data. The distinction from a standard Salesforce Flow is the reasoning layer. A Flow fires when a condition is met. An Agentforce renewal agent evaluates the condition in context — weighing multiple signals simultaneously, generating a natural language summary of what it found, and drafting context-aware communication that a Flow cannot produce. Part 3: Three renewal agent workflows worth building first Workflow 1 60-day renewal outreach agent Trigger:Contract end date is 60 days away. What it does:Reviews account health signals — product usage trend over the last 30 days, open support issues, last contact date, any logged expansion signals. Drafts a personalised renewal email with specific context from the account record. Queues the draft for CS review with a task to approve or revise within 48 hours. Why it works:A calendar reminder tells the rep to follow up. This agent tells the rep what the account looks like right now, drafts the message, and makes the rep’s job to review and send — not to research and write. The rep’s 20 minutes of prep becomes 5 minutes of review. Expected outcome: Higher quality renewal outreach, earlier in the cycle, with no additional CS capacity required. Workflow 2 Churn risk alert agent Trigger:Product usage drops more than 40 percent over a 14-day window compared to the prior 14 days. What it does:Flags the account with a Churn Risk tag in Salesforce. Creates a priority task for the account owner. Generates an account summary: last contact date, open support issues, usage trend, contract value and end date, any recent expansion or contraction signals. Why 14 days:The most actionable churn signals happen 30 to 60 days before renewal. A 14-day usage decline detected at 60 days out gives the CS team time to intervene before the customer has made a decision. Detected at 5 days out, the same signal is too late. Expected outcome: CS team prioritises the highest-risk accounts with full context before the intervention window closes. Workflow 3 Post-onboarding health agent Trigger:New subscription start date is 30 days ago. What it does:Checks whether the account has hit three key activation milestones. If all three are met, logs the health check and takes no further action. If one or more are not met, creates a targeted outreach task with a guided onboarding checklist attached and flags the account for a CS review. Why it matters:Customers who do not activate in the first 30 days are significantly more likely to churn at their first renewal. A health check at 30 days identifies at-risk customers at the moment where intervention — a 20-minute call, a targeted email with specific steps — is most likely to work. Expected outcome: Improved 30-day activation rates, lower first-renewal churn, CS effort focused on accounts that need it. Agent workflow Trigger What the agent does Expected outcome 📅 60-day renewal outreach Contract end date is 60 days away Reviews account health, drafts personalised renewal email, queues for CS review with 48-hour approval task Higher quality, earlier renewal outreach. Rep prep: 20 min → 5 min review. ⚠️ Churn risk alert Product usage drops 40%+ over 14-day window Flags account, creates priority task, generates account summary with full context CS prioritises at-risk accounts with
Summer ’26 Flow Updates: Six Things That Will Actually Change How You Build Automations
Every Salesforce release, the Flow section of the release notes is the one worth reading first. Summer ’26 did not disappoint — new date operators, batch size control for scheduled flows, collapsible fault paths, natural language updates for Screen Flows via Agentforce, and a genuinely better radio button experience. Here is the full breakdown of what landed, what it does, and when you would actually use it. Feature What it does Who benefits most 📅 Date Field Operators New operators: Is Today, Is Tomorrow, Is On, Anniversary. Applies to Date fields only — not DateTime. Admins building renewal reminders, SLA tracking, birthday campaigns, or any time-sensitive record logic. Eliminates the need for formula field workarounds. ⚙️ Scheduled Flow Batch Size Custom batch size control instead of the fixed default of 200. Smaller batches = lower governor limit risk. Larger batches = faster processing. Any org running Scheduled Flows against unpredictable record volumes. High-value for flows with DML operations or external callouts. 🗂️ Collapsible Fault Paths Fault paths in Flow Builder can now be collapsed. Canvas continues the visual cleanup started in Spring ’26 with collapsible Decisions and Loops. Admins managing complex flows with shared error-handling subflows. Large production flows become significantly more readable. 🤖 Natural Language Screen Flow Updates Agentforce natural language editing now supports Screen Flows. Describe a change in plain language, Agentforce makes the adjustment. Early access — review required. Admins who want to trial Agentforce-assisted flow building. Works well for additive changes with clear descriptions. Complex logic still needs manual work. 🔘 Radio Button Group New compact visual component replacing standard radio buttons in Screen Flows. Horizontal and vertical layout options, less vertical space per option. Any admin who has built Screen Flow intake forms and found standard radio buttons too space-heavy. Direct UI improvement for end users. 📧 Email Template Deployment Fix Send Email Actions using Email Templates now deploy correctly between environments. Fix is in “Show advanced options” in the action properties. Orgs with proper sandbox-to-production workflows who have been maintaining environment-specific flow versions as a workaround. One-time fix. 1. New date field operators Flow now supports four new date operators: Is Today, Is Tomorrow, Is On, and anniversary-based matching for date fields. For any flow that does time-sensitive record logic, this is a meaningful improvement over the workarounds that previously required formula fields or date math. The practical applications are immediate. A renewal reminder flow that should trigger 30 days before the contract end date can now use Is On with a relative date formula rather than a calculated checkbox field. A birthday-triggered campaign can fire using the anniversary operator without building a custom evaluation layer. Any flow checking whether a date falls within a specific window benefits directly. One important constraint: these operators apply to Date data types only, not DateTime. If your date field includes a time component, the new operators will not be available. This is worth checking against your object schema before building. Summer ’26 — New Flow Date Operators Quick Reference Is Today Matches records where the date field equals the current date. Ideal for daily-run flows that flag due-today tasks, contracts expiring today, or time-sensitive SLA conditions. Is Tomorrow Matches records where the date field equals tomorrow’s date. Use for advance notification flows — renewal reminders, follow-up triggers, appointment confirmations the day before. Is On Matches records where the date field equals a specified date or relative date formula. Most flexible of the new operators — covers “is on the first of next month” and similar calculated dates. Anniversary Matches records where the month and day of the date field match the current month and day, regardless of year. Use for birthday campaigns, contract anniversary workflows, and renewal sequences tied to the same calendar date each year. ⚠ Important: these operators apply to Date fields only — not DateTime. Check your field type before building. 2. Batch size control for Scheduled Flows Scheduled Flows now support a custom batch size setting. The default has always been 200 records per batch, which is a sensible baseline for most use cases but creates problems when qualifying record counts are unpredictable and the flow logic includes DML operations, callouts, or other governor limit-sensitive steps. Smaller batch sizes reduce the risk of hitting limits when record volume spikes. A flow that runs cleanly on 200 records can fail when it processes 1,400 and the batch triggers 200 SOQL queries rather than 200. Reducing the batch to 50 adds processing time but removes the failure risk. The tradeoff runs in both directions. Larger batches complete the full scheduled run faster when record volume is stable and governor limits are not a concern. The new control lets admins tune this explicitly rather than accepting a single default for every scenario. 3. Collapsible Fault Paths Fault paths can now be collapsed in Flow Builder, following the Spring ’26 changes that added collapsible Decisions and Loops. This is a quality-of-life improvement rather than a capability change — fault paths do not behave differently when collapsed — but for anyone managing complex flows with shared error-handling subflows, the canvas clarity improvement is real. Large production flows become difficult to read when fault paths branch from every element that can fail and the canvas becomes a sprawl of error-handling logic. Collapsing fault paths lets admins focus on the main execution path during review and debugging, and expand fault handling when needed. 4. Update Screen Flows with natural language via Agentforce Agentforce-powered natural language editing, which launched for Record-Triggered and Scheduled Flows in Spring ’26, now extends to Screen Flows in Summer ’26. Admins can describe the change they want in plain language — ‘add a required email field before the address step’ — and Agentforce makes the adjustment in Flow Builder. This feature is in early access and the honest framing is the right one: it works well for additive changes that are clearly described. Reorganising a complex screen, adjusting conditional visibility rules, or changes that require
Salesforce Summer 26 Developer Features
Every Salesforce Summer ’26 release has one developer feature that teams have been waiting for since approximately forever. LWC Component Preview is finally generally available. State Management for LWC reaches full GA. And the new Release Manager beta introduces a three-channel preview system that changes how teams stay ahead of what is coming. Here is the full rundown. LWC Component Preview finally GA This is the one. Anyone who has spent 90 seconds watching a Salesforce page reload to verify a two-line CSS change understands what this feature means for development speed. LWC Component Preview lets you see a single Lightning Web Component render in the browser or in VS Code without triggering a full page refresh. The feature has been in preview for several releases. Reaching GA in Summer ’26 means it is now stable, supported, and deployable in production orgs. The practical impact on iterative component development — particularly for orgs building complex page architectures with multiple custom components — is immediate and significant. State Management GA in Summer ’26 State Management for LWC is now fully generally available. The feature adds centralised state management across component trees — solving a problem that every developer building complex page architectures with multiple LWC components has run into: coordinating shared state without lifting it through the entire component tree via props. Salesforce Release Manager Beta — Three Channels 🏭 Standard Stable production The familiar quarterly release. Fully tested, fully supported, available in all sandboxes and production orgs. Best for Production orgs. Teams that need predictability above all else. The default for every Salesforce org. ⚡ Accelerated Production-ready early Features that are complete and tested but not yet in a major quarterly release. Earlier access, same quality bar as Standard. Best for Teams that want new capabilities before the next quarterly drop. Sandbox testing of features that are not yet in Standard. 🔬 Dev Active development Features in active development. Not production-ready. For evaluation, feedback, and planning — not for customer-facing work. Best for Developers who want to evaluate upcoming platform direction. Architects planning ahead. Never for production use. The practical benefit is cleaner data flow, less imperative code for managing shared state, and more predictable component behaviour when multiple components on a page need to respond to the same underlying data. For orgs building Opportunity detail pages with line items, totals, and discount components that all need to update from the same source, this removes a significant amount of coordination boilerplate. Salesforce Release Manager beta The Release Manager is the most strategically significant developer feature in Summer ’26. It gives developers access to three distinct release channels: Before: prop-drilling across components Without State Management // ParentComponent.js // Must pass totalMrr down to // every child that needs it export default class ParentCmp { @track totalMrr = 0; @track discount = 0; @track finalPrice = 0; } // Must wire props manually // to LineItems, Totals, Discounts // components separately After: centralised state store With State Management // oppStore.js — shared state import { createStore } from ‘@salesforce/state’; export const oppStore = createStore({ totalMrr: 0, discount: 0, finalPrice: 0 }); // Any component subscribes directly // No prop drilling needed Both LineItems, Totals, and Discounts components subscribe to oppStore directly — no parent coordination needed Standard: the stable production release. Familiar, predictable, the channel your production org is already on. Accelerated: production-ready features that are complete but not yet in a major release. These are features Salesforce has shipped and tested but held back from the standard release cycle. For teams that want to adopt new capabilities ahead of the next quarterly release, this is the channel. Dev: new features in active development. Not production-ready, not suitable for anything close to customer-facing work, but the right channel for teams that want to evaluate and influence upcoming platform direction. The Release Manager represents a meaningful shift toward continuous delivery for Salesforce. Historically, the three-times-a-year release cycle has meant long waits between features shipping at Salesforce and becoming available to developers. The Accelerated channel closes that gap considerably. Custom Flow Screen Component Styling Hooks Developers building custom Screen Flow components in LWC can now expose CSS styling hooks — color, border radius, font weight, and other SLDS attributes — so admins can customise the visual appearance of shared components without touching the component code. The practical scenario: an org has multiple business units sharing a common intake form component. The component logic is identical but each business unit needs different branding. Previously, the developer either maintained multiple versions of the component or the admin had no control over the visual output. Styling hooks solve this cleanly — one component, admin-configurable appearance per context. React support via Multi Framework (Beta) Salesforce Multi Framework enters beta in Summer ’26, allowing developers to build with ReactJS hosted natively on Salesforce, with data accessed via GraphQL and full integration with Agentforce Vibes. This is the most significant frontend architecture announcement in the release, and it deserves an honest take. The LWC-only frontend story is over. Salesforce is acknowledging that the developer ecosystem it wants to attract builds in React, and that requiring teams to learn a Salesforce-specific component model is a friction point that affects adoption of the platform for new development. The complication is a third UI model alongside LWC and the Agentforce Experience Layer. Orgs making frontend architecture decisions now face a genuinely more complex set of options. The article’s recommendation: Multi Framework is Beta and the right time to evaluate it is in preview orgs, not production. 5 Things Developers Should Test in Their Summer ’26 Preview Sandbox Before May 9 1 LWC Component Preview with your most complex component Open a custom LWC component in VS Code, make a CSS change, and preview it without a full page reload. Test with a component that has nested child components to confirm the preview reflects the full hierarchy correctly. GA — test for your stack 2 State Management on a page with multiple components