Salesforce Sandbox Types And How To Choose The Right One
Every Salesforce team has a story that starts with “it was just a small change in production”. A well chosen Salesforce sandbox is how that story never gets a sequel. Here is which sandbox type fits which job, how often to refresh it, and the one habit that gives you early access to every new release. What is a Salesforce sandbox A Salesforce sandbox is an isolated copy of your org’s metadata, and sometimes its data, used to build and test changes without touching production. Each sandbox has its own login, its own users and its own storage, so a broken flow or a bad data load stays inside the sandbox instead of reaching customers. Salesforce offers four types. They differ in how much data they hold, whether they copy data at all, and how often you can refresh them. The four Salesforce sandbox types compared TypeMetadataData copiedStorage limitRefreshBest for DeveloperYesNone200 MB1 dayBuilding flows and code Developer ProYesNone1 GB1 dayIntegrations, bigger test sets Partial CopyYesSample from atemplate5 GB5 daysUAT and training FullYesAll dataSame as production29 daysStaging and performance Values from Salesforce Help, checked October 7, 2026. Your edition decides how many you get. Professional Edition includes 10 Developer sandboxes. Enterprise Edition includes 25 Developer sandboxes and one Partial Copy. Unlimited and Performance include 100 Developer, five Developer Pro, one Partial Copy and one Full sandbox. Extra sandboxes can be bought, including Partial Copy and Full for Enterprise and above. Which sandbox for which job What do you need to test? A new flow, fieldor component An integration ora bigger test set UAT or training onrealistic records Staging, performanceor full data volume Developer200 MB, refresh daily Developer Pro1 GB, refresh daily Partial Copy5 GB sample, every 5 days FullAll data, every 29 days Start with what you need to test. Building a flow or a component. A Developer sandbox. It is fast to create, refreshes daily and keeps each person’s work separate Testing an integration. A Developer Pro or Partial Copy sandbox, so the integration has real looking records to read and write User training. A Partial Copy sandbox with a template that pulls realistic accounts and cases, so people practise on familiar data User acceptance testing before go live. A Partial Copy for most projects, or a Full sandbox when the change touches large data volumes Performance and load testing. A Full sandbox only, because nothing else holds production sized data Developersandbox UATPartial Copy StagingFull sandbox Productionyour live org BUILDTESTSIGN OFFDEPLOY Smaller teams can skip staging and deploy from UAT once sign off is complete. Smaller teams can skip staging and deploy from UAT once sign off is complete. How to create and refresh a sandbox In Setup, open Sandboxes and click New Sandbox Give it a short name, since it becomes part of every username, for example uat or dev1 Pick the type, and for Partial Copy choose or create a sandbox template that lists the objects to copy Optionally add an Apex class to run after copy, which can mask data or reset settings automatically Start the copy. Developer sandboxes are often ready within the hour, while a Full sandbox for a large org can take a day or more To refresh, click Refresh next to an existing sandbox once its interval has passed. A refresh replaces everything in the sandbox, so make sure nobody has unfinished work in it. After a copy or refresh, Salesforce adds the sandbox name to every username and adds .invalid to user email addresses, so test emails do not reach real people. Integration credentials and scheduled jobs usually need attention too, which is why the checklist below matters. Preview sandboxes and seasonal releases Salesforce ships three releases a year, and sandboxes upgrade before production. Sandboxes on preview instances get the new release several weeks early, while non preview sandboxes upgrade together with production. Whether a sandbox lands on a preview instance depends on its instance, and Salesforce publishes a sandbox preview guide before each release with the dates by which to refresh. Keeping at least one sandbox on preview gives your team a few weeks to test flows, integrations and release updates on the new version before users see it. That is the habit that turns every release weekend into a non event. Post refresh checklist After Every Sandbox Refresh Mask personal data testers do not need Point integrations at sandbox endpoints Reconnect integration users and credentials Check email deliverability settings Turn on only the scheduled jobs you test Restore tester email addresses truesolv.com, keep it next to your release plan Do this every time a sandbox is created or refreshed. Common questions How many sandboxes come with my edition? Professional Edition includes 10 Developer sandboxes. Enterprise adds one Partial Copy to 25 Developer sandboxes. Unlimited and Performance include 100 Developer, five Developer Pro, one Partial Copy and one Full sandbox. Does a Salesforce sandbox copy data? Developer and Developer Pro sandboxes copy metadata only. Partial Copy sandboxes copy a sample of data defined by a template, up to 5 GB, and Full sandboxes copy all data. How long does a Full sandbox refresh take? It depends on data volume and customisation. Smaller orgs often finish in a few hours, while large, complex orgs can take a day or more. After that, the next refresh is available after 29 days. Sandboxes are one half of a calm release, and the other half is a process your team follows every time. If you want help setting one up, our release management support covers it, and a Salesforce health check shows where your current setup carries risk. For a quick self review, try our 30 point health check checklist. A sandbox costs nothing compared to an evening spent rolling back a production change. Salesforce SandboxSalesforce AdminSalesforce DeveloperDevOpsTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What is a sandbox 02The four types compared 03Which sandbox for which job 04Create and refresh 05Preview sandboxes 06Post refresh checklist 07Common questions Refresh intervals Developer200
HubSpot Salesforce Integration Setup Guide For 2026
Marketing swears the lead was sent on Tuesday. Sales swears it never arrived. A clean HubSpot Salesforce integration ends that argument for good, because both teams finally look at the same record. Marketing keeps the tool it loves for campaigns and forms, sales keeps Salesforce for pipeline and forecasting, and the record in the middle stays the same on both sides. Here is how to set it up in an afternoon, and the five mistakes that quietly fill both systems with duplicates. If you would rather have it built and tested for you, that is exactly what our Salesforce integration services cover. What is a HubSpot Salesforce integration A HubSpot Salesforce integration is the native connector that keeps contacts, leads, companies, deals and activities in sync between both systems based on rules you define. You decide which records travel, which fields map to which, and which system wins when the same field is edited in both places. Sync runs on a regular cycle of roughly every 15 minutes, and many events such as form submissions and property changes trigger a faster update. HS HubSpot Marketing lives here ContactsCompaniesDealsActivities SF Salesforce Sales lives here Contacts and LeadsAccountsOpportunitiesTasks and Events CONTACTS AND LEADS COMPANIES AND ACCOUNTS DEALS AND OPPORTUNITIES ACTIVITIES, ONE WAY BY CHOICE One record, two systems Sync cycle roughly every 15 minutes Many events sync faster Activities flow one way only, to show that sync direction is a choice. This is different from a migration. If you are moving off HubSpot entirely, our HubSpot to Salesforce migration checklist is the better starting point. This guide is for teams that want to keep both systems and run them as one. What you need before you connect A Salesforce edition with API access, such as Enterprise or Unlimited, or Professional Edition, which the connector also supports. Group Edition is not supported A HubSpot Professional or Enterprise subscription on at least one hub, since the connector is not available on Starter plans A dedicated integration user in Salesforce with system administrator access and the permissions HubSpot asks for A written rule for field ownership, one line per important field saying which team and which system owns it That last point takes ten minutes and saves weeks. Most sync problems we fix are not technical. They come from two teams quietly assuming they each own the same field. SET IT UP IN AN AFTERNOON 1 Create a dedicated integration user System administrator access, never a real person’s login 2 Install the connector and set the inclusion list Only qualified contacts cross over to Salesforce 3 Map fields and pick who wins on conflicts Marketing fields flow out, sales fields flow back 4 Set up lead handoff rules Lifecycle stage, lead status, owner assignment in Salesforce 5 Test with 20 records, then turn on the full sync Check every record on both sides, field by field Five steps, one afternoon. Step 1. Create a dedicated integration user in Salesforce Create a new Salesforce user just for the connector, for example [email protected]. HubSpot requires the connecting user to be a system administrator, with API Enabled, View Setup and Configuration, Modify All on the objects you plan to sync, and a few metadata permissions for embedding HubSpot in Salesforce. Never connect with a real person’s login. When that person leaves or changes role, the sync breaks, and every record HubSpot creates looks like it was created by them. A dedicated user keeps the audit trail honest and survives team changes. 👍 Step 2. Install the connector and choose what syncs In HubSpot, open the App Marketplace, find the Salesforce integration and start the install. You will log in to Salesforce as the integration user, install the HubSpot package, and then walk through the setup wizard for contacts, companies, deals and activities. The most important choice on this screen is the inclusion list. It tells HubSpot which contacts are allowed to sync to Salesforce. Without one, every newsletter signup and every student downloading an ebook lands in Salesforce as a lead. With one, only contacts that meet your qualification rule, for example marketing qualified leads with a valid company email, cross over to sales. Step 3. Map fields and decide who wins on conflicts HubSpot gives every mapped field a sync rule. You can always use Salesforce, prefer Salesforce unless it is blank, keep the field two way, or not sync it at all. The goal is not to sync everything. It is to sync the fields each team actually needs and to make every conflict predictable. FIELD MAPPING AND CONFLICT RULES HubSpot propertySalesforce fieldSync directionWho wins on conflict EmailEmail↔ Two waySalesforce First and last nameFirst Name, Last Name↔ Two wayMost recent update Company nameCompany or Account Name↔ Two waySalesforce Phone numberPhone↔ Two waySalesforce unless blank Lifecycle stageCustom field→ To SalesforceHubSpot Lead statusLead Status← To HubSpotSalesforce Contact ownerOwner← To HubSpotSalesforce Original sourceCustom field→ To SalesforceHubSpot Eight common fields with direction and conflict rule. A simple pattern works for most teams. Marketing data such as source and lifecycle stage flows from HubSpot to Salesforce, and sales data such as owner and status flows back. Contact details stay two way, with Salesforce as the tie breaker. Step 4. Set up lead handoff rules This is where the lead fights actually end. Agree on one moment when a contact becomes sales’ responsibility, usually when the lifecycle stage reaches marketing qualified lead, and make that moment visible in both systems. Lifecycle stage in HubSpot decides when a contact joins the inclusion list and syncs to Salesforce Lead status in Salesforce shows what sales did with it, and syncs back so marketing can see the outcome Owner assignment happens in Salesforce, through assignment rules or a flow, so routing lives in one place When a rep marks a lead as unqualified, that status returns to HubSpot, and marketing can move the contact into a nurture program instead of sending it again next week. Step 5. Test with 20 records, then turn on
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