Salesforce Agentic Identity Gives AI Agents Their Own Login
📍 Part of our Dreamforce 2026 coverage — see also AIforce and the permission cleanup it just made urgent Until now an AI agent working in Salesforce borrowed the login of the person it was helping. 🔐 Salesforce Agentic Identity changes that and gives every agent its own badge, its own permissions and its own paper trail. For admins this is the security upgrade they quietly wanted. For finance teams it also brings a new line in the budget, so it pays to understand both sides before your first external agent goes live. BEFORE Maria Sales Rep login Full user permissions Agent acts as Maria AFTER Agent ID Own OAuth app Own scoped permission set Own activity log Its own badge, not a borrowed one. An agent that used to borrow a login now gets its own badge, its own permissions and its own activity log. What is Salesforce Agentic Identity Salesforce Agentic Identity is a registration system that gives each AI agent connecting to Salesforce its own OAuth credentials and its own scoped permission set, instead of acting under the login of the employee it serves. An agent gets issued its own badge rather than borrowing an employee’s badge, and every action it takes is tied back to that badge alone. This matters now because the quiet workaround is already everywhere. Claude, ChatGPT and custom built agents already read and write CRM data through MCP and direct API calls, almost always under a human user’s credentials, which means an audit log cannot actually tell you whether a given record change came from the person or from the tool acting on their behalf. What changes for admins Every external agent gets registered and scoped the way a new employee would be, under the principle of least privilege rather than inheriting a person’s full access Every agent action becomes fully traceable, and access can be revoked for one agent in a single click without touching the human user it used to borrow credentials from MCP clients will eventually move to the OAuth credentials of the registered agent identity instead of a shared user login Traditional integration Registered AI agent Identity Borrows a human user’s login Own OAuth credentials Permissions Inherits full user access Scoped, least privilege Audit trail Blends into user’s history Fully traceable to the agent Pricing model Standard API pricing Flex Credits per interaction Metered in sandbox Not applicable No, sandboxes are free Five rows, traditional integration against a registered AI agent. How Flex Credits metering will work Every successful call a registered agent makes to Salesforce, whether it arrives through MCP or a direct API call, will count as a Headless Platform Interaction and draw down Flex Credits, tracked through Digital Wallet. Traditional integrations keep today’s pricing, and sandboxes, scratch orgs and Developer Edition orgs are not metered under this model, so building and testing an agent costs nothing extra before it goes live. STEP 1 Agent calls MCP or direct API STEP 2 Identity checked Salesforce verifies the badge STEP 3 Action runs Scoped to agent permissions STEP 4 Logged Recorded in Digital Wallet What happens, in order, every time a registered agent reaches into Salesforce. ⏳ Salesforce has not yet published the Flex Credit multiplier for a Headless Platform Interaction, so the per call cost cannot be calculated yet. Salesforce has committed to 30 days of notice before metering actually begins, which gives every org a real window to measure expected agent volume before a single credit is charged. A five point readiness checklist Agentic Identity Readiness List every AI tool that already touches Salesforce Name one accountable owner per agent Draft a scoped permission set per agent Estimate monthly call volume per agent so the Flex Credit cost is not a surprise Build and test each agent in a sandbox first truesolv.com, before your first external agent goes live Before your first external agent goes live. Agents with their own identity are easier to trust, easier to audit and much easier to explain to a security team asking hard questions about what is touching customer data. Agentic Identity builds directly on the access review we covered in AIforce and the permission cleanup it just made urgent. For a structured way to do that review, see our Salesforce permission set audit guide. Dreamforce 2026Agentic IdentityAgentforceSalesforce AdminTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What is Agentic Identity 02What changes for admins 03How Flex Credits metering works 04Readiness checklist Key facts Billed unitHeadless Platform Interaction Paid inFlex Credits Tracked inDigital Wallet MultiplierNot yet published Notice before metering30 days SandboxesNot metered Dreamforce 2026 coverage ← Full recap hub AIforce & permissions Seven job ready agents Koa & multi-model AI → You are here: Agentic Identity Agents already touching your CRM? We inventory every AI tool with Salesforce access and scope a permission set per agent. Book an agent access review → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Koa and the New Multi Model AI Lineup
📍 Part of our Dreamforce 2026 coverage — start with the full announcement recap For two years every Salesforce roadmap meeting had the same awkward question. Which AI should we bet on? At Dreamforce 2026 Salesforce gave the most generous answer possible. Pick any of them, and now there is a brand new one built specifically for CRM. 🧠 MULTI MODEL AI / WHERE YOU MEET EACH ONE YOUR DATA Koa Reasoning inside Salesforce Claude Salesforce in Claude, beta Gemini Prompt Builder, Gemini Enterprise Amazon Bedrock Available to Agentforce now OpenAI Inside Agentforce and ChatGPT Five models on the menu, one thing that decides how smart they look. Meet Koa Koa is the first Salesforce CRM reasoning model, built together with NVIDIA and trained on a synthetic dataset modeled on almost three decades of CRM deployments. Salesforce controls the weights and runs Koa inside its own infrastructure, so customer data stays within the trust boundary during inference, and no customer data was used for training. Koa is in pilot with select customers now, and general availability is expected in winter 2026 for US regions. Everyone else is invited too Model Where you will meet it in Salesforce Koa CRM reasoning inside Salesforce infrastructure Claude Salesforce in Claude, in beta on paid Claude plans, and powering Agentforce Vibes by default Gemini Prompt Builder and the Agentforce reasoning engine, plus Salesforce inside Gemini Enterprise Amazon Bedrock models Available to Agentforce customers now OpenAI models Inside Agentforce, with Agentforce also reachable from ChatGPT So who actually wins Your data does. When the model becomes a choice, picking the wrong one gets much cheaper, and the real value moves to what every model depends on. Clean records, sensible permissions and well documented business rules now decide how smart any of these models look inside your org. Three questions for your next leadership meeting 1Who in our company decides which model runs which workload? 2Where is our data allowed to go, and which regions matter for our customers in the US and Europe? 3How will we log and review what each model does inside Salesforce? Answer them now and next year’s model announcements turn into an easy upgrade instead of a long debate. Salesforce just turned AI from a single bet into a full menu, and the companies with the cleanest data will order best. Catch up on the rest of the series with the full announcement recap, or see AIforce and the permission cleanup it just made urgent. Dreamforce 2026Salesforce AIKoaAgentforceTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Meet Koa 02Everyone else is invited too 03So who actually wins 043 questions for leadership Dreamforce 2026 coverage ← Full recap hub AIforce & permission cleanup Seven job ready agents → You are here: Koa & model choice Not sure which model policy fits your org? Book a call to translate the new model lineup into a written AI policy. Book a strategy call → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Duplicate Rules Setup, Block or Alert
Turn on strict duplicate rules and reps start finding ways around them, turn them off and the database turns into a mess again. The short answer on block versus alert is to block on exact, high confidence matches, an identical email address, for example, and alert on everything looser, like a similar company name with a different domain. Blocking too broadly trains reps to fake a field just to get past the rule, which ends up creating worse data than the duplicate ever would have. DUPLICATE RULES / BLOCK VS ALERT New record entered EXACT MATCH BLOCK Exact email match Exact phone + last name PROBABLE MATCH ALERT Similar company name Phone formatted differently Block only what you’re basically certain about. Everything else deserves a human look. Same new record, two different matches, two different responses — block the certain ones, alert on the rest. Why default duplicate rules are either too strict or too loose Salesforce’s standard duplicate rules ship with generic matching logic that rarely reflects how a specific team actually enters data. Reps might type a company name three different ways over a year. A lead source field picks up an extra suffix depending on which form it came through. Default rules either catch too much, blocking two legitimately different contacts who happen to share a similar name at the same company, or too little, missing an obvious duplicate because a phone number was formatted with a different number of digits. How to build matching rules around how the team actually enters data Pull a sample of real duplicate pairs already sitting in the org and look at exactly what differs between them, a missing area code, Inc versus Incorporated, an extra space nobody notices. Build matching criteria around those actual patterns instead of theoretical ones, fuzzy matching on company name, exact matching on email domain, normalized comparison on phone number. Separate matching rules by object and by how that object typically gets created, since a lead from a web form behaves differently than a contact a rep types in by hand after a call. Setting rules to alert instead of block where it makes sense Block only for near certain duplicates, an exact email match, or an exact phone number paired with an exact last name. Alert for everything probable but not certain, and let the person entering the data see the potential match and decide, since they often have context the system doesn’t, this might genuinely be two different people who happen to work at the same company. Blocking a genuine near miss teaches people to route around the rule entirely, which defeats the point of having one. Cleaning up existing duplicates before turning rules on 📊Run Salesforce’s built-in duplicate management report first, to see the actual scale of what’s already sitting in the org before designing anything ✅Merge the obvious exact duplicates first, the low risk, high confidence matches, before touching anything ambiguous 👀For ambiguous matches, don’t mass merge blind, assign a quick manual review to whoever owns those accounts, since a wrong merge loses history that doesn’t come back 🔛Only turn on the new matching and duplicate rules once the existing backlog is under control, otherwise the new rule just alerts everyone constantly about a mess it didn’t create Blocking a genuine near miss teaches people to route around the rule entirely. A duplicate rule that reps have learned to defeat is worse than no rule at all — it just looks like protection. Book a data quality consultation through our contact form, and follow TrueSolv on LinkedIn for more Salesforce admin notes. Salesforce AdminData QualitySalesforce SetupCRM Best PracticesTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Why defaults are too strict or loose 02Build rules around real data 03When to alert instead of block 04Cleaning up before turning rules on Block vs Alert Exact email match→ BLOCK Exact phone + last name→ BLOCK Similar company name→ ALERT Phone formatted differently→ ALERT Duplicates piling up, or reps routing around your rules? Book a data quality consultation to get the balance right. Book a consultation → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
How To Clean Up Permission Sets
Winter ’27 just changed how profile visibility works, and that is a good excuse to finally look at who can see what. A Salesforce permission set audit starts by pulling every permission set in the org next to a current list of job roles, then checking three things for each one. Who actually has it assigned. What it actually grants. And whether anyone assigned to it still does the job it was built for. Most orgs skip this for years, which is exactly why it’s worth doing now. PERMISSION SET AUDIT / METHOD Pull inventory Match to roles Flag unused Retire safely The Winter ’27 tie-in Enable Profile Filtering already narrowed default visibility. Use this same audit pass to confirm who still has View All Profiles actually matches who needs to see profile names org-wide. Four steps from “nobody wants to touch it” to a clean audit trail — plus the Winter ’27 tie-in. Why permission sets pile up and nobody wants to touch them Permission sets get created for a one-off project, a temporary access need, a role that later got restructured, and nobody circles back to remove them once the need passes. Each one starts to feel risky to touch, because nobody is fully sure who might be quietly relying on it. The safer-feeling choice is always to leave it alone and create a new one for the next need instead, which is exactly how orgs end up with more permission sets than active job roles. A simple method to audit permission sets against real job roles 1Pull a full list of permission sets with current assignment counts, from Setup or a report on permission set assignments 2List current job roles or teams from an HR or org chart source of truth, not from Salesforce’s own picture, since that view may be the stale one 3For each permission set, check assigned users against that role list, and flag anyone assigned who has since moved to a different role, or a set assigned to nobody current at all 4Check what each permission set actually grants, object permissions and field level security, watching for kitchen sink sets that grant far more than the role in front of you needs 5Note permission sets with overlapping grants doing the same job under different names, a common sign of years of drift rather than deliberate design Retiring unused permission sets without breaking anything mid-quarter 📋Run a report on exactly who has each candidate permission set assigned right now, not from memory or an old spreadsheet ⏸Deactivate before deleting where the tool allows it, or remove the assignment first and watch for a defined window, a sprint or a full pay cycle, before removing the set itself 📢Tell the affected users’ managers before removing anything, since a permission set nobody remembers creating might still be load bearing for one workflow that only runs at quarter close 🧩Retire in small batches, not all at once, so a mistake affects a handful of people instead of the whole sales team the week they’re closing pipeline Tying this to the Winter ’27 profile visibility change Winter ’27 already narrowed default visibility with Enable Profile Filtering, users without View All Profiles now see only their own profile name, covered in our September 4 release post. The same audit that surfaces unused permission sets is the natural moment to also confirm who actually has View All Profiles, and whether that list still matches who genuinely needs to see profile names across the org, instead of who happened to get it years ago. Nobody circles back to remove a permission set once the need passes. That’s not a discipline failure, it’s the default outcome of a system that never forces the review — until something like Winter ’27 gives you a reason to finally look. Book a Health Check focused on security and permissions through our contact form, and follow TrueSolv on LinkedIn for more admin notes like this one. Salesforce SecurityPermission SetsSalesforce AdminSalesforce Health CheckTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Why permission sets pile up 02A simple audit method 03Retiring safely 04Tying to Winter ’27 4-step method 1Pull inventory 2Match to real roles 3Flag unused 4Retire safely, in batches Not sure who can see what? Book a Health Check focused on security and permissions. Book a Health Check → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Winter 27 Release, Dates and What Changes
Release notes went live on August 19, sandbox preview opened August 28, and the first production wave lands the weekend of September 4. Salesforce’s Winter ’27 release notes published August 19, 2026, sandbox preview opened August 28, and production upgrades roll out across three weekends — September 4, October 2, and October 9, assigned by instance. The most useful thing an admin can do this week is find their own org’s exact date, since two changes in this release can quietly break something before anyone notices. WINTER ’27 RELEASE TIMELINE AUG 19 Release notes AUG 28 Sandbox preview SEP 4 Production wave 1 OCT 2 Production wave 2 OCT 9 Production wave 3 Enable Profile Filtering ENFORCES THIS CYCLE Users without View All Profiles can now see only their own profile name. Apex or Flow logic querying another user’s Profile now returns empty for them. OAuth Username-Password POSTPONED TO FEB 20, 2027 Scheduled for Winter ’27, then pushed back. Delayed, not cancelled. Integrations still using username and password logins are worth auditing now. Find your org’s exact weekend on Salesforce Trust, under Maintenance. Five dates, one permission change, one deadline that moved to February 2027. The permission change worth flagging to your team Enable Profile Filtering enforces this cycle. Users without the View All Profiles permission can now see only their own profile name. If any Apex or Flow logic queries the Profile of a user other than the one running it, that query now returns empty for anyone without the permission. Worth checking before the upgrade weekend, not after a report or an automation quietly stops working and nobody can figure out why. The API login change that got a reprieve Here’s a correction worth knowing before it spreads further. The retirement of the OAuth 2.0 username-password flow — the one where an integration logs in with a username, password, and security token — was originally scheduled to enforce in Winter ’27. Salesforce postponed the enforcement date to February 20, 2027. Treat that as delayed, not cancelled. Any integration still authenticating that way will stop getting a token on the later date, and finding every affected integration takes real time, so the extra months are worth spending now rather than in January. Check Login History filtered for OAuth password logins, and review Connected Apps OAuth Usage in Setup, to see what’s actually exposed in your org. What’s actually new to use this cycle 🧩Flow Builder — grouped sections, edit history, beta Test ModeCollapsible grouped sections with their own labels, an edit history timeline that shows every save and lets you restore older versions, and a new beta Flow Test Mode that splits Build and Test inside the builder with code coverage and mock outputs. 🤖Agentforce — beta Custom Scorers, Hosted MCP ServersLets a team define its own pass or fail evaluation logic for an agent session instead of relying only on Salesforce’s built-in quality metrics, plus expanded interoperability through Hosted MCP Servers. 🌐Experience Cloud — LWR sites embed real Lightning reportsCloses a long-standing gap: LWR sites can now embed an actual Lightning report, with charts, tables, and record editing, without falling back to the older Aura framework to get it. Find your exact upgrade weekend Production dates are assigned per instance, not per org type or edition. Check Salesforce Trust, search by instance name or domain, and open the Maintenance tab to see the exact weekend for that specific org. Writer note Dates above reflect Salesforce’s published Winter ’27 schedule and Trust status as of late August 2026. Production weekends are assigned per instance, so confirm the exact date on Salesforce Trust before publishing or promising a client a timeline. Two changes in this release can quietly break something before anyone notices. Finding your org’s exact date is the highest-leverage five minutes an admin can spend this week. Book a pre-upgrade Health Check through our contact form to catch breaking integrations before your org’s wave hits, and follow TrueSolv on LinkedIn for release coverage like this. Salesforce Winter ’27Salesforce ReleaseSalesforce AdminSalesforce SecurityTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Enable Profile Filtering 02OAuth password flow — postponed 03What’s new this cycle 04Find your upgrade weekend Key dates Aug 19Release notes published Aug 28Sandbox preview opens Sep 4Production wave 1 Oct 2Production wave 2 Oct 9Production wave 3 Feb 20OAuth password flow retires (2027) Not sure what breaks in your org? Book a pre-upgrade Health Check before your production wave hits. Book a Health Check → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Dashboards for Leaders Worth Checking Weekly
Most Salesforce dashboards look great and get opened once a quarter. Good Salesforce dashboards for leaders get checked weekly, not quarterly, and they answer three questions in under five minutes. Are deals actually moving or just sitting there. Is the team working the accounts that matter. Is the forecast something to trust or optimism with a dollar sign on it. MONDAY DASHBOARD ROUTINE Pipeline velocity THE TAKEAWAY Speed through the pipeline matters more than its size. Team activity LAST TOUCH, OPEN DEALS ! 14 days quiet, no logged activity THE TAKEAWAY Silence is the warning sign, not the lost reason. Forecast accuracy Forecast Actual THE TAKEAWAY Watch the gap’s pattern, not one quarter’s number. 10 MIN, EVERY MONDAY Three reports, one takeaway each, ten minutes every Monday before the week starts. Pipeline velocity report The takeaway How fast money moves through the pipeline matters more than how much sits in it. Pipeline velocity is calculated from the number of open opportunities, average deal value, win rate, and average sales cycle length. A pipeline that looks full but moves slowly is a warning sign a quarterly review won’t catch until the quarter is already lost. Team activity report The takeaway A stalled deal shows up in activity long before it shows up in a lost reason. This report tracks calls, emails, and meetings logged against each open opportunity, sorted by days since last activity. A deal with nothing logged in two weeks deserves a manager’s attention regardless of what stage it’s sitting in. Forecast accuracy report The takeaway The number worth watching isn’t this quarter’s forecast, it’s how often last quarter’s forecast was wrong. This report compares the committed and best case numbers reps submitted against what actually closed, tracked over time. It flags who is consistently over-optimistic and who is sandbagging, which matters more than any single quarter’s total, since both patterns repeat. One dashboard, one Monday routine All three reports drop onto one dashboard, filtered to the current quarter. Ten minutes every Monday, before the week gets going, catches a stalling deal or a shaky forecast while there’s still time to do something about it, instead of finding out at quarter close when the only option left is explaining it. A dashboard checked quarterly tells you what already happened. A dashboard checked weekly gives you time to change what happens next. Send us your current reports through the contact form and we’ll help set this dashboard up. Follow TrueSolv on LinkedIn for more notes like this one. Salesforce DashboardsSalesforce ReportsSales LeadershipCRM AnalyticsTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Pipeline velocity report 02Team activity report 03Forecast accuracy report 04One dashboard, one routine 3 questions in 5 minutes Moving or sitting?Are deals actually moving or just sitting there Right accounts?Is the team working the accounts that matter Trust the number?Is the forecast trustworthy or optimism with a dollar sign Still checking dashboards quarterly? Send your current reports and we’ll help set up the weekly routine. Set up the dashboard → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Salesforce Health Check Signs Your Org Needs an Audit
The org keeps growing, automations keep piling up, and nobody has reviewed access permissions in years. You know an org needs a Salesforce Health Check when the same handful of symptoms start showing up together. Reports that give a different number depending on who pulls them. Permission sets nobody remembers granting. Flows nobody wants to touch because nobody is sure what they’d break. If two or three of those sound familiar, the org is already overdue. INSIDE THE ORG ! Unused field ! Orphaned Flow ! Permission creep ! Duplicate records Health Check HEALTH CHECK REPORT Security & access Data quality Performance & scale Org structure Licenses & contracts Integrations & API Six domains, one report, no guessing what’s actually wrong. Four warning signs inside the org — one six-domain Health Check report that names every one of them. What an unaudited org tends to look like Custom fields nobody remembers the purpose ofStill sitting on every page layout, slowing down load times, and appearing on reports where they were never meant to. Orphaned Flows referencing deleted objects or fieldsActive automations pointing at things that no longer exist — running silently, failing silently, or doing nothing at all. Permission sets that have grown broader with every hire and never been trimmedThe easiest fix at onboarding time becomes a security exposure the moment someone changes roles or leaves the company. Duplicate records quietly skewing every report that touches themTwo records for the same account mean two pipelines, two activity histories, and one number nobody fully trusts. Why this is a risk now, not a someday problem None of this happens on purpose. It happens because Salesforce is flexible enough to absorb years of quick fixes without ever forcing a cleanup, so the org keeps working just well enough that nobody schedules the review. A former employee with an active login is a live exposure the moment they leave, not a theoretical one. Reports that take too long to load or automations that quietly conflict cost real working hours every single week, not just at renewal time. The longer the mess sits, the more new work gets built on top of it, and the more expensive the eventual cleanup gets. What a Salesforce Health Check covers A TrueSolv Health Check reviews six domains in one pass: Security and access controls. Data quality and management. System performance and scalability. Org structure and customization. License and contract usage. Integrations and API health. The client walks away with a findings report running twenty to forty pages, each issue rated by severity with a plain language explanation and a specific fix. An executive summary condenses the top priorities for anyone who wasn’t in the weeds. An action item list with effort estimates plugs straight into a sprint, and a quick wins checklist flags what an admin can fix the same afternoon. The org keeps working just well enough that nobody schedules the review. That’s what makes the mess expensive — it compounds every week you don’t look at it. Run the free Salesforce Health Check self-assessment for an instant score, or book the full audit through the contact form. Follow TrueSolv on LinkedIn for more org cleanup notes. Salesforce Health CheckSalesforce SecurityCRM AuditSalesforce AdminTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What an unaudited org looks like 02Why this is a risk now 03What the Health Check covers 6 audit domains 🔐Security & access 🗄️Data quality ⚡Performance & scale 🏗️Org structure 📋Licenses & contracts 🔌Integrations & API Not sure where the org stands? Book the full six-domain audit or run the free self-assessment for an instant score. Book the Health Check → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
We Celebrated Seven Years the Way We Do Most Things
We are a distributed team across Tbilisi and Dubai, so there was never going to be one office with balloons taped to the ceiling. Instead, seven years got celebrated the way most of our workdays already happen — on a call, across time zones, and somehow still louder than expected. Here is what actually went down. TrueSolv — Year 7 Anniversary CallAugust 2026 · Full team · 1 video call 🎂7 years of Salesforce work 2countries on one call 3hours, no formal agenda 🇬🇪 Tbilisi, Georgia·🇦🇪 Dubai, UAE The format: games, not an agenda We made a deliberate decision not to structure the anniversary call around a retrospective deck or a metrics review. Seven years of those exist already. This one was structured around games, which turned out to be the right call. The format was loose: a full-team video call, a mix of people from both offices in the same frame, and three blocks of activity with no formal agenda between them. What we actually played The first block was company trivia — questions about the project history, the early years, the decisions that look obvious in retrospect and were genuinely uncertain at the time. The format was simple: a question, everyone answers, the person who gets it right gets to ask the follow-up question. Some questions were easy. Some were not. The one about which client project arrived with the strangest technical requirement — a Salesforce org that needed to track inventory for a museum, including items that had not been catalogued yet — produced a genuine debate about whether “null but billable” is a real data state. (The answer is yes, apparently, if the contract says so.) The second block was an online quiz platform — faster, more competitive, not limited to people who had been around long enough to know the company history. This levelled the playing field significantly and produced the discovery that our most competitive team member on a quiz platform is not the person anyone would have predicted. The third block was show-and-tell. Each person picked one thing from the past year — a project, a technical problem, a moment — and described it in two minutes. No slides. No preparation required. The two-minute constraint was the part that made it work: enough time to say something specific, not enough time to turn it into a presentation. Best moments from the anniversary callCompany trivia, unexpected answers, and the quiz that humbled some of us From company trivia 🏛️Which project had the strangest technical requirement?A museum inventory system that needed to track items that had not been catalogued yet. The resulting 20-minute discussion about whether “null but billable” is a valid CRM data state is now a recurring reference. 🤔What was the first Salesforce object we ever built a custom trigger for?Nobody got this right on the first guess. The people who joined in years 4 through 7 had to take it on faith that the answer was accurate. From the online quiz 🏆Most competitive team member on a quiz platformNot the person anyone would have predicted. They were very calm about winning. Suspiciously calm. 😐Highest-scoring moment in show-and-tell (informal)Someone sharing a debugging session where the bug turned out to be a missing comma in a JSON payload that took four hours to find. The room recognised it immediately. General observation 💡What a distributed team celebration actually isIt is not a party. It is a few hours where the work stops being the only thing people share. Seven years of that is a lot of shared context — and it turns out to be louder than expected when you put it all in one call. The part that is hard to describe to people who have not worked distributed A distributed team that has been working together for years accumulates shared context in a specific, gradual way. There are no hallway conversations. There are no off-the-cuff lunches. The shared context that builds in a co-located office — the running jokes, the inside references, the “you had to be there” stories — has to be built intentionally in a distributed one. What struck me about the anniversary call was how much of that context exists without anyone having planned it. Stories about the same project told from different angles by people who worked on it at different times. References to client situations that everyone understood without explanation. A team that has been doing good work together for long enough that the good work has become its own kind of shared language. That is not something you schedule into a company retrospective. It builds in the work, over time. Seven years is enough time to accumulate a lot of it. To everyone who has been part of this in any form — client, partner, or team member who moved on to something else — thank you. Seven years of this kind of work is not small. Follow us on LinkedIn and Instagram for more of what it is actually like working with a distributed Salesforce team. TrueSolvTeam CultureSalesforce Consulting7 Year Anniversary Share: LinkedIn Twitter / X Copy link In this article 01Games, not an agenda 02What we actually played 03Working distributed Anniversary call, at a glance 7 years of TrueSolv 2 countries, 1 call 3 game blocks, 0 slides About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
Hire a Salesforce Admin or Stay With a Partner?
At some point between 25 and 50 employees, almost every SaaS company asks the same question: do we hire a Salesforce admin, or do we keep working with a partner? It sounds like a resourcing question. It is actually a maturity question. And getting the answer wrong in either direction costs money, time, and six months of technical debt that lands on whoever comes next. Here is the framework for making that decision deliberately rather than reactively. Factor In-house admin Salesforce partner Hybrid model Primary work type Operational — reports, users, data cleanup, routine flows, responding to business requests daily Architectural — new objects, integrations, Agentforce, data model redesign, CRM migration Both simultaneously — admin handles daily operations; partner handles quarterly project work Team size signal 25–50+ employees generating 8–12+ consistent admin tickets per week filling 75%+ of a full-time role Under 25 employees, or project-based Salesforce needs that don’t fill a full-time role consistently 40–100 employees where daily operations and quarterly architectural projects co-exist without clean separation Org documentation Org is well-documented — new admin can understand decisions made before they arrived Org undocumented or partially documented — partner can produce documentation as a deliverable before the admin hire Documented enough for daily admin; partner handles architecture decisions that require deeper platform knowledge Business context value High — admin who knows the business deeply diagnoses problems faster and avoids well-intentioned changes that don’t match reality Lower — partner needs context per project and works better on scoped work where requirements can be specified upfront Admin provides business context for daily requests; partner applies platform depth to defined project scope Typical annual cost $80K–$120K salary + benefits + management overhead $28K–$44K for 4 substantial projects at 40 hours each at $175–$275/hr $55K–$80K admin salary + $15K–$25K annual retained partner — total often less than senior admin alone When this works best Stable org that needs consistent daily availability more than platform depth Orgs where Salesforce work is project-based and architectural depth matters more than business context Orgs where the types of work are genuinely different and the division of responsibility is explicitly defined The case for hiring in-house sooner An in-house Salesforce admin makes economic sense when the Salesforce work is primarily operational — the org is stable, well-documented, and requires ongoing maintenance rather than architectural change. The specific tasks that benefit from an in-house resource are report building, user management, data cleanup, routine flow modifications, and responding to user requests in real time. The value that an internal resource adds that a partner cannot replicate is business context at low latency. An in-house admin who has sat in two dozen pipeline reviews understands why a field exists, why a certain report is broken differently than it looks, and what the revenue team actually means when they say “the CRM is wrong.” The breakeven for an in-house hire typically occurs when the org is generating more than eight to twelve admin tickets per week with enough consistency that the work fills 75% or more of a full-time role. Below that threshold, the cost per ticket is lower with a partner. The case for staying with a partner longer A Salesforce partner makes economic sense when the Salesforce work is project-based and architectural: building new objects and relationships, configuring third-system integrations, deploying Agentforce or other AI capabilities, migrating from another CRM, or redesigning the revenue operations data model. These are not tasks that benefit from low-latency business context. They require Salesforce depth — knowledge of how the platform behaves at implementation boundaries, what breaks in governor limits, how the data model will perform at scale, and what the configuration choices made today will cost in flexibility six months later. A senior Salesforce consultant at a partner firm costs $175 to $275 per hour. Four substantial architectural projects per year at 40 hours each totals $28,000 to $44,000. A senior in-house admin costs $80,000 to $120,000 per year in salary plus benefits. For companies doing four projects per year with mostly operational maintenance in between, the partner model is often less expensive — even before accounting for the depth differential. The three mistakes most SaaS companies make Mistake 1: Hiring an admin to fix a problem that requires an architect The presenting symptom is “our Salesforce is broken.” The actual problem is that the data model does not reflect how the business works, the integrations are unreliable, or the objects were configured for a different business model than the current one. Hiring a mid-level admin to fix an architectural problem produces months of workarounds that make the underlying problem harder to fix later. Mistake 2: Paying an architect-level partner for admin tasks The reverse problem: a company stays with a sophisticated Salesforce partner after the org stabilises, paying project rates for report building, user management, and minor flow modifications that any mid-level admin could handle. This often happens because the decision to hire was never formally revisited. The partner was right for the implementation phase; staying with them indefinitely for operational maintenance is a default, not a decision. Mistake 3: Treating the decision as permanent The right answer at 30 employees is rarely the right answer at 80 employees. The maturity of the org, the complexity of the Salesforce environment, and the ratio of architectural to operational work all shift as the company grows. A decision made correctly at one stage needs to be revisited at the next one. Three diagnostic questions to answer before deciding Three diagnostic questions before making the decisionAnswer all three honestly — not aspirationally 1What is the primary type of Salesforce work needed in the next six months?New objects, integrations, Agentforce configuration, or data model changes = architectural work. Reports, users, data hygiene, flow tweaks = operational work. Be honest about which is primary, not which you aspire to be doing.→ Primarily architectural: partner. Primarily operational: in-house. Both significantly: hybrid. 2What is the current state of org documentation?An undocumented org transferred to a new in-house admin
Salesforce Data 360 MCP Server Is in Developer Preview
On May 26, Salesforce announced that the Data 360 MCP Server is now in Developer Preview. The idea is direct: every piece of data in your Salesforce Data Cloud is now reachable by any AI agent that speaks Model Context Protocol. Your CRM context, unified customer profiles, real-time data streams — accessible from Claude Code, Cursor, or any MCP-compatible agent tool without writing a custom API wrapper. Data 360 MCP Server — How Data Cloud Connects to AI Agents Salesforce Data Cloud • Unified customer profiles • Audience segments • Calculated insights • Data streams • Identity resolution exposes Data 360 MCP Server Developer Preview Trust Layer protected tool calls MCP-compatible AI agents Claude Code Cursor / Codex Agentforce Studio Custom MCP clients Any agent that speaks MCP No custom API wrapper required. Data arrives through the same trust layer as other Agentforce data access. What the Data 360 MCP Server actually exposes The server gives AI agents structured access to Data Cloud data — unified customer profiles, audience segments, data streams, calculated insights, and identity resolution outputs. These are the data objects that previously required SOQL-like queries against the Data Cloud query engine or custom API development to surface. Through the MCP interface, an agent can retrieve a unified customer profile by identity, query segment membership for a specific individual, pull calculated insight values for an account, or read real-time data stream events — using the same tool-call pattern it would use to interact with any other MCP server, without learning a proprietary API. The significance is in the combination. An agent building a renewal recommendation previously had access to Salesforce CRM data — the account record, the opportunity history, the activity log. What it did not have was the Data Cloud layer: the calculated health score from product usage, the segment membership that reflects behavioural patterns, the cross-channel identity resolution that unifies how the same customer appears across touchpoints. The Data 360 MCP Server adds that layer. Why this changes how agents reason The practical difference between an agent with CRM access and an agent with CRM plus Data Cloud access is the difference between structured records and contextualised customer intelligence. An agent reviewing a renewal opportunity can currently see: account name, ACV, contract end date, last activity log, open support tickets. With the Data 360 MCP Server, that same agent can also see: the customer’s health score calculated from product usage patterns, their segment membership indicating they are in a high-churn-risk cohort, and their identity resolution confirming that two separate records in the CRM are the same individual. Because the data arrives through the MCP interface with the same trust layer protections as other Agentforce data access, the agent’s data handling governance applies uniformly — no separate security configuration needed for the Data Cloud layer. What is available in Developer Preview vs. what is coming Capability Available in Developer Preview Expected at GA Unified customer profile retrieval ✓ Query by identity, return full profile with attributes — Audience segment membership ✓ Query segment membership for a specific individual or account — Calculated insights reads ✓ Return health scores, propensity scores per record — Identity resolution queries ✓ Cross-reference unified identity across touchpoints — Data stream reads ✓ Basic event stream data — subject to Data Cloud sync latency Real-time streaming subscriptions Write-back to Data Cloud ✗ Not yet available Agents will be able to update Data Cloud records based on reasoning output Complex data stream subscriptions ✗ Not yet available Subscribe to data stream events as part of agent trigger logic Production org access ✗ Developer Edition orgs with Data Cloud only Full production org access at GA Developer Preview gives access to the core unified profile retrieval, segment queries, and calculated insight reads. The key constraint is data freshness: Data Cloud data surfaces through the MCP Server with the same refresh latency as the underlying Data Cloud sync. For most use cases this is acceptable. For agents reasoning about real-time events, it is worth understanding the lag characteristics of your specific data streams before building workflows that depend on sub-second freshness. Developer Preview access path Data 360 MCP Server — Developer Preview Access Path4 steps 1Confirm your org has Data Cloud enabledDeveloper Edition orgs with Data Cloud access qualify for Developer Preview. If you do not have a Data Cloud-enabled org, spin up a Developer Edition at developer.salesforce.com — the fastest path to experimenting. 2Enable the Data 360 MCP Server in SetupOpen Setup → search for MCP Servers. The Data 360 MCP Server appears in the available server list for Developer Preview-enrolled orgs. Enable it and configure which agents have access to which data objects.Setup → MCP Servers → Data 360 MCP Server → Enable 3Connect an MCP-compatible clientClaude Code, Cursor, Agentforce Studio, or any MCP-compatible development environment can connect once the server is enabled. The server returns a tool manifest — no custom authentication code required beyond the standard MCP handshake. 4Test with a unified profile retrievalPull a known profile by ID, confirm the MCP Server returns the same data as the Data Cloud UI, and verify that segment membership and calculated insights are included in the response. This confirms the data path is working before building agent logic on top of it. Developer Preview is the right time to experiment, not the right time to build production workflows. Map your architecture, test your data access patterns, and identify what works before GA removes the preview caveats. The orgs that move through this now will deploy faster when GA lands. Data 360MCPData CloudSalesforce DevAgentforce Share: LinkedIn Twitter / X Copy link In this article 01What it exposes 02Why it changes agent reasoning 03Preview vs. GA capabilities 04Access path — 4 steps Developer Preview status Unified profilesQuery by identity — live Segment membershipPer individual — live Calculated insightsHealth scores — live Write-backExpected at GA Production orgsDev Edition only now Quick access path 1️⃣Enable Data Cloud in org 2️⃣Setup → MCP Servers → Enable 3️⃣Connect MCP