Most Salesforce Orgs Have Never Actually Been Looked At. Here Is What a Health Check Finds.
Most Salesforce orgs have never actually been looked at. Not the dashboards, not the reports — the org itself. The permission sets nobody remembers assigning. The automation that fires twice for reasons no one has investigated. The fields that were supposed to be temporary three years ago. A Salesforce Health Check is the moment someone finally looks. And through August 10, the first four hours of it are free as part of TrueSolv’s 7th anniversary campaign. What accumulates in a Salesforce org when nobody is looking Salesforce orgs are living systems. Every consultant who has ever configured something leaves a mark. Every internal admin who solved a problem fast leaves a mark. Every integration that was set up and then partially migrated to something else leaves a mark. None of these marks are visible in a dashboard. You can have perfectly formatted reports and a deeply unreliable Salesforce org at the same time. The dashboards show what was built to surface. The Health Check shows what was not built to surface. Permission sets and profiles: Created for a project that ended two years ago and never deactivated. A user with System Admin access who left the company eight months ago. A permission set that grants Modify All Data to a user who is supposed to be read-only. These are not hypothetical — they are the most common findings in any Health Check. Automation conflicts: A Flow that was built when Process Builder was the answer, a second Flow built when Flow Builder replaced it, and an Apex trigger that was written before either existed. All three still fire on record updates, occasionally at the same time. The resulting behaviour is technically correct most of the time and subtly wrong the rest. Fields added for a one-time report: There are 47 custom fields on the Contact object in an org that was initially configured by a team of four. Nobody currently in the business knows what 12 of them were for. Six of them have values in them. None of those six are populated in any consistent pattern. Data quality that surfaces when it matters: Duplicate records that were fine until someone tried to merge the customer list. Incomplete opportunity records that looked passable in a rep’s pipeline view and are now making the forecasting model meaningless. A key account field that was always optional and is now populated on 34 percent of records. Integration points documented nowhere: A MuleSoft flow configured by a consultant who left 18 months ago. A Zapier connection that was a temporary solution and is still running in production. An API key that rotates but the credentials are only saved in someone’s local .env file. What a Health Check actually covers Health Check area What is reviewed What the output looks like 🔐 Security configuration Profile audit against current job functions. Permission set review for over-assignment. Sharing rule validation. Inactive user status. MFA enrollment status across all internal users. List of access grants that do not match current team structure — users with access they should not have, users without access they need, and inactive accounts still enabled. ⚙️ Automation health Flow error log review. Deprecated Process Builders still running in production. Trigger conflict analysis. Automation overlap detection — where multiple automations fire on the same record event. Prioritised list of automations to retire, consolidate, or fix. What is conflicting, what is silently failing on edge cases, what is technically correct but fragile. 📋 Data quality Duplicate record analysis. Required field compliance rate across key objects. Orphaned record identification. Field population consistency across the objects used most frequently in reporting. The data quality problems most likely to affect reporting accuracy, Agentforce reliability, and the integrity of any AI deployment that reasons from CRM data. 🔧 Technical debt Custom field usage analysis — which fields have no data and no references. Unused object identification. Deprecated integration inventory. Hardcoded references in Apex and Flows. What to clean up first for the best maintainability impact. The items that make the org slower, harder to document, and more expensive to change. ⚡ Performance Page load issue identification. Governor limit risk assessment for high-volume operations. Query performance review for the reports and dashboards your team runs most frequently. What to address before it becomes a user experience problem — slow pages, reports that time out, operations at risk of hitting Salesforce governor limits at scale. A structured Health Check is a review across five specific areas, each with a defined output. Security configuration: Profile audit against job function, permission set review for over-assignment, sharing rule validation, inactive user status check, MFA enrollment verification. Output: a list of access grants that do not match current team structure. Automation health: Flow error log review, identification of deprecated Process Builders still running in production, trigger conflict analysis, automation overlap detection. Output: a prioritised list of automations to retire, consolidate, or fix. Data quality: Duplicate record analysis, required field compliance rate, orphaned record identification, field population consistency across the objects your team uses most. Output: the data quality problems most likely to affect reporting and AI reliability. Technical debt: Custom field usage analysis, unused object identification, deprecated integration inventory, hardcoded references in Apex and Flows. Output: what to clean up first for the best maintainability impact. Performance: Page load issue identification, governor limit risk assessment for high-volume operations, query performance review for reports and dashboards your team runs most frequently. Output: what to address before it becomes a user experience problem. Common Health Check findings — things we see in almost every orgThese are not worst-case scenarios. They are standard. 👤A user with System Administrator profile who left the company 6–18 months ago. Account still active. No deactivation was logged. 🔄A deprecated Process Builder still firing in production alongside the Flow that replaced it — both running on the same record update, producing conflicting results on edge cases nobody has found yet. 📦Custom fields on high-volume objects with no data, no record type reference,
TrueSolv 7th Anniversary. Here Is What We Are Doing With Them.
Seven years ago TrueSolv started with a laptop, a Salesforce login, and considerably more confidence than clients. The anniversary was Sunday. This post is the Monday version. We are marking it the way that actually matters to you — not with a party you cannot attend, but with free hours on your Salesforce org. No strings, no upsell script, just work that needs doing. 7 Seven Years in the Making Founded in Tbilisi, Georgia · Also operating from Dubai, UAE 7years of Salesforce implementation, development, and consulting 2countries · 1 distributed team · 1 timezone gap that somehow works 7industries served across the client portfolio Industries: NonprofitFintechHealthcareSaaSRoboticsLegalReal estate What seven years of Salesforce consulting actually looks like TrueSolv was founded in Tbilisi, Georgia, and now operates across Tbilisi and Dubai. Seven years in a single industry gives you a particular kind of longitudinal view: you see the same problems appear in different clients, at different stages, in different industries, in the same repeating patterns. You also see how the platform changes underneath the work. When we started, the conversation was Classic versus Lightning and whether Lightning was actually ready. Now the conversation is how Agentforce agents should be scoped and what the data quality requirements are for a reliable AI deployment. The specific questions change; the underlying work — understanding what a business needs from Salesforce and building it correctly — stays constant. We have worked across nonprofits, fintech companies, healthcare teams, SaaS businesses, robotics companies, legal firms, and real estate operations. The industries are different. The version of “we built something that worked and then something changed and now it does not quite work anymore” is surprisingly consistent across all of them. To every client who brought us that problem over the past seven years: thank you. The challenging ones especially. You are the reason we got better at this. The campaign: free Salesforce work through August 10 From July 27 through August 10, TrueSolv is offering free Salesforce work under four hours. No minimum commitment, no catch. If the job takes longer than four hours, the first four hours are still free — you only pay for anything beyond that, and we will tell you before we go further. What four hours actually covers What four free hours can actually coverNo projects, no retainers — just work that needs doing, this week, for free ⚙️A stuck automationA Flow that fires at the wrong time, a process that was working six months ago and stopped, an integration that produces errors nobody has tracked down. 🔐A permission issueA user who should see something and cannot. A user who can see something they should not. A profile configuration question that has been bouncing between your team and Salesforce support. 📊A report that never works rightThe numbers do not match what your team expects, the filters are not doing what they look like they should be doing, a dashboard that someone decided to trust and probably should not. ✅A configuration change on the backlogSomething small that would make the CRM noticeably better for the people using it every day, but has been sitting on a list because nobody has gotten to it. These are not the kinds of problems that require a multi-week project. They require someone who knows Salesforce to look at them without billing pressure. That is what the free hours are for. 🎂 7th Anniversary Free Hours CampaignEnds Aug 10 4Free hours on your Salesforce org — no minimum commitment, no catch Aug 10Campaign closes — this week only If the job takes longer than 4 hours, the first 4 are still free. You only pay for anything beyond — and we tell you before we go further. Seven years is a good time to do something useful. Book your free hours at truesolv.com before August 10 — no strings, no catch. Follow us on LinkedIn and Instagram — we will be sharing more from the last seven years all month. TrueSolvSalesforce Consulting7 Year AnniversaryFree Consultation Share: LinkedIn Twitter / X Copy link In this article 01Seven years of consulting 02The free-hours campaign 03What 4 hours covers 🎂 Anniversary Offer 4 free hours on your Salesforce org No strings. No catch. Through August 10 only. Claim your free hours → About the Author AR Anastasia RashkunaMarketing Specialist & Author at TrueSolv
Salesforce Report Step-Up MFA
Starting July 1, your Salesforce users will be prompted to verify their identity every time they open a report. Not when they export it. Every time they open it. Every 120 minutes by default. If nobody on your team knew this was coming, Monday morning answered that question with a support queue. Here is what it is, why Salesforce introduced it, and what admins need to configure — including the setting most documentation skips. ⚡ SalesforceReports → Q2 Customer Pipeline Report content loading… 🔐 Verify your identity to view this report Salesforce requires identity re-verification to access reports. This prompt appears every 120 minutes by default. 📱Salesforce AuthenticatorTap the notification in the app 🔑Security KeyInsert and touch your key Verify with Salesforce Authenticator No enrolled method? You’ll receive a one-time code by email or SMS instead. This prompt is expected — not a security incident. All Salesforce users now see this every 120 min when accessing reports. Interval is configurable by your admin. What step-up MFA on reports actually means Step-up MFA is a secondary verification that fires when a user reaches a high-risk surface, even if they already authenticated with MFA at login. In this case, the trigger is any Salesforce report — opening it, not exporting it. The prompt appears before the report loads. The default re-verification window is 120 minutes. After a user verifies, they can open reports freely for 120 minutes before the prompt returns. This is configurable — which is the part most admin documentation understates. For users already enrolled in an MFA method, the step takes 15 to 30 seconds. For users with no enrolled method, the system falls back to email or SMS one-time passcode. If that also fails, the user cannot open the report at all. This applies to all internal orgs platform-wide, live since July 1. Why Salesforce introduced it Reports are the highest-risk data surface in most Salesforce orgs. A user with View All Data can navigate to the Reports tab, open a standard contact report, run it unfiltered, and export 50,000 records to a spreadsheet in under two minutes. The exported file leaves Salesforce with no record that it happened unless a Transaction Security Policy was in place. The step-up MFA requirement is specifically about the gap between “authenticated at login” and “accessing a surface that enables bulk data extraction.” Login MFA proves identity when a session starts. Step-up MFA proves continued identity at the moment of high-risk data access. What admins need to do now — four steps Report Step-Up MFA — Admin ActionsLive July 1 1Communicate to all report users before they discover it themselvesWithout context, users interpret the verification prompt as a security incident, phishing attempt, or system error. A one-paragraph internal message — what the prompt is, why it appears, what to do if it fails, who to contact — prevents a wave of support tickets and builds trust rather than confusion. 2Verify all active users have an enrolled MFA methodSetup → Identity → Identity Verification. Add MFA enrollment status column to your user list view. Users without any enrolled method fall back to email or SMS OTP. If that also fails — no mobile number registered, slow email delivery — they cannot open reports. Reach out to unenrolled users directly. 3Configure the re-verification interval for your team’s workflowThe 120-minute default is adjustable and most documentation skips this. Find it at: Setup → Identity → Session Settings → High-Assurance Session Timeout. The setting is org-wide. Consider shorter (60 min) for regulated environments; consider longer (240 min) for teams running reports continuously throughout the day. 4Create a user FAQ covering the four questions that will recurAnswer proactively: what is this prompt, how to enroll an MFA method, what to do if verification fails, and whether the prompt means the account has been hacked. A Chatter post or internal knowledge article takes an hour and replaces dozens of individual support conversations. Configuring the re-verification interval — where to find it Setup → Identity → Session Settings → High-Assurance Session Timeout 60 minRegulated environments — HIPAA, SOC 2, or internal policies requiring shorter session timeouts. More frequent prompts, stronger security posture. Appropriate if your audit requirements specify session limits. 120 minDefault — Salesforce’s chosen balance between security and usability. Suitable for most orgs. Users in standard report workflows will see the prompt once or twice per working day. 240 minHigh-frequency reporting teams — Analytics, operations, and management teams running reports throughout the day who find 120-minute prompts disruptive. One prompt at the start of the work session, one at the end. The setting is org-wide. No per-profile or per-permission-set configuration is available in the current release. One interval applies to all internal users. What this does not affect External users and Experience Cloud community users are not covered by the report step-up requirement in the current enforcement scope. The change applies to internal users accessing Salesforce through the standard internal login path. Reports embedded in Lightning record page dashboards operate differently from reports accessed directly through the Reports tab. The step-up prompt fires when a user navigates directly to a report — not currently when a dashboard component rendering report data is loaded on a record page. This distinction matters for orgs where report data is primarily surfaced through embedded dashboard components rather than the Reports tab itself. Step-up MFA on reports has been live since July 1. If your users have already encountered it, the communication gap already cost you some support tickets. The remaining configuration work — interval adjustment and the internal FAQ — takes less than a day and prevents the same tickets from recurring every time a new user hits the prompt for the first time. Salesforce AdminSalesforce SecurityMFASalesforce Reports Share: LinkedIn Twitter / X Copy link In this article 01What step-up MFA means 02Why Salesforce introduced it 034 admin actions required 04What this does not affect ⚡ Four admin actions Communicate to all report users first Check MFA enrollment for every user
Agentforce World Tour Boston 2026
Agentforce World Tour Boston happened on June 24 at the Hynes Convention Center. One full day, thousands of Salesforce customers, partners, developers, and admins, and a consistent message that came out of every session: the companies seeing real results from Agentforce are the ones that treated it as a workflow redesign, not a feature rollout. Here is what stood out and why it matters for the rest of 2026. 01Workflow first, agent secondEvery successful deployment in Boston case studies started with a specific painful workflow and built the agent around solving it — not the reverse.→ Start with the problem. The agent is how you solve it at scale. 02Data quality blocks everything upstreamEvery breakout session on Agentforce hit the same wall: outdated knowledge articles, inconsistent field population, product usage data never synced to CRM.→ Clean the data before building the agent. The gap is almost always upstream. 03Two agents before full orchestrationOrchestration sessions focused on the one-plus-one pattern: one primary agent, one specialist. Realistic first step before a full multi-agent build.→ Full orchestration comes after learning the single-agent failure modes. The deployment pattern that is actually working The Agentforce deployments generating real, demonstrable outcomes at Boston — the ones that made it into session case studies and partner showcases — had one structural thing in common: they started with a specific, painful workflow and built the agent around eliminating that pain. Not “we want to use Agentforce” and then a use case search. A specific problem, a defined success condition, an agent built to address both. The orgs that struggled described the opposite process. They had access to Agentforce, they had enthusiasm from leadership, and they started configuring agents before they had clearly defined what the agent was supposed to fix. The result was a technically functional agent that did not map to a meaningful business outcome — which, in practice, means it did not get adopted and did not get measured, so it could not be improved. Treat the first Agentforce deployment as a workflow redesign project that happens to produce an agent, not an AI project that happens to touch a workflow. The workflow is the thing. The agent is how you deliver the redesign at scale. Summer ’26 features in the room Multi-Agent Orchestration drew the most attention in the architecture and developer sessions. The pattern most discussed was not the full multi-agent system — which most attendees acknowledged they were not ready to build — but the simpler version: one primary agent with one specialist. A service agent that delegates billing questions to a billing specialist, handles the rest itself, and escalates complex cases to a human. That two-agent step before a full orchestration build is more realistic for teams deploying Agentforce for the first time. The Agentforce Self-Service live demos were notable for accuracy. Showing the 10-click setup in a real sandbox rather than a polished demo environment gave attendees a realistic view of what quick setup means — and what the knowledge grounding and topic configuration work looks like after the 10 clicks. The knowledge grounding sessions in particular were practical: the gap between “agent is activated” and “agent answers your specific questions accurately” is almost entirely a content gap, and Boston gave admins a concrete picture of how to close it. The data quality conversation, again This was the most consistent theme across breakout sessions regardless of the specific topic. Whether the session was about churn prediction agents, renewal automation, or sales qualification workflows, the technical blockers were almost always upstream of the agent itself. Outdated knowledge base articles that caused the agent to give stale product information. Inconsistent field population that made the account summary unreliable. Product usage data that was flowing to a data warehouse but never made it into Salesforce, so the agent could not see it. Integration users that had logged into Salesforce once during setup and never had their MFA enrolled, creating a credential problem on July 20 enforcement day. The point is not new — data quality as prerequisite to AI deployment has been said at every Agentforce event since launch. What Boston added is specificity: practitioners describing the exact gaps that blocked their specific workflows, and the order in which those gaps need to be closed. Looking forward: Dreamforce 2026, September 15–17 Platform Trajectory — Boston to Dreamforce 2026 (September 15–17) Platform Status — Late June 2026 ✅Multi-Agent Orchestration GA — available but most orgs still learning single-agent patterns before adopting orchestration ✅Agentforce Self-Service GA — 10-click setup available; knowledge grounding and topic tuning remain the primary post-setup work ✅Data 360 MCP Server in Developer Preview — early adopters experimenting; write-back and production access pending GA ✅Flow Orchestration free — included in Enterprise and above; first wave of adoption beginning ⚠️MFA enforcement approaching — July 1 and July 20 deadlines; admin preparation still in progress across the ecosystem What Dreamforce 2026 May Bring 🔮Orchestration reference patterns — Q1 of production deployments will produce validated architecture templates; DF26 typically codifies these into platform guidance 🔮Data quality tooling — Boston’s consistent data quality theme signals platform investment; expect metadata hygiene or Data Cloud enhancements addressing the upstream gap 🔮Enterprise integration layer — connecting Agentforce to non-Salesforce systems at scale is the next frontier after within-org orchestration 🔮Agent governance for regulated industries — compliance-grade audit trails for agent behaviour are the gap preventing regulated industry adoption; strong candidate for Winter ’27 preview at DF 📅Dreamforce 26 — September 15–17, 2026 Moscone Center, San Francisco Boston’s core message was practical, not aspirational: start with the workflow, keep the first deployment small, fix your data before your agent. The organisations that take that framing into Dreamforce will be in a meaningfully better position than the ones arriving with a blank slate. Agentforce World TourSalesforceAgentforceDreamforce 2026Salesforce Events Share: LinkedIn Twitter / X Copy link In this article 01The deployment pattern that works 02Summer ’26 features in the room 03Data quality — again 04Looking forward to Dreamforce Dreamforce 2026 Sep 15–17
Salesforce MFA Enforcement July 2026
Salesforce is not asking anymore. Starting July 1 in production, users who open a report will need to re-verify their identity even if they just logged in. By July 20, every internal user in every production org will need multi-factor authentication — not as a recommendation, but as a locked system setting that admins cannot disable. Five enforcement changes, three deadline dates, and zero tolerance for orgs that are not ready. Date What changes Who it affects July 1 Step-up MFA on every reportAny user who runs or views a report is prompted to re-verify identity, even after a recent login. All orgs, not Shield-only. All users who access reports. Users not enrolled in MFA are blocked at this step-up prompt — not just at login. July 1 Phishing-resistant MFA for privileged usersSystem Admins and users with Modify All Data, View All Data, or Manage Users must switch to hardware keys or passkeys. Authenticator apps no longer qualify. System Administrator profile users, plus anyone with Modify All Data, View All Data, or Manage Users via permission set — not just via profile. July 13 Transaction Security Policies auto-created for Shield orgsShield orgs without a custom export TSP get one auto-created for exports over 10,000 records. Shield-licensed orgs only. Orgs with existing export TSPs are unaffected. Auto-created policies may need review before this date. July 20 Full MFA locked for all internal usersSalesforce locks the MFA setting. Admins cannot disable it. Any user not enrolled is blocked from login entirely. All internal users in all production orgs. No exceptions, no grace period. Unenrolled users cannot log in after this date. July 20 MFA Opt Out permission stops workingThe self-service exemption permission for automation and integration users ceases to function. Integration users and automation service accounts currently using the opt-out permission. Must file a Salesforce Support case before July 20 for a supported exemption. Change 1: Step-up MFA on every report — July 1 From July 1, any user who runs or views a report in Salesforce is prompted to verify their identity again, even if they authenticated at login minutes earlier. This applies to all reports, not just exports, and not just Shield-licensed orgs. It is platform-wide. The practical impact on end users is a second prompt in their session flow when they access report functionality. Orgs with high report usage — sales dashboards, weekly pipeline reviews, regular operational reporting — should communicate this change to their users in advance. A verification prompt that appears without warning reads as a potential security incident to users who were not expecting it. The enrollment implication is more significant: any user who accesses reports and is not enrolled in an MFA method will be blocked at this step-up verification. Enrollment must be complete before July 1 for report-heavy users specifically, not just before July 20 for the general rollout. Change 2: Phishing-resistant MFA for privileged users — July 1 System Administrators and users with Modify All Data, View All Data, or Manage Users permissions must switch to a phishing-resistant authentication method by July 1. An authenticator app — the method most admins currently use — no longer qualifies for these privilege levels. Phishing-resistant methods at GA include hardware security keys compliant with FIDO2 (YubiKey and similar devices) and passkeys stored on a trusted device. Biometric authenticators on modern devices qualify when configured as passkeys. The action required for admins right now is an audit of which users hold elevated permissions in production. The Admin profile is obvious. The less obvious group is permission sets that grant Modify All Data, View All Data, or Manage Users without giving the System Administrator profile — these users are subject to the same requirement and are frequently missed in pre-enforcement preparation. Change 3: Transaction Security Policies for report exports — July 13 Shield-licensed orgs that do not have a custom Transaction Security Policy governing report exports will have one automatically created by Salesforce on July 13. The auto-created TSP applies to exports over 10,000 records and adds a verification step or block depending on the default configuration. Orgs with Shield that have already configured export TSPs are unaffected. Orgs with Shield that have not configured them should review the auto-created policy before July 13 and determine whether the default behavior is appropriate for their specific export patterns. Auto-created policies are a starting point, not a final configuration. Change 4: Full MFA for all internal users — July 20 On July 20, Salesforce locks the Multi-Factor Authentication setting in all production orgs. The setting cannot be disabled by an admin after this date. Any internal user who is not enrolled in an MFA method is blocked from logging in until enrollment is completed. What gets blocked if users are not enrolled on July 20: complete login block for any internal user without an enrolled MFA method. They cannot log in at all — not to read email, not to view their opportunities, not to run a report. The fix is to complete enrollment, which takes time that may not exist in the middle of a blocked login incident. The recommended approach is to complete enrollment for all internal users before July 13 — one week before the final deadline — to allow time to address any enrollment issues before the lock takes effect. Change 5: MFA exemption permission stops working — July 20 The MFA Opt Out of Multi-Factor Authentication permission, which some orgs have used to exempt automation users and integration service accounts from MFA requirements, stops functioning on July 20. Integration users and automation service accounts that use this permission for their login flow must be handled through an alternative path before the deadline. The supported path for integration and automation users who require a login flow incompatible with MFA is a Salesforce Support case filed before July 20, documenting the specific use case and requesting an exemption through the supported process. The self-service permission-based exemption will not be available after enforcement. ⚠What gets blocked —
Salesforce Flow Orchestration is Free in Summer 26
Flow Orchestration used to cost extra. Now it does not. Starting with Summer ’26, Flow Orchestration runs are included in Enterprise, Performance, Unlimited, and Developer editions without usage-based limits. If you ruled it out before because of the pricing, that calculation is gone. Here is what Flow Orchestration actually does, and why it is worth a fresh look. What Flow Orchestration actually is A regular Flow handles a trigger and a sequence of automated steps. It runs, completes, and is done — typically in seconds, with no pause for a human to weigh in partway through. Flow Orchestration is built for a different category of process: multi-step, multi-user business processes that require coordination across people, systems, and time. The work needs to pause, wait for a specific person to make a decision, branch based on that decision, and continue — all in a monitored, auditable way, potentially over hours, days, or weeks. The distinction matters because many processes that orgs currently handle through a combination of email, manual task assignment, and someone remembering to follow up are exactly the kind of process Orchestration is built for. The reason most orgs have not built these in Salesforce is that Orchestration previously carried a usage-based cost that made it hard to justify for internal process automation rather than customer-facing workflows. Characteristic Regular Flow Flow Orchestration Duration Runs and completes in seconds. No pause for human input mid-process. Can span hours, days, or weeks — pauses at human steps and resumes when action is taken. Human involvement Limited to triggering the flow or responding to a single approval step bolted on separately. Built-in stages where specific people are assigned tasks, make decisions, and the process branches based on their input. Visibility No persistent status view. Once running, you cannot easily see “where” the flow currently is. Defined stage model — anyone can see which stage a process instance is currently in and who owns it. Multi-department coordination Difficult — typically requires chaining multiple flows and manual handoffs between departments. Native — parallel and sequential stages across different teams with a single coordinated process instance. Best for Record updates, notifications, single-step automations, data validation, immediate actions triggered by a record change. Onboarding processes, approval chains, multi-department workflows — anything where “who does this next and when” is the core challenge. Cost (Summer ’26) Included in all editions, as always. Now free Included in Enterprise, Performance, Unlimited, and Developer editions — no usage-based limits. A simple orchestration, structurally The shape of an orchestration is consistent regardless of the specific process: a system step does something automatically, a human step pauses and waits for a person to act, the orchestration branches based on what that person decided, and the process continues — potentially with more human steps, more branches, and a final system step that records the outcome. A Simple Flow Orchestration — Four Stages Stage 1 System action e.g. create record AUTOMATED Stage 2 Human approval Manager reviews and decides PAUSES & WAITS Stage 3 System action e.g. update fields AUTOMATED Stage 4 Branch → Approved path → Rejected path OUTCOME RECORDED Status, owner, and stage are visible to anyone checking on the process — not just whoever is currently assigned. What makes this different from a Flow with an Approval Process attached is the structure and visibility. Orchestration gives you a defined stage model — each stage has a clear owner, a clear set of possible outcomes, and a status that is visible to anyone checking on the process, not just the person whose turn it currently is. For processes spanning multiple departments, that visibility is often the missing piece. Three workflows worth building now that it is free New employee onboarding across IT, HR, and the hiring manager Onboarding touches multiple departments with sequential and parallel dependencies: IT needs to provision accounts, HR needs to complete paperwork, the hiring manager needs to prepare the first-week schedule, and some of these steps depend on others completing first. An orchestration can sequence IT provisioning after HR confirms the start date, run HR paperwork and manager prep in parallel, and surface a single status view to whoever is coordinating the new hire’s first day. The alternative — the current state at most orgs — is a checklist in a shared document and a series of Slack messages asking whether each step is done yet. Orchestration replaces the asking with visibility. Contract approval chain with parallel legal and finance review A contract above a certain value needs review from legal and finance before it reaches an executive for final sign-off. Legal and finance review can happen in parallel — neither depends on the other — but the executive sign-off step depends on both being complete. Orchestration models this directly: a parallel stage for legal and finance, a convergence point that waits for both to complete, then a sequential executive approval stage. The audit trail shows who reviewed what and when, without anyone needing to track it manually. Deal desk workflow for non-standard pricing approvals Non-standard pricing requests — discounts above a threshold, custom payment terms, non-standard contract clauses — typically need sign-off from sales leadership, finance, and sometimes RevOps, in an order that depends on the specific request. An orchestration can route the request to the right combination of approvers based on the deal characteristics, track where it currently sits, and notify the rep when a decision is made. The business value here is speed: deal desk requests that currently take days because they sit in someone’s inbox move faster when the orchestration actively routes and tracks them, and the rep has visibility into where the holdup is rather than just waiting. 3 Workflows Worth Building Now That Orchestration Is FreeProcesses most orgs currently run on email, shared docs, and hoping someone follows up 👋New employee onboardingIT provisioning, HR paperwork, and hiring manager prep — sequenced and parallelised with a single status view for whoever is coordinating the new hire’s first day.Stages: HR confirms start date
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
Salesforce Summer 26 Release Features
Salesforce announced Summer ’26 on May 11 and set the general availability date for June 15. The headline: 17 major capabilities, all pointing in one direction. Agentforce is no longer a feature layer on top of the platform. In Summer ’26 it is becoming the operating layer underneath everything else. Here is what actually landed and what it means for your org. Salesforce Summer ’26 — Five Changes That Shape the Platform 🤝Multi-Agent OrchestrationAgents delegate to specialist agentsOne customer-facing contact point, multiple specialist agents working behind the scenes. Triage → delegate → coordinate — without the customer switching interfaces.GA — Summer ’26 ⚡Agentforce Self-ServiceHelp Agent in 10 clicks or fewerDeploy a Help Agent to your public website, Portal, or WhatsApp in a guided setup — designed for teams who want to trial Agentforce without a multi-week implementation.GA — Summer ’26 🛡️Security MeshUnified security fabric + risk scoringDisconnected security alerts across Service Cloud, Sales Cloud, and Experience Cloud unified into a single fabric with AI-generated risk scores. Agentforce activity included.GA — Summer ’26 🔄Flow Orchestration — FreeIncluded in Enterprise and aboveFlow Orchestration moves from a usage-limited add-on to included in Enterprise, Performance, Unlimited, and Developer editions. No usage caps, no add-on cost.Now included 📊Tableau over Model Context ProtocolAnalytics engine exposed to Agentforce agentsTableau’s analytics engine is now reachable by Agentforce agents over MCP, protected by the Agentforce Trust Layer. Agents can query revenue trends, spend analytics, and historical reports as part of their reasoning — without requiring a human to pull the report first. Closes the gap between CRM data and the BI layer.GA — Summer ’26 Multi-Agent Orchestration For most of Agentforce’s history, an agent was a single system handling a single domain. A service agent answered product questions. A sales agent qualified leads. Each worked independently and each required its own configuration. Multi-Agent Orchestration changes that architecture. Agents can now delegate tasks to specialist agents within the same org. One customer-facing contact point, multiple agents working behind the scenes: a triage agent receives the request, determines which specialist — a billing agent, a technical support agent, a returns agent — should handle it, delegates the task, and coordinates the result back to the customer without the customer ever switching interfaces. The practical implication for orgs with complex service or sales workflows is that you can build specialist agents for distinct domains and let orchestration handle the coordination, rather than trying to build one agent that knows everything. Simpler individual agents, more reliable outcomes at the orchestration level. For developers, the build model changes too. Agent teams can be tested and deployed independently. Failures in one specialist agent are contained rather than cascading through the entire interaction. Agentforce Self-Service The barrier to deploying an Agentforce Help Agent drops significantly in Summer ’26. Agentforce Self-Service is a setup path that gets a Help Agent deployed in 10 clicks or fewer — configured, grounded in your knowledge base, and ready to go on your public website, the new Portal experience, or WhatsApp. The positioning is explicit: Salesforce is targeting the orgs that have heard about Agentforce but found the implementation path too complex for their team size or technical capacity. Self-Service is designed to remove that barrier without removing the ability to customise later. For admins at smaller orgs who have been waiting for a way to trial Agentforce without a multi-week implementation project, this is the most directly actionable Summer ’26 announcement. For larger orgs, the Self-Service path is worth understanding as a rapid prototyping route before committing to a full agent build. Security Mesh Security Mesh unifies data sources across the Salesforce platform into a single security fabric and transforms disconnected access logs and alerts into intelligent risk scores. Instead of reviewing separate security events across Service Cloud, Sales Cloud, and Experience Cloud independently, Security Mesh provides a unified view with AI-generated risk assessment. The practical value for compliance-minded orgs is in audit efficiency. Security events that previously required cross-referencing multiple tools to understand their combined significance are now surfaced as correlated risk signals. Additionally, Security Mesh integrates with the Trust Layer that governs Agentforce agents, meaning agent activity is included in the unified risk picture rather than existing as a separate data source. Flow Orchestration now free Flow Orchestration moves from a usage-limited add-on to an included feature in Enterprise, Performance, Unlimited, and Developer editions without usage-based limits. This removes the licensing conversation from any multi-step process automation project. The timing is intentional. As Agentforce agents become more common in Salesforce orgs, the need to coordinate complex multi-step workflows across agents, humans, and systems increases. Flow Orchestration is the tooling that handles that coordination on the Salesforce side. Making it free removes the last friction point from adopting it broadly. For orgs that evaluated Flow Orchestration and passed because of cost, Summer ’26 is the time to revisit any approval workflows, cross-department handoff processes, or multi-system coordination tasks that are currently running on manual steps or basic Flow. Tableau over Model Context Protocol Tableau’s analytics engine is now exposed to Agentforce agents over the Model Context Protocol, protected by the Agentforce Trust Layer. An agent reasoning about a customer renewal can query Tableau for historical revenue trends. An agent managing a procurement workflow can pull spend analytics directly from the BI layer without requiring a human to run the report first. For data-heavy orgs, this is the most architecturally significant Summer ’26 addition after Multi-Agent Orchestration. It closes the gap between Salesforce CRM data — which agents have had access to — and the analytical layer that lives in Tableau but has been outside the agent’s reach. Role Most relevant Summer ’26 feature What to do now Admin Agentforce Self-Service lowers the barrier to deploying a Help Agent to your website or Portal. Flow Orchestration now free removes the licensing blocker for multi-step approval workflows. Explore Try the Self-Service setup in a sandbox. Identify one approval workflow worth rebuilding in Flow Orchestration now that cost is not a
Salesforce Summer 26 Admin Checklist
The Summer ’26 production upgrade is landing on June 5 and June 12 for most Salesforce orgs. Sandboxes have been on preview since May 8, which means there is no excuse for surprises on production upgrade weekend. Here is the pre-upgrade checklist every admin needs before their org flips. Summer ’26 Production Upgrade Weekends 🚨 June 5 — TomorrowMain production waveMost orgs on NA, EU, and AP instances. If your org is on this wave, the checklist below needs to be complete today — not this weekend. 📅 June 12 — 8 daysFinal production waveRemaining instances. You have until June 11 EOD to complete all mandatory items. Use the time — do not save this checklist for June 10. The mandatory items — these break things if skipped 1. SAML migration New SAML defaults are enforced in Summer ’26. If your org uses SSO via SAML — whether Salesforce is the identity provider, the service provider, or both — you need to verify your Auth Provider configuration and test the full login flow in your Summer ’26 sandbox before production upgrade. A SAML configuration that worked in Spring ’26 may fail after the upgrade if the new defaults require updated settings. Additionally, Triple DES signing for SAML SSO stops working entirely in Summer ’26, as announced in Spring ’26. Any SAML configuration using Triple DES as the signing algorithm breaks on upgrade regardless of whether you took any other action. 2. Apex sharing and security defaults New Apex security behaviors are enforced. Custom Apex code that relies on specific sharing model assumptions from earlier releases needs review. If your org has custom Apex classes managing record-level access or security, test them against the Summer ’26 sandbox before your production upgrade date. 3. Standard Omni-Channel retirement Standard Omni-Channel was retired June 1. If your production org has not migrated to Enhanced Omni-Channel Routing, this is now urgent — not scheduled. Completing the migration before your production upgrade date is the priority. See the dedicated Omni-Channel migration article for the correct four-step sequence — channel migrations must happen before the routing switch is enabled. 4. Legacy PDF generation retirement A legacy PDF rendering behavior is retired in Summer ’26. Any process that generates PDFs from Salesforce — Quote PDFs, Visualforce-generated reports, any custom PDF output — should be tested in the Summer ’26 sandbox to confirm the output is correct before production upgrade. PDF rendering changes are difficult to detect until something generates incorrectly in front of a customer. Summer ’26 Pre-Production Upgrade ChecklistBefore June 5 or June 12 Mandatory — breaks things if skipped SAML auth provider configuration verifiedMandatoryNew SAML defaults enforced. Test full SSO login flow in Summer ’26 sandbox. Triple DES signing algorithm stops working entirely — update to SHA-256 if still using Triple DES.↳ Breaks: SSO login fails for all SAML-authenticated users after upgrade Custom Apex sharing code reviewedMandatoryNew Apex security defaults enforced. Custom Apex classes managing record-level access or sharing rules need testing in sandbox against the new defaults. Run Apex tests in the Summer ’26 sandbox before production upgrade.↳ Breaks: Record access violations or unexpected sharing behaviour in Apex-governed objects Enhanced Omni-Channel migration completeMandatory · UrgentStandard Omni-Channel retired June 1. Migrate service channels (Live Agent, SMS, Messenger) first, then enable Enhanced routing. Test agent login and work item routing in sandbox end-to-end.↳ Breaks: Agents cannot log in to Omni-Channel, work items stop routing entirely PDF generation processes tested in sandboxMandatoryLegacy PDF rendering behaviour retired. Any process generating PDFs from Salesforce — Quote PDFs, Visualforce reports, custom PDF output — must be tested in Summer ’26 sandbox.↳ Breaks: Incorrectly formatted or failed PDF generation for customer-facing documents Recommended — should be done; will not immediately break Agentforce agent configurations reviewedRecommendedSummer ’26 changes agent lifecycle defaults. If your org has agents in production, review the Agentforce Summer ’26 release notes and test agent initialisation, session handling, and error surfacing in sandbox. Evaluate Flow Orchestration for existing processesOptional upsideFlow Orchestration is now free in Enterprise, Performance, Unlimited, and Developer editions. Review multi-step approval processes or cross-object coordination workflows that could benefit from rebuilding in Orchestration. Exact production upgrade date confirmedRecommendedSetup → Company Information → Instance. Then trust.salesforce.com to find your exact upgrade weekend. Some instances upgraded May 15 — if yours was in that wave, your production org is already on Summer ’26. The items you should do but that will not break immediately 5. Flow Orchestration is now free Flow Orchestration is included in Enterprise, Performance, Unlimited, and Developer editions without usage limits in Summer ’26. If your org has been avoiding Flow Orchestration due to licensing cost, that barrier is gone. Evaluate whether any current multi-step approval processes or cross-object coordination workflows would benefit from rebuilding in Orchestration. 6. Review Agentforce configurations Summer ’26 changes agent lifecycle defaults for orgs running Agentforce in production. If your org has agents in production — even in early access or limited deployment — review the Summer ’26 Agentforce release notes and test agent behaviour in sandbox before production upgrade. 7. Confirm your exact upgrade date Do not assume June 5 or June 12. Your specific upgrade date depends on your Salesforce instance. Check: Setup → Company Information → Instance field. Then confirm your upgrade date at trust.salesforce.com. Some instances upgraded May 15. If your org is on one of those instances and you are reading this on June 4, your production org may already be on Summer ’26. Summer ’26 is the release where “I’ll check the sandbox later” becomes a problem. The June 5 wave is tomorrow. If your sandbox has been on preview since May 8 and you have not looked at it yet, today is the day. Salesforce Admin Summer ’26 Salesforce Release SAML Upgrade Checklist Share: LinkedIn Twitter / X Copy link In this article —Mandatory items 01SAML migration 02Apex security defaults 03Omni-Channel migration 04PDF generation —Recommended items 05Flow Orchestration free 06Agentforce review 07Confirm your date Upgrade dates May 15First wave — already liveCheck if
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