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
HubSpot to Salesforce Migration, What to Prepare First
Most rocky HubSpot to Salesforce migrations fail on the field mapping nobody planned for, not on the data transfer itself. A HubSpot to Salesforce migration typically takes four to eight weeks for a straightforward setup, longer if the org carries years of custom properties and workflow automation. TrueSolv’s own migrations tend to land near that low end. A Series A SaaS company with 25 users moved over in four weeks with zero data loss and pipeline visibility up 40 percent afterward. What decides which end of that range a project lands on is preparation, not the transfer itself. HUBSPOT TO SALESFORCE / MIGRATION PATH HubSpot 1 Audit 2 Map fields 3 Dedupe 4 Sandbox test 5 Phased go live Salesforce 4 TO 8 WEEKS TYPICAL A 25-user Series A org moved in 4 weeks, zero data loss, pipeline visibility up 40%. Five checkpoints between HubSpot and a Salesforce org that’s actually ready — audit, map, dedupe, test, then go live. Audit the HubSpot data before anything moves Pull a full inventory of every custom property, workflow, and integration currently live in HubSpot. Flag which properties are actually in use versus abandoned years ago and never cleaned up. Check for duplicate contacts and companies that have built up over time. Note every HubSpot workflow that touches an external system, like billing or marketing automation, since each one needs a Salesforce equivalent before cutover. Map fields and objects on purpose, not by matching names HubSpot’s Contacts, Companies, and Deals don’t sit one to one on Salesforce’s Leads, Contacts, Accounts, and Opportunities, and deal stages rarely line up cleanly between the two platforms. A field like Lifecycle Stage in HubSpot might need to split across two or three Salesforce fields depending on how sales actually uses it day to day. This is the step most rushed migrations skip, and it’s where the rocky ones go wrong. Not in the data transfer itself, in the decisions about where each piece of data is supposed to live once it arrives. Deduplicate and clean up before the move, not after Migrating duplicates into Salesforce just starts the new CRM with the same mess under a new name. Run matching rules on the HubSpot export before load, email domain plus company name catches most of it, with phone number normalization for the rest. Decide on one source of truth for any field where HubSpot and another connected system disagree, and archive records that haven’t been touched in years instead of migrating everything on principle. Test the whole thing in a sandbox before it’s real Load a representative sample, or the full dataset, into a Salesforce sandbox first. Have the sales team run their actual daily workflow there, creating a deal, logging a call, pulling a report, before anyone touches production. Confirm that automation like assignment rules and email alerts fires correctly on migrated records. Mapping errors caught here cost nothing. The same errors found in production cost trust, and sometimes a deal. A phased go-live that doesn’t stop a deal mid-conversation 📦Move closed and historical data first, since nobody is actively working it ⏱Run HubSpot and Salesforce in parallel for open deals during a short transition window 🗓Cut active pipeline over in one scheduled move, often a weekend, so no rep loses a deal mid-conversation 🔒Keep HubSpot in read-only access for a defined period after cutover, in case something was missed 📢Tell the sales team the exact cutover time, so nobody logs a deal into the old system out of habit Four weeks is realistic. Eight is normal. Both numbers depend almost entirely on how much of this happens before the first record actually moves, not on how fast the transfer itself can run. Book a free migration consultation through our contact form, and follow TrueSolv on LinkedIn for more Salesforce admin and developer notes. Salesforce MigrationHubSpotCRM MigrationSalesforce ConsultingTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Audit the HubSpot data 02Map fields on purpose 03Deduplicate before the move 04Test in a sandbox 05A phased go-live 5 checkpoints 1Audit 2Map fields 3Dedupe 4Sandbox test 5Phased go live Planning a HubSpot → Salesforce move? Book a free consultation to scope the timeline before you commit to one. Book a consultation → About the Author AS Anastasia SokolovaSalesforce Developer 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
Apex Unit Test Best Practices Beyond the Coverage Number
Plenty of orgs hit the 75 percent coverage requirement with tests that check nothing real at all. Coverage counts which lines of code ran during a test, not whether the test verified anything meaningful. A test that inserts a record, calls a method, and confirms only that no exception was thrown will happily push coverage past 75 percent while catching zero actual regressions. Real Apex unit test best practices start from a different question: whether the test would fail the moment the underlying logic breaks, not whether it satisfies a percentage. APEX TESTING / CI PIPELINE 75% Coverage number alone Real assertions Bulk data, 200+ Mocked callouts CI gate Deploy What actually gates the merge Assertions tied to business outcome, not just the absence of an error 200+ record bulk test on every method that touches DML or SOQL External callouts mocked, never live inside a test context From a 75% coverage number to a CI gate that actually stops a broken assumption from shipping. The gap between passing and protecting A weak test looks productive. It compiles, it runs, it shows green in the deployment log, and the coverage number goes up. What it usually skips is any assertion tied to business outcome. It checks that a record exists, not that a field landed on the value the logic was supposed to produce. Six months later, someone changes a trigger, every existing test still passes, and the bug ships anyway — because nothing in the suite was actually watching for it. Assert patterns that actually catch something A test worth keeping asserts on the specific outcome the code is supposed to produce, not just on the absence of an error. That means asserting the field value that should have changed, the record count that should have resulted, or the exception that should have been thrown on a bad input. Here is a pair of tests for a trigger that updates a custom forecast category once an opportunity crosses an amount threshold. @isTest private class OpportunityRoundingTest { @isTest static void updatesForecastWhenAmountChanges() { Account acc = new Account(Name = ‘Test Account’); insert acc; Opportunity opp = new Opportunity( Name = ‘Renewal Deal’, AccountId = acc.Id, StageName = ‘Prospecting’, CloseDate = Date.today().addDays(30), Amount = 10000 ); insert opp; Test.startTest(); opp.Amount = 25000; update opp; Test.stopTest(); Opportunity updated = [ SELECT Forecast_Category_Custom__c, Amount FROM Opportunity WHERE Id = :opp.Id ]; Assert.areEqual(25000, updated.Amount, ‘Amount should reflect the update’); Assert.areEqual(‘Best Case’, updated.Forecast_Category_Custom__c, ‘Forecast category should move once the deal crosses the threshold’); } @isTest static void doesNotDefaultAmountWhenLeftBlank() { Account acc = new Account(Name = ‘Test Account 2’); insert acc; Opportunity opp = new Opportunity( Name = ‘Early Deal’, AccountId = acc.Id, StageName = ‘Prospecting’, CloseDate = Date.today().addDays(60) ); Test.startTest(); insert opp; Test.stopTest(); Opportunity result = [SELECT Amount FROM Opportunity WHERE Id = :opp.Id]; Assert.isNull(result.Amount, ‘A deal with no amount should stay null, not default to zero’); } } Both tests assert on the actual business rule — the forecast threshold and the null default — not just on the record existing. Bulk data catches what a single record never will A test that inserts one record will pass even when the underlying code runs a query or a DML statement inside a loop, because one iteration never comes close to a governor limit. Two hundred records will. Building bulk data into a test is the difference between finding that bug in a sandbox and finding it in production during a mass import. @isTest static void handlesBulkInsertWithoutHittingLimits() { List<Account> accounts = new List<Account>(); for (Integer i = 0; i < 200; i++) { accounts.add(new Account(Name = ‘Bulk Account ‘ + i)); } Test.startTest(); insert accounts; Test.stopTest(); List<Account> inserted = [ SELECT Id FROM Account WHERE Name LIKE ‘Bulk Account%’ ]; Assert.areEqual(200, inserted.size(), ‘All 200 accounts should insert without hitting a governor limit’); } Mocking callouts without touching a real endpoint Any test that reaches out to a real external system is slow, flaky, and eventually blocked by Salesforce itself, since live callouts aren’t allowed inside a test context. The fix is the HttpCalloutMock interface, which lets a test hand back a fake response and check that the code parses and handles it correctly — success and failure alike. @isTest private class ShippingRateMockTest { private class SuccessMock implements HttpCalloutMock { public HttpResponse respond(HttpRequest req) { HttpResponse res = new HttpResponse(); res.setStatusCode(200); res.setBody(‘{“rate”: 14.50, “carrier”: “Standard”}’); return res; } } @isTest static void parsesRateFromSuccessfulCallout() { Test.setMock(HttpCalloutMock.class, new SuccessMock()); Test.startTest(); ShippingRate rate = ShippingService.getRate(‘90210’); Test.stopTest(); Assert.areEqual(14.50, rate.amount, ‘Rate should match the mocked response body’); Assert.areEqual(‘Standard’, rate.carrier, ‘Carrier should be parsed from the JSON response’); } } A second mock returning a 500 status covers the failure path that actually breaks integrations in production. Wiring tests into CI before anything merges None of this holds up if tests only run when someone remembers to run them by hand. Wiring Apex tests into a CI pipeline means every pull request triggers a deploy to a scratch org or sandbox followed by a full test run, and a merge simply can’t happen if a test fails or coverage drops below the threshold. name: apex-tests on: [pull_request] jobs: test: runs-on: ubuntu-latest steps: – uses: actions/checkout@v4 – run: sf org login sfdx-url –sfdx-url-file authFile.txt –alias ci-org – run: sf project deploy start –target-org ci-org – run: sf apex run test –target-org ci-org –code-coverage –result-format human –wait 20 A coverage number without CI is a report nobody reads until deploy day. A coverage number wired into every pull request is a gate that actually stops a broken assumption from shipping. Send your test suite our way through the contact form for a custom development and code review pass, and follow TrueSolv on LinkedIn for more Apex notes. Apex CodeSalesforce DevCRM DevelopmentSalesforce TestingTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Passing vs protecting 02Assert patterns that work 03Bulk data (200+ records) 04Mocking callouts 05Wiring into CI What actually gates the merge Assertions on business outcomes — not just “no exception” Bulk data
Salesforce Flow Best Practices Before Automation Breaks
Flow runs fine for months, then fails at the worst possible moment — usually right before a reporting deadline. Following Salesforce Flow best practices means catching the handful of patterns that quietly turn a working automation into a liability, well before that automation is the thing standing between your team and a Monday morning report. Most flows don’t fail because Salesforce changed something. They fail because small shortcuts from setup day were never cleaned up. That’s the part admins tend to miss. A flow that ran cleanly in testing keeps running cleanly for weeks, sometimes months, because the exact conditions that break it haven’t happened yet. Then record volume spikes, or someone adds a second automation on the same object, and the whole thing falls over in front of the one person checking the pipeline report an hour before a leadership meeting. SALESFORCE FLOW / RISK PATH DML in a loop No fault path Hardcoded Id Duplicate trigger No test coverage Audited & stable Quarterly audit checklist Flow Trigger Explorer reviewed for every multi-automation object Every flow has a fault path connected, none left as a dead end Error emails route to an active admin, not a former employee Five risk points on the path from a working flow to an audited, stable one. Five signs a Flow is overdue for a look 1DML or SOQL inside a loopUpdating or querying records one at a time inside a loop is the fastest way to hit governor limits once record volume grows past what it looked like in a sandbox. 2Missing fault pathsA flow with no error handling doesn’t fail quietly. It fails loudly, usually by leaving a record half updated with no trace of what went wrong. 3Hardcoded record IDsAn ID copied in during testing works fine until the flow moves to a new org or the referenced record gets deleted, then it breaks with no obvious cause. 4Duplicate triggers on the same objectTwo flows, or a flow and an Apex trigger, both firing on the same object update can create conflicting logic, race conditions, or updates that quietly overwrite each other. 5Zero test coverage on related ApexAny Apex tied to the automation with no meaningful test coverage is a change nobody can safely make without breaking something else first. How to actually find these before they find you Flow Trigger Explorer, inside Setup, shows every flow and trigger firing on a given object in one place, including the order they run in. That order is where duplicate or conflicting automation usually hides, since two flows updating the same field rarely announce themselves until you see them listed side by side. Debug logs fill in the rest. Turning on debug logs for a user who regularly triggers the flow in question, then reading through what actually fired during a normal transaction, tends to surface loop-heavy DML and missing fault paths faster than reading the flow canvas alone. A flow can look fine on screen and still be doing something expensive every time it runs. A checklist worth running on a schedule Salesforce Flow audit checklistRun this on a schedule — quarterly is enough for most orgs Pull up Flow Trigger Explorer for every object with more than one active automation Confirm every flow has a fault path connected, not left as a dead end Search flow elements for hardcoded IDs left over from testing Check for DML or SOQL sitting inside a loop element Confirm Apex tied to automation has real test coverage, not just enough to pass deployment Make sure flow error emails route to an active admin, not someone who left the company last year None of this takes long to check. It takes almost no time at all to skip — which is exactly how an automation that ran fine for a year ends up failing the week a board report is due. If a full pass through your org sounds like more time than your week has, send it our way through the contact form. A Salesforce Health Check covers Flow and automation health as one of six audit areas, alongside security, data quality, and performance, so you get the full picture instead of just the flows that happened to break first. Salesforce FlowSalesforce AdminAutomationSalesforce Health CheckCRM Best Practices Share: LinkedIn Twitter / X Copy link In this article 015 signs a flow needs a look 02How to find problems first 03Audit checklist 5 flow risk patterns DML or SOQL inside a loop Missing fault paths Hardcoded record IDs Duplicate triggers on same object Zero Apex test coverage Where to look in Setup 🔍Flow Trigger Explorer 🪲Debug logs — live user 📋6-item audit checklist About the Author DK Dilyara KolesnikovaSalesforce Developer & Technical Writer at TrueSolv
Salesforce Field History AI Readiness
An Agentforce agent grounded in your Salesforce data will give answers based on whatever your records contain. If a field was overwritten six weeks ago by a bad import, the agent does not know that. If a contact’s status was manually edited three times without a logged reason, the agent treats the current value as correct. Your AI is only as trustworthy as your data history. True Field History is how you know what your data actually is. Opportunity Field History — What the Agent Sees vs. What Actually Happened What the Agentforce agent sees CurrentOpportunity StageProposal SentLast changed: 18 days ago CurrentAmount$45,000No recent changes noted CurrentClose DateAug 31, 2026Set at opportunity creation Agent readAgent assessmentDeal progressing — moderate paceNo risk flags surfaced What the field history actually shows 8 days agoStage was moved backVerbal Commit → Proposal SentNo reason logged. Changed by rep. 12 days agoAmount was reduced$78,000 → $45,000No reason logged. Changed by rep. 15 days agoLast activity loggedEmail sent — no responseNo follow-up logged since RealityActual risk profileStage regression + amount cut + 15 days darkSignificant risk. Agent had no visibility into this. The agent saw three fields and assessed normal deal progression with no risk flags. The field history shows a stage regression, a significant amount reduction, and 15 days of no contact — all without logged reasons. The AI data trust problem most deployments skip When organisations deploy Agentforce, the configuration conversation focuses on agent topics, knowledge base grounding, escalation logic, and Trust Layer guardrails. These are the right things to configure. What most organisations underestimate is the quality and reliability of the data the agent is reasoning from. An Agentforce agent does not evaluate data quality. It does not flag uncertainty about data recency. It does not know that the contract end date on an account was changed two months ago from a correct value to an incorrect one during a data cleanup task that went wrong. It presents what it finds and reasons from it as if it is accurate. This is not an agent problem. It is a data problem that the agent makes visible in a new way: not as a messy CRM that someone will clean up eventually, but as an AI system that answers incorrectly right now. Three scenarios where field history and Agentforce intersect 💚Customer Health ScoringAgent reasons from activity fields Specific vulnerabilityLast Contacted fields edited by reps to satisfy KPIs or look better in pipeline reviews. Agent reads the edited date, computes recency, produces a health score built on fabricated history.→ Field history reveals: accounts where Last Contacted was manually edited without a corresponding logged activity. 📋Contract Renewal AgentAgent triggers from contract dates Specific vulnerabilityInformal renegotiations that change terms verbally but never update the contract end date in Salesforce. Agent fires renewal outreach at the original date for a contract already renegotiated.→ Field history reveals: contract end dates not updated despite account activity suggesting renegotiation. 📊Pipeline & Deal RiskAgent reasons from stage and amount Specific vulnerabilityStage regressions and Amount reductions with no logged reason. Agent sees current stage and amount, assesses normal progression, misses the risk pattern entirely visible only in the change log.→ Field history reveals: stage regressions, amount cuts preceding a stage change, patterns inconsistent with deal movement. Scenario 1: Customer health scoring agents A customer health scoring agent ingests activity data — last contacted date, meeting count, support ticket volume, product usage signals — and produces a health score or churn risk flag that surfaces in account management workflows. The specific vulnerability is in manually managed fields: Last Contacted date fields that can be edited by reps. True Field History exposes this pattern before the agent is grounded in it. Scenario 2: Contract renewal agents A renewal agent monitors contract end dates and triggers outreach at defined thresholds before expiration. The common failure mode is informal renegotiations where the AE updates pricing in a side document, verbally confirms new terms, but never updates the contract end date in Salesforce. The renewal agent fires at the original date, triggering outreach for a contract that was already renegotiated. A renewal audit using field history takes 20 minutes and catches this problem before the agent encounters it. Scenario 3: Pipeline and deal risk agents An agent surfacing deal risk and stage progression analysis needs Opportunity Stage and Amount fields to reflect current deal reality. These are two of the most commonly manipulated fields in Salesforce. An agent reviewing an Opportunity that shows Stage: Proposal Sent, Amount: $45,000, Last Stage Change: 3 weeks ago will flag that deal as progressing normally. If the actual history shows the Stage was at Verbal Commit 10 days ago before being moved back without a logged reason, the risk profile is completely different — and the agent has no way to know. The broader argument for a pre-AI field history audit The three scenarios above share a structural pattern: a field value that looks correct in the current record is unreliable because of how it arrived at the current value — overwritten, manually edited without reason, or changed in a way that is inconsistent with the surrounding activity log. None of these problems are visible by looking at the current record. All of them are visible in the field change history. A pre-AI deployment field history audit identifies which fields the agent will reason from, which of those fields have unreliable change histories, and what data quality remediation is needed before the agent is grounded in those fields. For a focused Agentforce deployment — an agent reasoning from a defined set of Account and Opportunity fields — the relevant field history can be reviewed and flagged in days. Pre-AI Deployment Field History AuditRun this before grounding any Agentforce agent in Salesforce data Map what the agent will reason from List the specific fields the agent will access for each topicEvery field in the agent’s grounding scope is a data quality risk. Make the list explicit before the audit — not all
Hire a Salesforce Admin or Stay With a Partner?
At some point between 25 and 50 employees, almost every SaaS company asks the same question: do we hire a Salesforce admin, or do we keep working with a partner? It sounds like a resourcing question. It is actually a maturity question. And getting the answer wrong in either direction costs money, time, and six months of technical debt that lands on whoever comes next. Here is the framework for making that decision deliberately rather than reactively. Factor In-house admin Salesforce partner Hybrid model Primary work type Operational — reports, users, data cleanup, routine flows, responding to business requests daily Architectural — new objects, integrations, Agentforce, data model redesign, CRM migration Both simultaneously — admin handles daily operations; partner handles quarterly project work Team size signal 25–50+ employees generating 8–12+ consistent admin tickets per week filling 75%+ of a full-time role Under 25 employees, or project-based Salesforce needs that don’t fill a full-time role consistently 40–100 employees where daily operations and quarterly architectural projects co-exist without clean separation Org documentation Org is well-documented — new admin can understand decisions made before they arrived Org undocumented or partially documented — partner can produce documentation as a deliverable before the admin hire Documented enough for daily admin; partner handles architecture decisions that require deeper platform knowledge Business context value High — admin who knows the business deeply diagnoses problems faster and avoids well-intentioned changes that don’t match reality Lower — partner needs context per project and works better on scoped work where requirements can be specified upfront Admin provides business context for daily requests; partner applies platform depth to defined project scope Typical annual cost $80K–$120K salary + benefits + management overhead $28K–$44K for 4 substantial projects at 40 hours each at $175–$275/hr $55K–$80K admin salary + $15K–$25K annual retained partner — total often less than senior admin alone When this works best Stable org that needs consistent daily availability more than platform depth Orgs where Salesforce work is project-based and architectural depth matters more than business context Orgs where the types of work are genuinely different and the division of responsibility is explicitly defined The case for hiring in-house sooner An in-house Salesforce admin makes economic sense when the Salesforce work is primarily operational — the org is stable, well-documented, and requires ongoing maintenance rather than architectural change. The specific tasks that benefit from an in-house resource are report building, user management, data cleanup, routine flow modifications, and responding to user requests in real time. The value that an internal resource adds that a partner cannot replicate is business context at low latency. An in-house admin who has sat in two dozen pipeline reviews understands why a field exists, why a certain report is broken differently than it looks, and what the revenue team actually means when they say “the CRM is wrong.” The breakeven for an in-house hire typically occurs when the org is generating more than eight to twelve admin tickets per week with enough consistency that the work fills 75% or more of a full-time role. Below that threshold, the cost per ticket is lower with a partner. The case for staying with a partner longer A Salesforce partner makes economic sense when the Salesforce work is project-based and architectural: building new objects and relationships, configuring third-system integrations, deploying Agentforce or other AI capabilities, migrating from another CRM, or redesigning the revenue operations data model. These are not tasks that benefit from low-latency business context. They require Salesforce depth — knowledge of how the platform behaves at implementation boundaries, what breaks in governor limits, how the data model will perform at scale, and what the configuration choices made today will cost in flexibility six months later. A senior Salesforce consultant at a partner firm costs $175 to $275 per hour. Four substantial architectural projects per year at 40 hours each totals $28,000 to $44,000. A senior in-house admin costs $80,000 to $120,000 per year in salary plus benefits. For companies doing four projects per year with mostly operational maintenance in between, the partner model is often less expensive — even before accounting for the depth differential. The three mistakes most SaaS companies make Mistake 1: Hiring an admin to fix a problem that requires an architect The presenting symptom is “our Salesforce is broken.” The actual problem is that the data model does not reflect how the business works, the integrations are unreliable, or the objects were configured for a different business model than the current one. Hiring a mid-level admin to fix an architectural problem produces months of workarounds that make the underlying problem harder to fix later. Mistake 2: Paying an architect-level partner for admin tasks The reverse problem: a company stays with a sophisticated Salesforce partner after the org stabilises, paying project rates for report building, user management, and minor flow modifications that any mid-level admin could handle. This often happens because the decision to hire was never formally revisited. The partner was right for the implementation phase; staying with them indefinitely for operational maintenance is a default, not a decision. Mistake 3: Treating the decision as permanent The right answer at 30 employees is rarely the right answer at 80 employees. The maturity of the org, the complexity of the Salesforce environment, and the ratio of architectural to operational work all shift as the company grows. A decision made correctly at one stage needs to be revisited at the next one. Three diagnostic questions to answer before deciding Three diagnostic questions before making the decisionAnswer all three honestly — not aspirationally 1What is the primary type of Salesforce work needed in the next six months?New objects, integrations, Agentforce configuration, or data model changes = architectural work. Reports, users, data hygiene, flow tweaks = operational work. Be honest about which is primary, not which you aspire to be doing.→ Primarily architectural: partner. Primarily operational: in-house. Both significantly: hybrid. 2What is the current state of org documentation?An undocumented org transferred to a new in-house admin
Salesforce Field Level Security Summer 26
Any Salesforce admin who has ever done a field-level security audit knows the process: open a profile, navigate to object settings, find the field, note the access, repeat for every other profile, then repeat for every permission set. It is tedious, error-prone, and nobody does it as often as they should. Summer ’26 adds a Field Access tab directly to Object Manager that shows the full picture in one place. What the Field Access tab shows At the bottom of each object in Object Manager, a new Field Access tab lists every field on the object alongside a consolidated view of exactly how access is granted — across all profiles and permission sets — in a single interface. Previously, getting this view required navigating each profile individually, cross-referencing permission sets separately, and building a mental or spreadsheet-based picture of who can see and edit which field. For a mid-sized org with 20 profiles and 40 permission sets, that process takes hours and is almost guaranteed to miss something. The Field Access tab shows it in one view. One object, every field, all access configurations visible simultaneously. ⚡ Salesforce Setup → Object Manager → Opportunity → Field Access Opportunity Standard Object Details Fields & Relationships Page Layouts Validation Rules Field Access New All profiles and permission sets — one view Field Label Profile / Permission Set Access Granted Via Amount ✓ Read / Edit Sales Rep, Sales Manager Profile: Sales Rep · Profile: Sales Manager Annual Contract Value ✓ Read / Edit Finance, Admin📖 Read only Sales Rep Perm Set: Finance View · Profile: Admin Internal Deal Notes ✓ Read / Edit Sales Manager, Admin✗ No access Sales Rep, Support Perm Set: Manager Access · Profile: Admin Stripe Subscription ID 📖 Read only Finance, Admin✗ No access Sales Rep, Support, CS Perm Set: Finance View · Profile: Admin Read-only in Summer ’26. Edit permissions via Profile or Permission Set settings. Why this matters more than it sounds Field-level security is one of the most common gaps in Salesforce org audits. Orgs grow, permission sets multiply, profiles get copied from other profiles, and nobody has a clear picture of who can read or edit which field. Compliance audits, security reviews, and new admin onboarding all require this visibility — and getting it has always required more effort than it should. The Field Access tab does not change permissions. It makes the existing permissions visible and auditable at a glance. That distinction matters for compliance contexts specifically: the audit requirement is often to demonstrate that someone reviewed field access, not that they changed it. Summer ’26 makes that review faster, more reliable, and easier to document. Three situations where this saves significant time ✗ Before Summer ’26 1Open Profile 1 → Object Settings → navigate to field → note access level~3 min per profile 2Repeat for all 20 profiles. Build a spreadsheet.~60 minutes 3Open each permission set and check the same field. Add to spreadsheet.~30 min for 40 perm sets 4Cross-reference manually. Identify gaps. Probably miss one.~20 minutes 2+ hours. Error-prone. Often skipped. ✓ With Summer ’26 Field Access tab 1Open Object Manager → select object → click Field Access tab~30 seconds 2All fields listed. All profiles and permission sets in a single view.Immediate 3Search or scroll to the specific field. Access visible at a glance.~2 minutes 4Screenshot or export for the audit documentation. Done.~5 minutes total Under 10 minutes. Reliable. Auditable. Where the Field Access Tab Saves Significant Time 🔒Before a new team accesses sensitive account dataWhen a new department or external partner is being onboarded to Salesforce, reviewing field-level security on Account, Contact, or Opportunity objects is a required step. The Field Access tab makes this a 10-minute review instead of an afternoon, and makes the outcome documentable.Time saving: ~2 hours → ~10 minutes per object reviewed 📋GDPR and HIPAA-adjacent field visibility auditsDemonstrating controlled access to specific fields — email addresses, phone numbers, health-related custom fields — requires showing who has access and how it is granted. The Field Access tab produces that view without a manual cross-referencing exercise, making it audit-ready by design.Compliance requirement: access visibility is demonstrable in one screenshot 🔍Debugging a field not visible for a specific userA rep reports a field is missing from their record page. Previously: check profile → check permission sets → check page layout. With Field Access tab: search for the field, see all access configurations simultaneously, identify the gap in under 2 minutes.Debugging time: ~20 minutes → ~2 minutes What it does not do yet The Field Access tab is read-only in the initial Summer ’26 implementation. You can view field access across all profiles and permission sets, but you cannot edit permissions from this interface. Changes still require navigating to the profile or permission set and making edits there. Worth watching: The ability to edit permissions from the same view — which would make it genuinely powerful — is the likely Winter ’27 addition. The visibility improvement is real and significant now. Editing from the same surface is the logical next step. Field-level security has always been one of the hardest things to audit in a Salesforce org. Summer ’26 does not solve the permissions complexity — it makes it visible. That is the starting point for everything else. Salesforce Admin Summer ’26 Field Level Security Object Manager Salesforce Release Share: LinkedIn Twitter / X Copy link In this article 01What the Field Access tab shows 02Why this matters 03Three time-saving scenarios 04What it doesn’t do yet Field Access tab — quick facts 🆕Where: Object Manager → any object → Field Access tab (last tab) 📊Shows: All profiles and permission sets in one consolidated view 🚫Doesn’t do: Editing — read-only in Summer ’26 📅Available: Summer ’26 GA — sandboxes from ~May 9 Use this tab when… 🔒Onboarding a new team to sensitive data 📋Running a GDPR / HIPAA audit 🔍Debugging a missing field About the Author DK Dilyara Kolesnikova Salesforce Developer & Technical Writer at TrueSolv
How to Use Agentforce to Automate SaaS Renewal Protection
Most SaaS companies do not lose renewals because the product failed. They lose them because nobody noticed the signals in time — usage dropping, a key contact going quiet, a support ticket that never fully resolved. By the time the CS team follows up, the customer has already decided. Agentforce inside Salesforce changes this from a reactive problem to a proactive workflow. Proactive CS motions outperform reactive ones at every stage The signal arrives weeks before the decision. The question is whether your system is watching for it. 67%Higher renewal rate when CS reaches out proactively vs. waiting for the customer to initiate 14 daysAverage time between detectable usage decline and churn — the intervention window most teams miss 80+Accounts per CS rep at a 30-person SaaS company — volume that makes manual monitoring impossible SaaS industry renewal benchmarks. Specific percentages vary by product category, deal size, and CS team structure. Part 1: Why SaaS renewal churn is a data problem, not a people problem The CS team at a 30-person SaaS company is usually one or two people managing 80 or more accounts. They are good at their jobs. They are not able to proactively review every account monthly while simultaneously handling onboarding calls, support escalations, and renewal negotiations. The signals that predict churn are not hidden. Usage declining by 40 percent over two weeks is visible in your product analytics. A key contact going silent for 45 days is visible in your activity log. A support ticket that stayed open for 12 days before resolution is visible in your case management. The problem is that nobody is watching all of these signals simultaneously across 80 accounts. Agentforce agents can. They run continuously against your Salesforce data, evaluate conditions against defined thresholds, and take action when those thresholds are crossed — without requiring a CS rep to remember to check. The data advantage compounds over time. As agents surface patterns — which usage drops correlate with churn, which onboarding milestones predict expansion — your renewal playbook becomes more precise with each cycle. Part 2: What an Agentforce renewal agent actually does An Agentforce renewal agent is an automated system that monitors account health signals, evaluates them against configured thresholds, and takes a defined action when a threshold is crossed — without human initiation. Agentforce Renewal Workflow — How a churn signal becomes a CS action Data Signals • Usage −40% / 14d • No contact 45+ days • Open support tickets • Contract 60d away Monitors Agentforce Renewal Agent Evaluates all signals simultaneously • 24/7 Triggers Autonomous Actions Priority CS task assigned to account owner Account summary usage + contacts + tickets Churn risk flag renewal dashboard alert Draft renewal email queued for CS review No human initiation required. Agent runs continuously against Salesforce data. The distinction from a standard Salesforce Flow is the reasoning layer. A Flow fires when a condition is met. An Agentforce renewal agent evaluates the condition in context — weighing multiple signals simultaneously, generating a natural language summary of what it found, and drafting context-aware communication that a Flow cannot produce. Part 3: Three renewal agent workflows worth building first Workflow 1 60-day renewal outreach agent Trigger:Contract end date is 60 days away. What it does:Reviews account health signals — product usage trend over the last 30 days, open support issues, last contact date, any logged expansion signals. Drafts a personalised renewal email with specific context from the account record. Queues the draft for CS review with a task to approve or revise within 48 hours. Why it works:A calendar reminder tells the rep to follow up. This agent tells the rep what the account looks like right now, drafts the message, and makes the rep’s job to review and send — not to research and write. The rep’s 20 minutes of prep becomes 5 minutes of review. Expected outcome: Higher quality renewal outreach, earlier in the cycle, with no additional CS capacity required. Workflow 2 Churn risk alert agent Trigger:Product usage drops more than 40 percent over a 14-day window compared to the prior 14 days. What it does:Flags the account with a Churn Risk tag in Salesforce. Creates a priority task for the account owner. Generates an account summary: last contact date, open support issues, usage trend, contract value and end date, any recent expansion or contraction signals. Why 14 days:The most actionable churn signals happen 30 to 60 days before renewal. A 14-day usage decline detected at 60 days out gives the CS team time to intervene before the customer has made a decision. Detected at 5 days out, the same signal is too late. Expected outcome: CS team prioritises the highest-risk accounts with full context before the intervention window closes. Workflow 3 Post-onboarding health agent Trigger:New subscription start date is 30 days ago. What it does:Checks whether the account has hit three key activation milestones. If all three are met, logs the health check and takes no further action. If one or more are not met, creates a targeted outreach task with a guided onboarding checklist attached and flags the account for a CS review. Why it matters:Customers who do not activate in the first 30 days are significantly more likely to churn at their first renewal. A health check at 30 days identifies at-risk customers at the moment where intervention — a 20-minute call, a targeted email with specific steps — is most likely to work. Expected outcome: Improved 30-day activation rates, lower first-renewal churn, CS effort focused on accounts that need it. Agent workflow Trigger What the agent does Expected outcome 📅 60-day renewal outreach Contract end date is 60 days away Reviews account health, drafts personalised renewal email, queues for CS review with 48-hour approval task Higher quality, earlier renewal outreach. Rep prep: 20 min → 5 min review. ⚠️ Churn risk alert Product usage drops 40%+ over 14-day window Flags account, creates priority task, generates account summary with full context CS prioritises at-risk accounts with
Agent Script: The Layer Between AI Flexibility and Enterprise Control
The biggest complaint about AI agents in production has always been the same: they work great in demos and go off-script in real deployments. Salesforce heard that complaint and built Agent Script — a scripting language that lets you define exactly how an agent behaves, step by step, without giving up the flexibility that makes AI useful. Here is what it is, how it works, and why it changes the calculus on Agentforce adoption. Agent Behaviour: Without vs. With Agent Script WITHOUT Agent Script — probabilistic path WITH Agent Script — deterministic rails User request Path A Path B Path C Outcome depends on reasoning and conversation flow ⚠ Risk: agent may skip required verification if the user’s phrasing is persuasive or impatient User request Identity verified REQUIRED STEP — Agent Script AI handles response Verification tool call must return confirmed — no bypass ✓ Deterministic: required steps always execute AI reasoning operates within defined rails The problem Agent Script was built to solve AI agents are probabilistic systems. Give an agent a task and it reasons toward an outcome — evaluating options, choosing actions, interpreting ambiguous inputs — in a way that is flexible and often impressive but never fully predictable from the instruction set alone. For customer service, sales qualification, and internal help desk use cases, that flexibility is valuable. The agent can handle variations in how a question is asked, adapt to unexpected inputs, and reach correct outcomes through different reasoning paths. However, for enterprise deployments where specific steps must happen in a specific order — identity verification before account access, compliance disclosure before a financial recommendation, escalation to a human at a specific deal stage — probabilistic behaviour is a blocker, not a feature. The question is not whether the agent gets to the right answer. It is whether it follows the required path to get there. How Agent Script works Agent Script adds a deterministic layer on top of the AI reasoning layer. You define the fixed logic in a human-readable JSON expression language — the if/then rules, the required tool calls, the handoff triggers, the compliance checkpoints — and the LLM handles the conversational reasoning in between the defined steps. The mental model is a set of rails. Between the rails, the agent reasons freely and handles variation naturally. At the defined points on the rails, the behaviour is fixed: the agent must perform a specific action, verify a specific condition, or hand off to a specific resource before it can continue. Agent Script — identity verification before account access Simplified example // Step 1: Required identity verification // Agent cannot proceed until this returns “verified” { “step”: “verify_identity”, “type”: “required_tool_call”, “tool”: “IdentityVerificationService”, “condition”: { “result”: “verified” // must match — no bypass } } // Step 2: AI handles the response conversation // LLM reasoning operates freely here { “step”: “handle_account_query”, “type”: “llm_reasoning”, “context”: “account_data”, “guardrails”: [“no_pii_in_response”] } // Step 3: Handoff trigger if deal threshold met { “step”: “check_escalation”, “if”: { “deal_value”: { “$gt”: 50000 } }, “then”: { “action”: “handoff_to_human”, “queue”: “senior_sales_rep” } } Between the defined steps, the AI reasons freely. At the defined steps, the behaviour is fixed — the agent cannot proceed without completing the required action. The distinction from a traditional decision tree is important. Agent Script is not replacing AI reasoning with a flowchart. It is constraining the parts of the interaction where constraint is required while leaving the parts where AI is valuable free to operate as designed. Practical examples Customer service agent with identity verification Without Agent Script: The agent is instructed to verify identity before accessing account data. Whether it follows that instruction precisely depends on how the conversation goes — a persuasive or impatient customer might cause the agent to skip or abbreviate the step. With Agent Script: Identity verification is a defined step in the script. The agent cannot proceed to account lookup until the verification tool call returns a confirmed result. The LLM handles the conversation around verification, but the verification itself is not optional. Sales qualification agent with human handoff Without Agent Script: The agent is instructed to hand off to a human sales rep when a qualified opportunity reaches a specific threshold. Whether it recognises the threshold correctly depends on its interpretation of the conversation. With Agent Script: The handoff trigger is defined explicitly. When the deal value field exceeds the threshold, or when the prospect uses specific phrases indicating high purchase intent, the agent executes a defined handoff action to the Salesforce queue. The LLM does not decide whether the handoff happens; the script does. Integration with Agentforce Builder Agent Script integrates with Agentforce Builder — the conversational build environment introduced in Spring ’26. Admins and developers write Agent Script in the Builder interface alongside the natural language instructions that govern the agent’s conversational behaviour. The separation of concerns in the build environment mirrors the separation in the runtime: conversational behaviour is configured in natural language, deterministic controls are written in Agent Script. Neither replaces the other. Additionally, Agent Script was open-sourced at TDX 2026. The full specification, parser, and compiler are on GitHub. For compliance teams and legal teams who need to understand and audit agent behaviour independently of the vendor, this is significant: Agent Script is a readable, auditable format that does not require Salesforce expertise to understand the logic. Who needs Agent Script now, and who can wait Use case type Determinism non-negotiable Pure AI reasoning is fine Customer service — account access Identity verification must precede account lookup without exception. Agent Script enforces the required step regardless of conversation flow. Handling FAQ questions that do not involve personal data — product information, store hours, general policies. Financial services Regulatory disclosures must be delivered before a product recommendation. Compliance checkpoints cannot be skipped regardless of conversation length. Summarising publicly available market information with no personalised recommendation required. Sales qualification Handoff to a human rep must trigger at a specific deal stage or value threshold,