Lightning Record Form vs Edit Form vs View Form In LWC
LIGHTNING WEB COMPONENTS Lightning Record Form vs Edit Form vs View Form record-form Save Fastest record-edit-form Priority = High (default) Create case Most control record-view-form NameAcme renewal Amount$48,000 StageNegotiation Read only, your layout TRUESOLV.COM Three similar form cards, one of them fits your job. Salesforce gives you three base components that all show a record form. 🧩 Last updated October 2026 They look almost identical in the docs. Pick the wrong one and you spend a week fighting it instead of shipping. Here is the lightning record form compared with the record edit form and the record view form, with code, limits and the moment it is time to build your own. Key takeaways lightning-record-form is the fastest to build and the least flexible lightning-record-edit-form gives full control over editable fields and supports default values lightning-record-view-form is read only with a layout you design All three use Lightning Data Service, so field level security and sharing are handled for you Several objects, heavy conditional logic or custom validation are the signal to build a custom form What is lightning-record-form? lightning-record-form is a base Lightning Web Component that displays, edits or creates a record with very little code. You give it an object, an optional record ID and either a layout type or a list of fields, and it builds the form, the buttons and the save logic for you. Lightning record form vs edit form vs view form compared Capability record-form record-edit-form record-view-form Create records ✓ Yes ✓ Yes ✕ No Edit records ✓ Yes ✓ Yes ✕ No View records ✓ Yes ✕ No ✓ Yes Custom layout ✕ No, columns only ✓ Yes ✓ Yes Default or prefilled values ✕ No ✓ Yes Not applicable Custom submit logic Limited ✓ Yes, onsubmit Not applicable Best for Quick standard forms Custom create and edit Custom read only views Building a form the base components cannot handle? Book a call with our developers. We review your component or help you build a custom one. Talk to a developer → When should you use lightning-record-form? Use it when the form is standard and speed matters more than control. It supports three modes. Edit is the default when there is no record ID, view is the default when there is one, and readonly shows output fields without Save or Cancel buttons. <template> <lightning-record-form record-id={recordId} object-api-name="Account" fields={fields} columns="2" mode="edit" onsuccess={handleSuccess}> </lightning-record-form> </template> // accountForm.js import { LightningElement, api } from 'lwc'; import NAME from '@salesforce/schema/Account.Name'; import INDUSTRY from '@salesforce/schema/Account.Industry'; export default class AccountForm extends LightningElement { @api recordId; fields = [NAME, INDUSTRY]; handleSuccess() { /* show a toast or navigate */ } } Use either fields or layout-type, not both. Compact layouts cannot be used to create records. It stops working when you need to prefill values, control the layout beyond columns, or change what happens on submit in a meaningful way. It also does not support every standard object, so check the component reference for the one you use. When should you use lightning-record-edit-form? Use it when you need control over editable fields. You place each lightning-input-field yourself, set default values with the value attribute and intercept the submit event to adjust fields before saving. <template> <lightning-record-edit-form object-api-name="Case" onsubmit={handleSubmit}> <lightning-messages></lightning-messages> <lightning-input-field field-name="Subject"></lightning-input-field> <lightning-input-field field-name="Priority" value="High"></lightning-input-field> <lightning-button type="submit" label="Create case"></lightning-button> </lightning-record-edit-form> </template> handleSubmit(event) { event.preventDefault(); const fields = event.detail.fields; fields.Origin = 'Web'; this.template.querySelector('lightning-record-edit-form').submit(fields); } For a step by step walkthrough of changing values before save, see our guide on how to modify fields onsubmit in lightning record edit form. When should you use lightning-record-view-form? Use it when you need a read only view with your own layout, for example a summary card that mixes fields from one record with custom styling. <template> <lightning-record-view-form record-id={recordId} object-api-name="Opportunity"> <div class="slds-grid slds-gutters"> <div class="slds-col"><lightning-output-field field-name="Name"></lightning-output-field></div> <div class="slds-col"><lightning-output-field field-name="Amount"></lightning-output-field></div> <div class="slds-col"><lightning-output-field field-name="StageName"></lightning-output-field></div> </div> </lightning-record-view-form> </template> When should you build a custom form instead? More than one object in the form? YES Custom formLDS wire adapters or Apex NO Will users edit or create? READ ONLY Need your own layout? YESrecord-view-form NOrecord-formmode readonly EDIT OR CREATE Defaults, layout or submit logic? YESrecord-edit-form NOrecord-form All three base components enforce field level security and sharing through Lightning Data Service Which component should I use? Start at the top. Build your own when the form outgrows a single record. Typical signals are several objects in one form, complex conditional fields, related lists inside the form or validation that depends on data elsewhere. Use the Lightning Data Service wire adapters such as getRecord and updateRecord, or call Apex when you need transactions across objects. If you need something more involved, our custom Lightning Web Component development team builds and reviews these regularly. For the adoption side, see our guide on LWC best practices that get components used, and for simple screens that need no code at all, our Flow guide covers screen flows. What are the common mistakes? Mixing fields and layout-typeIn lightning-record-form this makes field order unpredictable Assuming field level security is optionalThe components respect it, so a field may simply not render for some users Hardcoding field API names as stringsImport them from @salesforce/schema instead. Strings break silently when a field is renamed No error handlingWithout lightning-messages or an onerror handler, users see nothing when a save fails Common questions What is the difference between lightning-record-form and lightning-record-edit-form? lightning-record-form builds the whole form for you from a layout or a field list, with built in buttons and modes. lightning-record-edit-form lets you place each input field yourself, set default values and change data before submit. Use the first for speed and the second for control. Can lightning-record-form prefill values? No. lightning-record-form does not support prepopulating field values when the form loads. If you need default values, use lightning-record-edit-form and set the value attribute on each lightning-input-field, or adjust the fields in the onsubmit handler before saving. Does lightning-record-form respect field level security? Yes. All three components use Lightning Data Service, which enforces field level security and sharing automatically. Users only see
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