Agentforce Implementation, Where to Actually Start
Everyone is talking about autonomous agents in Salesforce, but few teams can name one concrete first step. The honest answer to where to start with Agentforce implementation is with one workflow, not a strategy. Pick a single repetitive task your team can already describe clearly, ground the agent in Salesforce data and content you already trust, and get that one agent live before touching a second use case. AGENTFORCE IMPLEMENTATION / FIRST STEP TODAY Manual workflow Readiness assessment Blueprint & grounding First live agent WHERE TEAMS ACTUALLY START Case deflection Email drafting Agent-assisted replies Start narrow. One workflow, one agent, a human still in the loop. From today’s manual step to a first live agent — readiness assessment, blueprint, then go live. What Agentforce can actually do right now Agentforce uses the automations and integrations already in your Salesforce org as callable actions, then pairs those actions with answers pulled from your CRM data and approved content. It works inside topics and routing you define, not as an open-ended assistant that figures out your business on its own. That’s not a limitation to apologize for. It’s what makes an agent’s answers traceable back to data your business actually owns, instead of a plausible-sounding guess. Where teams actually start 💬Case deflectionThe agent answers common support questions from your knowledge base before a ticket ever reaches a human queue. ✉️Email draftingThe agent prepares a first-pass reply grounded in the case history, and a rep reviews it before anything goes out. 🤝Agent-assisted repliesInside Slack or the service console, the agent surfaces a likely answer with its source, and a person still makes the call. Every one of these keeps a human in the loop on the first pass. That’s by design. The point of a first use case is proving the agent’s answers hold up against real questions, not handing it the keys on day one. What an Agentforce implementation with TrueSolv involves It starts with a readiness assessment, a review of your org, data sources, and target workflows to confirm what Agentforce can support now and what needs prep first. From there, a use case workshop turns one workflow into a clear blueprint, with topics, allowed actions, handoff rules, and success metrics defined before any building starts. Data grounding comes next, configuring the agent to answer from your Salesforce data and approved sources, alongside a knowledge cleanup pass so it pulls one consistent answer instead of three conflicting versions. Agent Builder configuration sets up the topic structure, routing, and guardrails, and a Flow and Apex action library lets the agent actually complete tasks inside Salesforce, not just talk about them. Structured testing on topic and action selection runs before rollout, and monitoring stays on after go-live so the agent keeps improving on real usage instead of staying frozen at launch. The point of a first use case is proving the agent’s answers hold up against real questions, not handing it the keys on day one. Book an Agentforce readiness call through our contact form, and follow TrueSolv on LinkedIn for more on where this technology is actually ready today. AgentforceSalesforce AIAI AgentsSalesforce ConsultingTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What Agentforce can do now 02Where teams actually start 03What implementation involves Implementation steps 1Readiness assessment 2Use case workshop & blueprint 3Data grounding & KB cleanup 4Agent Builder configuration 5Testing & rollout 6Monitoring after go-live Ready for a first agent? Book a readiness call to scope one workflow and get a real blueprint. Book a readiness call → About the Author AS Anastasia SokolovaSalesforce Developer at TrueSolv
Task Tracker Salesforce App That Keeps Deadlines Visible
Tasks live in Trello or Asana, deals live in Salesforce, and the manager finds out about a missed deadline last. A task tracker Salesforce app fixes that by keeping tasks, due dates, and priorities on the same record as the deal or case they belong to, so a missed deadline shows up on the account itself instead of surfacing three tools away, days after it mattered. OUTSIDE SALESFORCE Trello / Asana board Email thread ! Manager finds out last True Task Tracker SALESFORCE Task & due date Priority tag Comments & files One task list, tied to the deal it belongs to. Trello board, email thread, and a manager finding out last — all replaced by one task list on the Salesforce record. Why splitting tasks and CRM data costs more than convenience A rep works from a board in one tab while the deal record sits open in another, and the two never fully sync. A task gets marked done in Trello and the opportunity record never reflects it. A follow-up call slips because the person who owns the deal isn’t the person watching the board, and the two tools were never going to tell each other. That’s not a discipline problem. It’s a system problem. Two tools with two sources of truth will always drift, and the gap between them always costs someone — a rep who missed a follow-up, a manager scanning a pipeline that doesn’t show the half-overdue task still sitting in Asana. What comes with it True Task Tracker — what’s included 📋Tasks created, assigned, and managed with due dates — right on the record they belong to, no separate login 🏷Flexible tags to prioritize and categorize, plus custom columns for how your team actually works 🔔Instant notifications when a task changes, so a status update doesn’t wait to be noticed hours later in a different tool 📎Files and comments attached directly to the task, instead of scattered across email threads and Slack conversations ↕️Drag-and-drop task movement for updating status without a form to fill out — the way boards work, inside Salesforce Who gets the clearest win A sales team gets the clearest result first. Follow-up tasks sit directly on the opportunity, so a manager scanning the pipeline sees exactly which deals have an overdue task without opening a separate board to check. A support team benefits just as much. Escalation tasks get assigned with a due date and a priority tag right on the case, and the comments and attachments that explain the escalation stay with it instead of living in three different Slack threads. The support lead sees what’s overdue, who owns it, and why it was flagged — all from the same record view they’re already in. The deadline was always real. Now it lives where the deal does. Request a True Task Tracker demo through our contact form, and follow TrueSolv on LinkedIn and Instagram for more tools built to keep work inside Salesforce. True Task TrackerSalesforce ProductivitySales OpsCRM ToolsTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Why splitting tools costs more 02What’s included 03Who gets the clearest win Deadlines still living in a separate board? True Task Tracker puts tasks, due dates, and priorities directly on the Salesforce record. Request a demo → 5 things included 📋Tasks + due dates on the record 🏷Flexible tags + custom columns 🔔Instant notifications on change 📎Files + comments on the task ↕️Drag-and-drop status update About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
Apex Unit Test Best Practices Beyond the Coverage Number
Plenty of orgs hit the 75 percent coverage requirement with tests that check nothing real at all. Coverage counts which lines of code ran during a test, not whether the test verified anything meaningful. A test that inserts a record, calls a method, and confirms only that no exception was thrown will happily push coverage past 75 percent while catching zero actual regressions. Real Apex unit test best practices start from a different question: whether the test would fail the moment the underlying logic breaks, not whether it satisfies a percentage. APEX TESTING / CI PIPELINE 75% Coverage number alone Real assertions Bulk data, 200+ Mocked callouts CI gate Deploy What actually gates the merge Assertions tied to business outcome, not just the absence of an error 200+ record bulk test on every method that touches DML or SOQL External callouts mocked, never live inside a test context From a 75% coverage number to a CI gate that actually stops a broken assumption from shipping. The gap between passing and protecting A weak test looks productive. It compiles, it runs, it shows green in the deployment log, and the coverage number goes up. What it usually skips is any assertion tied to business outcome. It checks that a record exists, not that a field landed on the value the logic was supposed to produce. Six months later, someone changes a trigger, every existing test still passes, and the bug ships anyway — because nothing in the suite was actually watching for it. Assert patterns that actually catch something A test worth keeping asserts on the specific outcome the code is supposed to produce, not just on the absence of an error. That means asserting the field value that should have changed, the record count that should have resulted, or the exception that should have been thrown on a bad input. Here is a pair of tests for a trigger that updates a custom forecast category once an opportunity crosses an amount threshold. @isTest private class OpportunityRoundingTest { @isTest static void updatesForecastWhenAmountChanges() { Account acc = new Account(Name = ‘Test Account’); insert acc; Opportunity opp = new Opportunity( Name = ‘Renewal Deal’, AccountId = acc.Id, StageName = ‘Prospecting’, CloseDate = Date.today().addDays(30), Amount = 10000 ); insert opp; Test.startTest(); opp.Amount = 25000; update opp; Test.stopTest(); Opportunity updated = [ SELECT Forecast_Category_Custom__c, Amount FROM Opportunity WHERE Id = :opp.Id ]; Assert.areEqual(25000, updated.Amount, ‘Amount should reflect the update’); Assert.areEqual(‘Best Case’, updated.Forecast_Category_Custom__c, ‘Forecast category should move once the deal crosses the threshold’); } @isTest static void doesNotDefaultAmountWhenLeftBlank() { Account acc = new Account(Name = ‘Test Account 2’); insert acc; Opportunity opp = new Opportunity( Name = ‘Early Deal’, AccountId = acc.Id, StageName = ‘Prospecting’, CloseDate = Date.today().addDays(60) ); Test.startTest(); insert opp; Test.stopTest(); Opportunity result = [SELECT Amount FROM Opportunity WHERE Id = :opp.Id]; Assert.isNull(result.Amount, ‘A deal with no amount should stay null, not default to zero’); } } Both tests assert on the actual business rule — the forecast threshold and the null default — not just on the record existing. Bulk data catches what a single record never will A test that inserts one record will pass even when the underlying code runs a query or a DML statement inside a loop, because one iteration never comes close to a governor limit. Two hundred records will. Building bulk data into a test is the difference between finding that bug in a sandbox and finding it in production during a mass import. @isTest static void handlesBulkInsertWithoutHittingLimits() { List<Account> accounts = new List<Account>(); for (Integer i = 0; i < 200; i++) { accounts.add(new Account(Name = ‘Bulk Account ‘ + i)); } Test.startTest(); insert accounts; Test.stopTest(); List<Account> inserted = [ SELECT Id FROM Account WHERE Name LIKE ‘Bulk Account%’ ]; Assert.areEqual(200, inserted.size(), ‘All 200 accounts should insert without hitting a governor limit’); } Mocking callouts without touching a real endpoint Any test that reaches out to a real external system is slow, flaky, and eventually blocked by Salesforce itself, since live callouts aren’t allowed inside a test context. The fix is the HttpCalloutMock interface, which lets a test hand back a fake response and check that the code parses and handles it correctly — success and failure alike. @isTest private class ShippingRateMockTest { private class SuccessMock implements HttpCalloutMock { public HttpResponse respond(HttpRequest req) { HttpResponse res = new HttpResponse(); res.setStatusCode(200); res.setBody(‘{“rate”: 14.50, “carrier”: “Standard”}’); return res; } } @isTest static void parsesRateFromSuccessfulCallout() { Test.setMock(HttpCalloutMock.class, new SuccessMock()); Test.startTest(); ShippingRate rate = ShippingService.getRate(‘90210’); Test.stopTest(); Assert.areEqual(14.50, rate.amount, ‘Rate should match the mocked response body’); Assert.areEqual(‘Standard’, rate.carrier, ‘Carrier should be parsed from the JSON response’); } } A second mock returning a 500 status covers the failure path that actually breaks integrations in production. Wiring tests into CI before anything merges None of this holds up if tests only run when someone remembers to run them by hand. Wiring Apex tests into a CI pipeline means every pull request triggers a deploy to a scratch org or sandbox followed by a full test run, and a merge simply can’t happen if a test fails or coverage drops below the threshold. name: apex-tests on: [pull_request] jobs: test: runs-on: ubuntu-latest steps: – uses: actions/checkout@v4 – run: sf org login sfdx-url –sfdx-url-file authFile.txt –alias ci-org – run: sf project deploy start –target-org ci-org – run: sf apex run test –target-org ci-org –code-coverage –result-format human –wait 20 A coverage number without CI is a report nobody reads until deploy day. A coverage number wired into every pull request is a gate that actually stops a broken assumption from shipping. Send your test suite our way through the contact form for a custom development and code review pass, and follow TrueSolv on LinkedIn for more Apex notes. Apex CodeSalesforce DevCRM DevelopmentSalesforce TestingTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Passing vs protecting 02Assert patterns that work 03Bulk data (200+ records) 04Mocking callouts 05Wiring into CI What actually gates the merge Assertions on business outcomes — not just “no exception” Bulk data
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 Field History AI Readiness
An Agentforce agent grounded in your Salesforce data will give answers based on whatever your records contain. If a field was overwritten six weeks ago by a bad import, the agent does not know that. If a contact’s status was manually edited three times without a logged reason, the agent treats the current value as correct. Your AI is only as trustworthy as your data history. True Field History is how you know what your data actually is. Opportunity Field History — What the Agent Sees vs. What Actually Happened What the Agentforce agent sees CurrentOpportunity StageProposal SentLast changed: 18 days ago CurrentAmount$45,000No recent changes noted CurrentClose DateAug 31, 2026Set at opportunity creation Agent readAgent assessmentDeal progressing — moderate paceNo risk flags surfaced What the field history actually shows 8 days agoStage was moved backVerbal Commit → Proposal SentNo reason logged. Changed by rep. 12 days agoAmount was reduced$78,000 → $45,000No reason logged. Changed by rep. 15 days agoLast activity loggedEmail sent — no responseNo follow-up logged since RealityActual risk profileStage regression + amount cut + 15 days darkSignificant risk. Agent had no visibility into this. The agent saw three fields and assessed normal deal progression with no risk flags. The field history shows a stage regression, a significant amount reduction, and 15 days of no contact — all without logged reasons. The AI data trust problem most deployments skip When organisations deploy Agentforce, the configuration conversation focuses on agent topics, knowledge base grounding, escalation logic, and Trust Layer guardrails. These are the right things to configure. What most organisations underestimate is the quality and reliability of the data the agent is reasoning from. An Agentforce agent does not evaluate data quality. It does not flag uncertainty about data recency. It does not know that the contract end date on an account was changed two months ago from a correct value to an incorrect one during a data cleanup task that went wrong. It presents what it finds and reasons from it as if it is accurate. This is not an agent problem. It is a data problem that the agent makes visible in a new way: not as a messy CRM that someone will clean up eventually, but as an AI system that answers incorrectly right now. Three scenarios where field history and Agentforce intersect 💚Customer Health ScoringAgent reasons from activity fields Specific vulnerabilityLast Contacted fields edited by reps to satisfy KPIs or look better in pipeline reviews. Agent reads the edited date, computes recency, produces a health score built on fabricated history.→ Field history reveals: accounts where Last Contacted was manually edited without a corresponding logged activity. 📋Contract Renewal AgentAgent triggers from contract dates Specific vulnerabilityInformal renegotiations that change terms verbally but never update the contract end date in Salesforce. Agent fires renewal outreach at the original date for a contract already renegotiated.→ Field history reveals: contract end dates not updated despite account activity suggesting renegotiation. 📊Pipeline & Deal RiskAgent reasons from stage and amount Specific vulnerabilityStage regressions and Amount reductions with no logged reason. Agent sees current stage and amount, assesses normal progression, misses the risk pattern entirely visible only in the change log.→ Field history reveals: stage regressions, amount cuts preceding a stage change, patterns inconsistent with deal movement. Scenario 1: Customer health scoring agents A customer health scoring agent ingests activity data — last contacted date, meeting count, support ticket volume, product usage signals — and produces a health score or churn risk flag that surfaces in account management workflows. The specific vulnerability is in manually managed fields: Last Contacted date fields that can be edited by reps. True Field History exposes this pattern before the agent is grounded in it. Scenario 2: Contract renewal agents A renewal agent monitors contract end dates and triggers outreach at defined thresholds before expiration. The common failure mode is informal renegotiations where the AE updates pricing in a side document, verbally confirms new terms, but never updates the contract end date in Salesforce. The renewal agent fires at the original date, triggering outreach for a contract that was already renegotiated. A renewal audit using field history takes 20 minutes and catches this problem before the agent encounters it. Scenario 3: Pipeline and deal risk agents An agent surfacing deal risk and stage progression analysis needs Opportunity Stage and Amount fields to reflect current deal reality. These are two of the most commonly manipulated fields in Salesforce. An agent reviewing an Opportunity that shows Stage: Proposal Sent, Amount: $45,000, Last Stage Change: 3 weeks ago will flag that deal as progressing normally. If the actual history shows the Stage was at Verbal Commit 10 days ago before being moved back without a logged reason, the risk profile is completely different — and the agent has no way to know. The broader argument for a pre-AI field history audit The three scenarios above share a structural pattern: a field value that looks correct in the current record is unreliable because of how it arrived at the current value — overwritten, manually edited without reason, or changed in a way that is inconsistent with the surrounding activity log. None of these problems are visible by looking at the current record. All of them are visible in the field change history. A pre-AI deployment field history audit identifies which fields the agent will reason from, which of those fields have unreliable change histories, and what data quality remediation is needed before the agent is grounded in those fields. For a focused Agentforce deployment — an agent reasoning from a defined set of Account and Opportunity fields — the relevant field history can be reviewed and flagged in days. Pre-AI Deployment Field History AuditRun this before grounding any Agentforce agent in Salesforce data Map what the agent will reason from List the specific fields the agent will access for each topicEvery field in the agent’s grounding scope is a data quality risk. Make the list explicit before the audit — not all
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 Headless 360 and MCP
For most of Salesforce’s history, building on the platform meant working inside it: browser open, Setup menu navigated, page layouts configured. Salesforce Headless 360, announced at TDX on April 15, draws a line under that era. Every piece of the platform (data, workflows, business logic, compliance controls) is now reachable as an API, an MCP tool, or a CLI command. No browser required. Here is what that actually means if you build integrations or work with AI coding tools. Salesforce Headless 360 — How the Platform Is Now Exposed Salesforce Platform Data · Flows · Logic · Permissions Headless 360 REST / Bulk / Streaming Standard Salesforce APIs 60+ MCP Tools AI-callable structured tools CLI / DevOps Center Programmatic CI/CD access Human Developers CLI · VS Code · CI/CD pipelines AI Coding Agents Claude Code · Cursor · Codex Integration Systems MCP servers · External APIs No browser required. Every capability reachable as API, MCP tool, or CLI command. What Salesforce Headless 360 Ships With The headline number is 60 new MCP tools exposing Salesforce capabilities as structured interfaces that AI agents can call directly: objects, flows, deployments, permissions, reports. Alongside those, 30 preconfigured coding skills cover the most common Salesforce development tasks, from writing Apex triggers to configuring permission sets. DevOps Center MCP and Natural Language DevOps The DevOps Center MCP is the most immediately practical piece for integration teams: it brings programmatic access into any CI/CD pipeline. Natural Language DevOps sits on top of that: describe what you want to deploy in plain language and agents execute it. Salesforce cites a 40 percent cycle time reduction for development workflows as an early benchmark from teams using the integrated toolchain. The framing from Salesforce is that the build loop requiring context-switching across four different tools now happens inside one connected experience. That is the right framing, but the practical reality depends heavily on where your org’s metadata and documentation quality sits right now. What MCP means for Salesforce integrations The Model Context Protocol is becoming the default interoperability layer for AI agents across the industry. By exposing Salesforce through MCP, Salesforce is positioning itself as a participant in multi-agent orchestration, not just a destination for data, but a system that AI agents from Claude Code, Cursor, Codex, and Windsurf can work within directly. The practical shift for integration teams is significant. Instead of writing API wrappers manually (defining the request shape, handling authentication, mapping the response), you describe the integration behaviour and an agent executes and tests it using the MCP tools that already understand Salesforce’s object model. A Practical Integration Example For example: an integration that syncs Salesforce Opportunity data to an external billing system previously required a developer to write and maintain the API connection, handle field mapping, and manage error states. With MCP-exposed Salesforce tools and an AI coding agent, the same integration can be described in plain language, generated, and validated against the actual org schema, including custom objects and fields, without manual API documentation reading. The constraint is the quality of the description. Vague integration requirements produce vague integrations. MCP tools remove the API plumbing problem; they do not remove the requirement to know what you are building. Agent Fabric and multi-agent governance Headless 360 opens the Salesforce platform to AI agents. Agent Fabric answers the follow-on question: when you have multiple agents from multiple vendors operating across Salesforce and other systems, who governs them? Agent Fabric is the control plane launched at TDX 2026. It provides deterministic orchestration and centralised governance across agents, tools, and LLMs, scanning for agents across Salesforce Agentforce, Amazon Bedrock, Microsoft Foundry, and MCP servers, then providing a unified view of what agents exist, what they have access to, and what they are doing. Why Deterministic Governance Matters The governance problem it solves is specific: AI agents are probabilistic. They reason toward outcomes, which means their behaviour cannot be fully predicted from the instruction set alone. Agent Fabric adds the deterministic layer: Agent Broker defines fixed handoff rules between agents, Agent Script enforces compliance checkpoints within workflows, and Trusted Agent Identity ensures agents execute with specific user permissions rather than a shared service account. For architects designing systems where agents span Salesforce and external platforms, Agent Fabric is the piece that makes enterprise-grade deployment possible rather than merely experimental. Workflow Traditional Salesforce dev Headless 360 + AI coding agents Write an Apex trigger Open Developer Console or VS Code → write Apex → deploy to sandbox → test manually → deploy to production Describe the trigger behaviour in natural language → agent writes Apex using your org’s actual object model → review → deploy via DevOps Center MCP Build a Salesforce integration Read API docs → write request/response handlers → map fields manually → handle auth and error states → test in sandbox Describe integration behaviour → agent generates using MCP tools that understand your schema → automated testing → review and approve Understand an existing automation Open Flow Builder or Apex class → read through the logic → trace dependencies manually → ask a colleague Ask Vibes (Ask mode): “Explain this trigger and whether it conflicts with the Process Builder on this object” — org-aware answer with dependency context Debug a production issue Reproduce locally → inspect error log → trace through code → write fix → test → deploy Debug mode: agent analyses error log, identifies root cause in org context, proposes targeted fix → developer reviews and applies Deploy a change across environments Package the change → run change set or Salesforce CLI deploy → validate in staging → release Natural Language DevOps: describe the deployment in plain language → agent executes via DevOps Center MCP with CI/CD pipeline integration Context-switching across tools VS Code → Org → Developer Console → Sandbox → Jira → Slack → back to Org. Multiple context switches per task. One connected experience inside the development environment. Salesforce cites 40% reduction in development cycle time. What you need before Headless
Stripe and Salesforce integration for SaaS companies
Your Stripe dashboard shows who is paying. Your Segment or PostHog shows who is actually using the product. Your Salesforce shows who the sales team is talking to. Three tools, three completely separate truths, and no connection between them. The most dangerous churn is the kind where a customer goes quiet in the product weeks before the renewal and nobody on the sales team knows, because they are looking at a different screen. At 30 to 50 people, this gap stops being an inconvenience and starts costing real revenue. How the Three Systems Connect in Salesforce Segment or PostHog PRODUCT EVENTS Stripe Billing & Subscriptions BILLING DATA Salesforce Account · Opportunity Contract · Lead · Contact SALESFORCE FLOW PQL events usage scores MRR · plan · status Renewal Opportunity auto-created at 90-day window PQL Task for Rep triggered by product threshold CS Churn Alert usage drop triggers CS queue Stripe and Segment/PostHog feed Salesforce. Flow automation handles the rest. How this gap forms at the 30–50 person stage At 10 people, three separate systems are manageable. The founder knows every customer. The CS lead knows the product numbers. The AE knows the renewal dates. Context lives in heads rather than systems, and that works until it does not. At 30 to 50 people, the team is too large for context to live in heads, and too small to have dedicated RevOps infrastructure. Stripe renewals are tracked in a shared spreadsheet that someone updates when they remember. Product usage reports are emailed by the data team on Fridays, if at all. Salesforce has the account records, but none of the product or billing reality is visible on them. The result is a sales team operating on incomplete information, a CS team reacting to churn rather than preventing it, and a leadership team whose pipeline numbers do not reflect what is actually happening in the customer base. Three problems that appear when these systems are not connected The renewal blind spot A subscription renewal is not a surprise event. The date is known. The contract value is known. And yet, in most SaaS companies at this stage, renewals are managed through a combination of calendar reminders, spreadsheet exports from Stripe, and a Salesforce pipeline that someone populated three months ago and has not touched since. The specific failure mode is not the missed renewal itself it is the missed signal. A customer whose usage dropped 60% in the 30 days before renewal is telling you something. Without Stripe and product data flowing into Salesforce, that signal is invisible. The rep goes into the renewal call having seen nothing change in CRM, not knowing the customer has already mentally moved on. Research from SaaS industry benchmarks consistently shows that companies managing renewals manually lose 10 to 15 percent more ARR to avoidable churn than those with connected systems. At a $3 million ARR base, that is between $300,000 and $450,000 a year in revenue that a spreadsheet is costing you. 10–15% more ARR lost The cost of managing renewals manually SaaS companies that track renewals in spreadsheets — without automated CRM visibility into billing and product usage — lose 10 to 15 percent more ARR to avoidable churn than those with connected systems. At a $3M ARR base, that is between $300K and $450K per year that a spreadsheet is costing you. SaaS industry renewal benchmarks The PQL opportunity going uncontacted The most valuable leads in a SaaS company are not the people who filled out a demo form. These are Product-Qualified Leads, and they are worth three to five times the conversion rate of a cold inbound lead. The problem is that the signal for a PQL lives in Segment or PostHog. It does not live in Salesforce. So when a user activates your most advanced features and invites four teammates in the same week, nothing happens in CRM. Meanwhile, the rep’s call list is full of people who clicked an ad or downloaded a whitepaper. The highest-intent users in your product are invisible. The quote and proposal bottleneck At this stage, sales reps are usually creating proposals in one of three ways: a Google Docs template they copy and paste from, a PDF that lives on someone’s desktop, or an email they wrote from scratch. None of these live in Salesforce. None of them can be tracked, approved by a manager, or analyzed for win rates. Furthermore, when a deal closes, nobody can trace back from the Opportunity to the quote that was sent. Pricing decisions, discount patterns, and approval workflows are invisible to leadership. The audit trail does not exist because the quotes were never in the system. What a sales rep’s week looks like without the integration vs. with it What the rep sees Without integration With integration Current MRR / plan ACV from when the deal was first entered. May not reflect a seat reduction or downgrade that happened in Stripe. Live MRR pulled from Stripe, updated on the Account record in real time. Seat count and plan visible at a glance. Product usage trend Not visible. Rep would need to ask the CS lead, who would need to pull a report from PostHog or Segment manually. 30-day engagement score and key feature activation events visible directly on the Account record. Renewal date In the spreadsheet maintained by one person. Or a calendar reminder. Possibly both, possibly disagreeing. Renewal Opportunity auto-created 90 days out, visible in pipeline alongside new business, with value from contract. Churn risk signal None — unless a customer raises a support ticket or emails to cancel. Risk is identified at or after the churn event. Usage drop flag auto-generated when engagement falls below baseline for 14+ days. CS task created before the call. Payment health Unknown. A declined card or failed payment from last month would not appear in CRM. Payment status from Stripe on the Account record. Failed payments surfaced as a risk flag before the renewal call. Expansion opportunity Rep guesses
How to Use GEO in Salesforce Experience Cloud
SEO is not dead, but it has a new layer on top of it. Spring ’26 added Generative Engine Optimization to Salesforce Experience Cloud — a single toggle in Experience Builder that tells AI engines like ChatGPT, Perplexity, and Gemini how to read your portal content directly from the source. If your customers are starting their searches in AI chat instead of Google, this matters more than you might think. Here is what the feature does, how to turn it on, and which types of Salesforce sites benefit most. What Generative Engine Optimization actually does When a user asks ChatGPT or Perplexity a question about your product or service, the AI engine looks for publicly available content to ground its answer. If your Experience Cloud site is not set up to accommodate that process, the engine either ignores it or generates an answer from indirect sources — which may not reflect your current content accurately. GEO changes that by allowing AI bots to request a structured content snapshot of your public site pages. The snapshot gives the AI a clean, source-verified version of your content to work with, rather than a cached or scraped approximation. The result is that your portal becomes citable: when someone asks an AI assistant a question your help center or community site answers, there is a higher chance the answer comes from your actual content. This is the core difference from traditional SEO. Traditional SEO tells Google’s web crawler how to index your page for search ranking. GEO tells AI language model crawlers how to read and reference your page when generating answers. Dimension Traditional SEO GEO Target audience Google, Bing, and other traditional search engine crawlers AI-powered answer engines: ChatGPT, Perplexity, Gemini, Google AI Overviews Goal Rank higher in search results pages Be cited accurately in AI-generated answers Core mechanism Crawlable HTML, meta tags, backlinks, structured data, page speed Structured content snapshots that AI bots can request and process What it optimises for Click-through from a results list Accuracy and attribution when the user never sees a results list Where users see the result A link in a list of search results they click through An answer that cites your content directly in the AI interface Requires publishing Crawled on Google’s schedule, not yours Snapshot reflects your content as of the last site publish How to enable in Salesforce SEO settings: page title, meta description, canonical, sitemap Experience Builder → Settings → SEO → enable GEO toggle → republish Replaces the other? No — parallel tracks for parallel channels. Both are worth managing. Where to find the toggle and how to enable it The GEO setting lives in Experience Builder under the SEO settings panel. The path is: Experience Builder → Settings → SEO → Provide content snapshots of public site pages when requested by AI bots Enable the toggle, then republish the site. The setting takes effect on the next publish. It applies to both Aura and LWR sites and is available in Enterprise, Performance, Unlimited, and Developer editions. There is no additional configuration required at the page level. The toggle works across all public-facing pages on the site. Pages behind authentication are not included — GEO only applies to content that is publicly accessible without a login. How to Enable GEO in Experience Builder Spring ’26 — 3 steps 1 Open your Experience Cloud site in Experience Builder Navigate to the site you want to update. You need Admin access or a profile with Experience Cloud site management permissions. Setup → All Sites → Builder 2 Go to Settings → SEO and enable the GEO toggle In the left panel, open Settings. Select SEO. Find the option labelled “Provide content snapshots of public site pages when requested by AI bots” and enable it. Settings → SEO → AI bots toggle → ON 3 Publish the site The GEO setting takes effect on the next publish. Click Publish in Experience Builder to apply the change. The setting then applies to all public-facing pages on both Aura and LWR sites. Publish → Confirm Available in Enterprise, Performance, Unlimited, and Developer editions. Applies to public pages only — authenticated content is not included. What a content snapshot actually is A content snapshot is a static HTML version of your page that AI crawlers can request and process. It is optimised for machine reading rather than browser rendering — it strips out the dynamic elements, JavaScript-rendered content, and navigation chrome, and returns the core textual content of the page in a clean format. For AI engines, this is more reliable than attempting to crawl a JavaScript-heavy page where the main content only appears after client-side rendering. Furthermore, it means the snapshot reflects what is actually published in your Salesforce CMS, not a cached version from weeks ago. The practical implication is accuracy. If your help center article says your product supports a specific integration, the snapshot contains that exact statement. The AI engine citing your content has a verified source, rather than a reconstructed one. Which Salesforce portals benefit most from enabling GEO Which Salesforce Portals Benefit Most from Enabling GEO Public pages only 📖 Self-service help centers and knowledge bases Articles, FAQs, and troubleshooting guides are exactly the content AI engines look for when answering product questions. GEO makes your help content the cited source instead of a paraphrased approximation. Highest impact 🤝 B2B partner portals with public documentation Product docs, integration guides, and pricing pages are actively searched by B2B buyers using AI research tools. A GEO-enabled portal appears in that research process; one without it does not. High impact 💬 Community sites with publicly visible content Community answers to product questions are high-value for AI engines because they reflect real usage. If your community is publicly viewable without login, GEO makes that content accessible in the right format. Good candidate 🏢 Customer-facing product or service information sites Any Experience Cloud site where prospects or customers look up your features, plans, or support
10 Salesforce Automations Every SaaS Team Should Have
Salesforce is not magic. Out of the box, it is a database with a nice interface. What makes it actually useful for a SaaS company is the layer of automation built on top of it .