Salesforce Q1 FY27 Earnings Preview
Salesforce reports Q1 FY27 earnings on June 3. Last quarter: $11.2B in revenue, 29,000 Agentforce deals closed, $800M in Agentforce ARR — and guidance for continued Agentforce-led growth. The question everyone will be watching is not whether the revenue number grew. It is whether Agentforce ARR is accelerating and how many of those 29,000 deals turned into real deployments. Salesforce FY26 Full-Year Results — The Baseline for June 3 Q1 FY27 earnings reported June 3, 2026 after market close $41.5B+10% YoYFY26 full-year revenue — highest annual total in company history $800M+169% YoYAgentforce Annual Recurring Revenue at end of FY26 29,000+50% QoQAgentforce deals closed since launch — commercial and public sector $72BRPORemaining Performance Obligations — contracted future revenue Source: Salesforce FY26 Q4 Earnings, February 25, 2026. Q1 FY27 results on June 3 are the first post-FY26 signal on whether Agentforce momentum is accelerating or plateauing. Watch 1: Agentforce ARR trajectory FY26 closed with $800M in Agentforce ARR after 169 percent year-over-year growth. Q1 FY27 is the first full quarter with three key products in market simultaneously: Agentforce Sales went GA on March 16, Agentforce Operations went GA on April 29, and Agentforce Contact Center is live in Enterprise and Unlimited editions. The ARR number on June 3 is the first clean signal of whether enterprise adoption is compounding from the FY26 base or plateauing as initial deal signings convert into measured deployments. A significant step-up from $800M suggests acceleration. Flat or modest growth suggests the 29,000 deal count is still primarily pilots and signed agreements rather than active production deployments. Additionally, watch the combined Agentforce and Data Cloud ARR figure. In FY26, that number exceeded $2.9B. The Data Cloud layer is the data substrate that makes Agentforce agents reliably useful — its trajectory tells you something about the depth of enterprise adoption beyond surface-level AI feature adoption. Watch 2: Deployment signals versus deal count Twenty-nine thousand Agentforce deals signed is a pipeline number. The more interesting metric is what proportion of those deals moved from signed to live in production. Salesforce provided proxy signals for this in FY26 — token consumption (nearly 20 trillion tokens processed) and agentic work units (2.4 billion delivered) — as evidence of real operational output rather than just signed contracts. Q1 FY27 will either extend those proxy metrics significantly or provide a more cautious signal about deployment pace. Token consumption accelerating quarter-over-quarter is the clearest indicator that the deal count reflects real production usage, not pipeline optimism. Three Questions to Watch on June 3Earnings preview 1 Is Agentforce ARR accelerating from the $800M FY26 base? Q1 FY27 is the first full quarter with Agentforce Sales (GA March 16), Operations (GA April 29), and Contact Center all in market. A significant step-up signals compounding enterprise adoption. Flat growth signals deals are still converting slowly from signed to deployed. Bullish signal: ARR significantly above $800M run rate 2 Are the proxy deployment metrics (tokens, agentic work units) accelerating? FY26 reported nearly 20 trillion tokens and 2.4 billion agentic work units — operational evidence of real production usage. If these numbers step up materially in Q1 FY27, it confirms a meaningful proportion of the 29,000 deals are live in production. Bullish signal: token consumption and agentic work units significantly higher 3 Any signal on Agentforce traction below the enterprise segment? FY26 Agentforce growth was primarily enterprise-led. The Spring ’26 release — AgentExchange consolidation, Salesforce Setup for SaaS, managed package templates — signals intent to accelerate mid-market and SMB adoption. Commentary on sub-enterprise traction would be significant. Watch for: SMB and mid-market Agentforce references in prepared remarks Watch 3: SMB and mid-market traction FY26 Agentforce growth was predominantly enterprise-led. Large deals with named enterprise customers drove the majority of the ARR. The Spring ’26 release — including the Salesforce Setup for SaaS initiative, the AgentExchange marketplace consolidation, and the acceleration of managed package templates for specific verticals — signals intent to bring Agentforce adoption into the mid-market and SMB segments. Salesforce’s $41.5B revenue base was built primarily on SMB and mid-market customers. The long-term Agentforce story depends on whether the platform can deliver agent value at that tier, not just at the enterprise level where implementation complexity is more manageable. One more thing: the Earnings Show format Salesforce moved its earnings calls to a more informal ‘Earnings Show’ format that often includes customer CEO guests and a conversational structure alongside the traditional financial presentation. It is worth watching in full rather than reading the transcript — the customer case studies and Benioff’s commentary on platform direction often contain more signal about where the product is going than the prepared remarks alone. 📺 About the Salesforce Earnings Show — June 3 🕔Time: After market close on June 3, 2026. Typically begins 1 hour after close with the press release, followed by the live show. 🎙️Format: Conversational structure alongside traditional financial presentation. Often includes customer CEO guests discussing real deployment outcomes. 📊Beyond the numbers: Benioff’s commentary on Agentforce deployment depth, customer case studies, and any commentary on the SMB and mid-market motion. 🔗Where: investor.salesforce.com — live stream and replay. TrueSolv will be covering the call live on LinkedIn. The revenue number on June 3 will tell you how Salesforce is doing. The Agentforce ARR trajectory and the deployment signals will tell you whether the platform bet is compounding. Those are different questions and the second one matters more for anyone who depends on Salesforce as infrastructure. Salesforce Earnings Q1 FY27 Agentforce Salesforce News CRM Share: LinkedIn Twitter / X Copy link In this article 01Watch 1: Agentforce ARR trajectory 02Watch 2: Deployment vs. deal count 03Watch 3: SMB & mid-market 04The Earnings Show format FY26 baseline — key numbers $41.5BFY26 full-year revenue $800MAgentforce ARR (end of FY26) 29KAgentforce deals closed $72BRemaining Performance Obligations $2.9BAgentforce + Data Cloud combined ARR June 3 — what to watch 📈Agentforce ARR step-up from $800M ⚙️Token consumption acceleration 🏢Sub-enterprise traction signals 📺Earnings Show — watch in full About the Author DS Daria Savelieva Salesforce Consultant &
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
Eight Summer ’26 Features Salesforce Developers Should Actually Care About
Summer ’26 release notes landed April 22. Sandboxes upgrade around May 9. If you have not looked at the notes yet, here are the eight features most worth your time — ranked by how much they will actually change your day-to-day development workflow, not by how impressive they sound in the release announcement. Feature Impact Action before May 9 sandbox upgrade LWC Single Component Preview High · GA Test with your most complex custom component. Verify preview correctly reflects nested child component states. No production risk — pure upside for iterative development speed. LWC State Management High · GA Identify pages with multiple LWC components sharing state via prop drilling or message channels. Build a proof-of-concept state store in sandbox before committing to a refactor plan. Collapsible Fault Paths in Flow Medium · GA No action needed before upgrade. Open your largest production flow in the Summer ’26 sandbox to confirm the canvas renders correctly and collapse fault paths for readability. Global Flow Resources Medium · Preview Enable in a preview sandbox. Identify the variables declared repeatedly across your flows. Evaluate the scope of what a GA version could simplify — but do not plan production changes until GA. AI Content Summarizer Component Medium · GA Drop the component onto an Opportunity or Account page in sandbox. Verify Agentforce has data access to the fields that would make the summary useful. Flag gaps for configuration before production. External Client Apps Enforcement High · Act now Open App Manager now. Filter by Connected App type. Identify every Connected App your org created and manages. Confirm migration status to External Client Apps before Summer ’26 tightens enforcement. Web Console for Apex/SOQL Medium · GA Familiarise yourself with the interface in sandbox. Evaluate whether it replaces Developer Console for ad-hoc work or supplements VS Code. Low risk — no configuration required. Agentforce in CRM Surfaces High · Test now Load your production-critical customised pages in the Summer ’26 preview sandbox. Check for layout conflicts between custom Lightning components and new Agentforce-aware UI elements before the upgrade lands in production. 1. LWC Single Component Preview This is the feature that has appeared on Salesforce developer wishlist surveys for multiple consecutive years and finally reached GA in Summer ’26. The ability to preview a single Lightning Web Component in the browser or in VS Code without triggering a full page reload is not a small improvement — it removes one of the most consistent time sinks in iterative LWC development. The practical impact depends on how much LWC work you do. For a developer spending four hours on a component UI, the difference between a 90-second page reload and an instant preview compounds significantly across a day. For teams building complex component libraries, the impact is considerable. GA means it is stable, supported, and safe to rely on in production development workflows. Test it in your Summer ’26 sandbox first to confirm it behaves correctly with your component architecture. 2. LWC State Management State Management for LWC reaches full general availability in Summer ’26, providing centralised state across component trees — the standard pattern for managing shared state in modern frontend development that LWC has been missing. The practical scenario: an Opportunity detail page has a line items component, a totals component, and a discount component. All three need to respond to the same underlying deal data. Without State Management, this requires lifting state through the parent component via properties, creating a coordination pattern that grows increasingly unwieldy as component trees deepen. With State Management, each component subscribes to a shared store directly. Before — prop drilling across components // Parent must hold all shared state // and pass down as props to each child @track totalMrr = 0; @track discount = 0; @track finalPrice = 0; // Wired to LineItems via: <c-line-items total-mrr={totalMrr} discount={discount}> </c-line-items> // And to Totals separately… // Grows unwieldy fast. After — centralised state store // Shared store — declared once import { createStore } from ‘@salesforce/state’; export const oppStore = createStore({ totalMrr: 0, discount: 0, finalPrice: 0 }); // Each component subscribes directly // No parent coordination needed // LineItems, Totals, Discounts // all update from the same store 3. Flow UI: Collapsible Fault Paths and Readable Data Tables Collapsible fault paths extend the canvas cleanup work started in Spring ’26 with collapsible Decisions and Loops. Large production flows become difficult to maintain when fault paths branch from every element that can fail and the canvas is an unnavigable tangle of error-handling logic. For developers maintaining flows built by previous admins, collapsible fault paths are a significant cognitive load reduction. The execution path becomes readable when error handling is collapsed. When debugging, expand the specific fault path you are investigating rather than navigating around all of them simultaneously. The data table display improvements in Flow Builder are in the same category — cosmetic in that they do not change flow behaviour, but meaningful for any developer who has tried to read a data table in the current canvas and given up. 4. Global Flow Resources Still in preview orgs, but worth testing now: Global Flow Resources enable variables and components to be shared across flows platform-wide rather than redeclared in every flow that needs them. The impact depends on your org’s automation architecture. Orgs with dozens of flows that each declare the same custom picklist variable or the same error-handling configuration are the immediate beneficiaries. If this ships as expected in Winter ’27 based on the current preview, it significantly reduces duplicated logic across complex automation layers. Because it is in preview, it belongs in your summer sandbox testing but not in your production planning until GA is confirmed. 5. AI Content Summarizer Component A new AI Content Summarizer component can be dropped onto any Lightning record page from App Builder without writing Apex. It surfaces an Agentforce-generated summary of the record’s key information — account history, deal context, case background — directly on the page. The developer
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,
Summer ’26 Flow Updates: Six Things That Will Actually Change How You Build Automations
Every Salesforce release, the Flow section of the release notes is the one worth reading first. Summer ’26 did not disappoint — new date operators, batch size control for scheduled flows, collapsible fault paths, natural language updates for Screen Flows via Agentforce, and a genuinely better radio button experience. Here is the full breakdown of what landed, what it does, and when you would actually use it. Feature What it does Who benefits most 📅 Date Field Operators New operators: Is Today, Is Tomorrow, Is On, Anniversary. Applies to Date fields only — not DateTime. Admins building renewal reminders, SLA tracking, birthday campaigns, or any time-sensitive record logic. Eliminates the need for formula field workarounds. ⚙️ Scheduled Flow Batch Size Custom batch size control instead of the fixed default of 200. Smaller batches = lower governor limit risk. Larger batches = faster processing. Any org running Scheduled Flows against unpredictable record volumes. High-value for flows with DML operations or external callouts. 🗂️ Collapsible Fault Paths Fault paths in Flow Builder can now be collapsed. Canvas continues the visual cleanup started in Spring ’26 with collapsible Decisions and Loops. Admins managing complex flows with shared error-handling subflows. Large production flows become significantly more readable. 🤖 Natural Language Screen Flow Updates Agentforce natural language editing now supports Screen Flows. Describe a change in plain language, Agentforce makes the adjustment. Early access — review required. Admins who want to trial Agentforce-assisted flow building. Works well for additive changes with clear descriptions. Complex logic still needs manual work. 🔘 Radio Button Group New compact visual component replacing standard radio buttons in Screen Flows. Horizontal and vertical layout options, less vertical space per option. Any admin who has built Screen Flow intake forms and found standard radio buttons too space-heavy. Direct UI improvement for end users. 📧 Email Template Deployment Fix Send Email Actions using Email Templates now deploy correctly between environments. Fix is in “Show advanced options” in the action properties. Orgs with proper sandbox-to-production workflows who have been maintaining environment-specific flow versions as a workaround. One-time fix. 1. New date field operators Flow now supports four new date operators: Is Today, Is Tomorrow, Is On, and anniversary-based matching for date fields. For any flow that does time-sensitive record logic, this is a meaningful improvement over the workarounds that previously required formula fields or date math. The practical applications are immediate. A renewal reminder flow that should trigger 30 days before the contract end date can now use Is On with a relative date formula rather than a calculated checkbox field. A birthday-triggered campaign can fire using the anniversary operator without building a custom evaluation layer. Any flow checking whether a date falls within a specific window benefits directly. One important constraint: these operators apply to Date data types only, not DateTime. If your date field includes a time component, the new operators will not be available. This is worth checking against your object schema before building. Summer ’26 — New Flow Date Operators Quick Reference Is Today Matches records where the date field equals the current date. Ideal for daily-run flows that flag due-today tasks, contracts expiring today, or time-sensitive SLA conditions. Is Tomorrow Matches records where the date field equals tomorrow’s date. Use for advance notification flows — renewal reminders, follow-up triggers, appointment confirmations the day before. Is On Matches records where the date field equals a specified date or relative date formula. Most flexible of the new operators — covers “is on the first of next month” and similar calculated dates. Anniversary Matches records where the month and day of the date field match the current month and day, regardless of year. Use for birthday campaigns, contract anniversary workflows, and renewal sequences tied to the same calendar date each year. ⚠ Important: these operators apply to Date fields only — not DateTime. Check your field type before building. 2. Batch size control for Scheduled Flows Scheduled Flows now support a custom batch size setting. The default has always been 200 records per batch, which is a sensible baseline for most use cases but creates problems when qualifying record counts are unpredictable and the flow logic includes DML operations, callouts, or other governor limit-sensitive steps. Smaller batch sizes reduce the risk of hitting limits when record volume spikes. A flow that runs cleanly on 200 records can fail when it processes 1,400 and the batch triggers 200 SOQL queries rather than 200. Reducing the batch to 50 adds processing time but removes the failure risk. The tradeoff runs in both directions. Larger batches complete the full scheduled run faster when record volume is stable and governor limits are not a concern. The new control lets admins tune this explicitly rather than accepting a single default for every scenario. 3. Collapsible Fault Paths Fault paths can now be collapsed in Flow Builder, following the Spring ’26 changes that added collapsible Decisions and Loops. This is a quality-of-life improvement rather than a capability change — fault paths do not behave differently when collapsed — but for anyone managing complex flows with shared error-handling subflows, the canvas clarity improvement is real. Large production flows become difficult to read when fault paths branch from every element that can fail and the canvas becomes a sprawl of error-handling logic. Collapsing fault paths lets admins focus on the main execution path during review and debugging, and expand fault handling when needed. 4. Update Screen Flows with natural language via Agentforce Agentforce-powered natural language editing, which launched for Record-Triggered and Scheduled Flows in Spring ’26, now extends to Screen Flows in Summer ’26. Admins can describe the change they want in plain language — ‘add a required email field before the address step’ — and Agentforce makes the adjustment in Flow Builder. This feature is in early access and the honest framing is the right one: it works well for additive changes that are clearly described. Reorganising a complex screen, adjusting conditional visibility rules, or changes that require
AgentExchange Salesforce: AppExchange Renamed
Salesforce has renamed things before. A lot. Data Cloud has had five names. Agentforce 360 had four. But AgentExchange, Salesforce’s most consequential rename yet is different. The AppExchange, launched in 2006, the marketplace that nearly 90 percent of Salesforce customers used to extend the platform, just became AgentExchange. Launched with a $50M Builders Fund and 13,000 apps, agents, and MCP servers under one roof. The community has thoughts. AppExchange to AgentExchange — Twenty Years 06 2006 AppExchange launches — first enterprise app marketplace Launch 12 2012 1,000 apps milestone 18 2018 AppExchange integrates Slack apps after acquisition 24 2024 Agentforce launches — first AI agent listings appear 26 2026 AgentExchange — unified catalog, AI search, $50M fund Now What actually changed The rename is not purely cosmetic. Three previously separate catalogs, the AppExchange, the Slack Marketplace, and the Agentforce ecosystem, are now unified into a single AI-searchable marketplace. That means 10,000 Salesforce apps, 2,600 Slack apps, and over 1,000 agents and MCP servers from partners including Google, DocuSign, and Notion now live in one place. Discovery works differently. Instead of keyword browsing through categories, users describe what they need and AgentExchange surfaces the right solution. One-click activation replaces the previous multi-step install process. For admins who have spent time navigating package installation wizards, that reduction in friction is material. The $50M Builders Fund is the other concrete change. It provides investment, engineering support, and go-to-market backing for ISVs and partners building in the new ecosystem, not a fund you apply to generically, but structured support tied to building agents and MCP integrations for AgentExchange distribution. The case for why it is more than a rebrand The community frustration with Salesforce naming is understandable and largely justified. When a product gets four names in three years, each rename starts looking like a marketing exercise rather than a product decision. This one is different for a specific reason: the marketplace structure changed, not just the name. AppExchange was an app catalog optimised for keyword search and category browsing. AgentExchange is designed from the ground up for AI-guided discovery. Those are different products with different underlying assumptions about how users find and evaluate solutions. Moreover, the consolidation of Salesforce apps, Slack apps, and AI agents into a single catalog reflects a genuine product reality: the Salesforce platform in 2026 includes all three, and separating them into different marketplaces created friction for customers who needed solutions that span all three surfaces. Putting them in one place with AI-guided discovery is a coherent response to how the platform actually works now. Partner data from the announcement makes the economic case more concrete. DocuSign processed over 200 private offers in Q4 2025 with 60 percent faster time to signature after listing on the unified marketplace. Notion cut its average sales cycle from four months to three weeks. These are not typical launch testimonials — they are specific metrics tied to the marketplace distribution model. What the community is actually saying The Reddit r/Salesforce thread opened with ‘Why?’ and the SF Ben community spent a productive afternoon debating whether CTO Nicolas Vuilamy was right that the company would eventually just rename itself Agentforce. One Salesforce coach wrote: ‘It is all a clear sign that the future is not human for Salesforce.’ The tone ranged from resigned to genuinely unsettled. The underlying concern is reasonable. When every product gets an ‘Agentforce’ prefix and every marketplace becomes an ‘Exchange’, it starts to feel like the platform is being rebuilt around a bet on AI that has not yet fully proven itself in the field. That is a fair read. The counter is also fair: the bets Salesforce made on CRM in 2006 and on the cloud in 2010 looked aggressive at the time and turned out to be correct. The question is whether the AI agent bet is in the same category. What this means by role 13,000+ Solutions total Salesforce apps, Slack apps, agents, and MCP servers unified in AgentExchange at launch $50M Builders Fund Investment, engineering support, and go-to-market backing for ISVs building agents and MCP servers 300% YoY growth Growth in Slack AI agent listings since January 2026 — the fastest-growing category in the marketplace Role What actually changed for you What to do now Admin Unified catalog means one place to find solutions across Salesforce, Slack, and Agentforce. AI-guided discovery replaces keyword browsing. One-click activation replaces multi-step install wizards. Explore Browse AgentExchange for solutions you previously searched AppExchange for — new categories and unified search may surface options you did not know existed. Developer 1,000+ agents and MCP servers are now listed alongside traditional apps. These are structured integration tools AI coding agents can call directly — a new category of extension beyond installed packages. Evaluate Review available MCP servers relevant to your integration stack. The agent/MCP category will expand rapidly; early familiarity pays off. ISV / Partner The $50M Builders Fund and AI-guided distribution represent a genuine go-to-market shift. Marketplace discoverability now depends on AI-optimised listing quality, not just keyword-based search ranking. Act now Review AgentExchange listing criteria. Evaluate what an agent or MCP server submission would require for your product. The window to list early in an AI-native marketplace is open now. Decision Maker The rename signals Salesforce’s long-term direction: agents as the primary unit of value. The practical marketplace capabilities are similar to AppExchange for current purchasing decisions. The strategic signal is clear. Watch Track which vendor partners are building agents and MCP integrations. The ecosystem is reshaping around agent-based extensions — understanding the map now informs technology roadmap decisions later. Building on Salesforce and thinking about what AgentExchange means for your product or integration strategy? Reach out at truesolv.com — we work with the Salesforce ecosystem daily. Follow us on LinkedIn for more Salesforce news with less jargon.
Salesforce Headless 360 and MCP
For most of Salesforce’s history, building on the platform meant working inside it: browser open, Setup menu navigated, page layouts configured. Salesforce Headless 360, announced at TDX on April 15, draws a line under that era. Every piece of the platform (data, workflows, business logic, compliance controls) is now reachable as an API, an MCP tool, or a CLI command. No browser required. Here is what that actually means if you build integrations or work with AI coding tools. Salesforce Headless 360 — How the Platform Is Now Exposed Salesforce Platform Data · Flows · Logic · Permissions Headless 360 REST / Bulk / Streaming Standard Salesforce APIs 60+ MCP Tools AI-callable structured tools CLI / DevOps Center Programmatic CI/CD access Human Developers CLI · VS Code · CI/CD pipelines AI Coding Agents Claude Code · Cursor · Codex Integration Systems MCP servers · External APIs No browser required. Every capability reachable as API, MCP tool, or CLI command. What Salesforce Headless 360 Ships With The headline number is 60 new MCP tools exposing Salesforce capabilities as structured interfaces that AI agents can call directly: objects, flows, deployments, permissions, reports. Alongside those, 30 preconfigured coding skills cover the most common Salesforce development tasks, from writing Apex triggers to configuring permission sets. DevOps Center MCP and Natural Language DevOps The DevOps Center MCP is the most immediately practical piece for integration teams: it brings programmatic access into any CI/CD pipeline. Natural Language DevOps sits on top of that: describe what you want to deploy in plain language and agents execute it. Salesforce cites a 40 percent cycle time reduction for development workflows as an early benchmark from teams using the integrated toolchain. The framing from Salesforce is that the build loop requiring context-switching across four different tools now happens inside one connected experience. That is the right framing, but the practical reality depends heavily on where your org’s metadata and documentation quality sits right now. What MCP means for Salesforce integrations The Model Context Protocol is becoming the default interoperability layer for AI agents across the industry. By exposing Salesforce through MCP, Salesforce is positioning itself as a participant in multi-agent orchestration, not just a destination for data, but a system that AI agents from Claude Code, Cursor, Codex, and Windsurf can work within directly. The practical shift for integration teams is significant. Instead of writing API wrappers manually (defining the request shape, handling authentication, mapping the response), you describe the integration behaviour and an agent executes and tests it using the MCP tools that already understand Salesforce’s object model. A Practical Integration Example For example: an integration that syncs Salesforce Opportunity data to an external billing system previously required a developer to write and maintain the API connection, handle field mapping, and manage error states. With MCP-exposed Salesforce tools and an AI coding agent, the same integration can be described in plain language, generated, and validated against the actual org schema, including custom objects and fields, without manual API documentation reading. The constraint is the quality of the description. Vague integration requirements produce vague integrations. MCP tools remove the API plumbing problem; they do not remove the requirement to know what you are building. Agent Fabric and multi-agent governance Headless 360 opens the Salesforce platform to AI agents. Agent Fabric answers the follow-on question: when you have multiple agents from multiple vendors operating across Salesforce and other systems, who governs them? Agent Fabric is the control plane launched at TDX 2026. It provides deterministic orchestration and centralised governance across agents, tools, and LLMs, scanning for agents across Salesforce Agentforce, Amazon Bedrock, Microsoft Foundry, and MCP servers, then providing a unified view of what agents exist, what they have access to, and what they are doing. Why Deterministic Governance Matters The governance problem it solves is specific: AI agents are probabilistic. They reason toward outcomes, which means their behaviour cannot be fully predicted from the instruction set alone. Agent Fabric adds the deterministic layer: Agent Broker defines fixed handoff rules between agents, Agent Script enforces compliance checkpoints within workflows, and Trusted Agent Identity ensures agents execute with specific user permissions rather than a shared service account. For architects designing systems where agents span Salesforce and external platforms, Agent Fabric is the piece that makes enterprise-grade deployment possible rather than merely experimental. Workflow Traditional Salesforce dev Headless 360 + AI coding agents Write an Apex trigger Open Developer Console or VS Code → write Apex → deploy to sandbox → test manually → deploy to production Describe the trigger behaviour in natural language → agent writes Apex using your org’s actual object model → review → deploy via DevOps Center MCP Build a Salesforce integration Read API docs → write request/response handlers → map fields manually → handle auth and error states → test in sandbox Describe integration behaviour → agent generates using MCP tools that understand your schema → automated testing → review and approve Understand an existing automation Open Flow Builder or Apex class → read through the logic → trace dependencies manually → ask a colleague Ask Vibes (Ask mode): “Explain this trigger and whether it conflicts with the Process Builder on this object” — org-aware answer with dependency context Debug a production issue Reproduce locally → inspect error log → trace through code → write fix → test → deploy Debug mode: agent analyses error log, identifies root cause in org context, proposes targeted fix → developer reviews and applies Deploy a change across environments Package the change → run change set or Salesforce CLI deploy → validate in staging → release Natural Language DevOps: describe the deployment in plain language → agent executes via DevOps Center MCP with CI/CD pipeline integration Context-switching across tools VS Code → Org → Developer Console → Sandbox → Jira → Slack → back to Org. Multiple context switches per task. One connected experience inside the development environment. Salesforce cites 40% reduction in development cycle time. What you need before Headless
TDX 2026 Salesforce Recap
Salesforce co-founder Parker Harris asked the question right before TDX 2026: “Why should you ever log into Salesforce again?” What got announced on April 15 in San Francisco was a structural redesign of how the entire Salesforce platform works. Here is the short version of everything that actually matters. 🌐 Headless 360Platform as API Every Salesforce capability is now an API, MCP tool, or CLI command. AI coding agents can build and act in your org without a browser. GA at TDX 60+ new MCP tools · 40% dev cycle time reduction 🎛️ Agentforce Vibes 2.0Org-aware AI dev IDE Vibe coding with full org metadata awareness. Four modes: Agentic, Plan, Ask, Debug. Runs on Claude Sonnet, GPT-5, and open source models. Preview May ’26 Multi-model · Paid tier required 🔄 AgentExchangeAppExchange renamed AppExchange, Slack Marketplace, and Agentforce ecosystem unified into one AI-searchable catalog. One-click activation. $50M Builders Fund. GA at TDX 13,000+ solutions · 1,000+ agents & MCP servers 📋 Agent ScriptOpen-sourced Deterministic scripting language for AI agents — fixed rules + LLM reasoning in between. Full spec, parser, and compiler now on GitHub. Open source Compliance-readable · Agent Fabric integration Headless 360: the browser is now optional For most of Salesforce’s history, building on the platform meant working inside it — browser open, Setup menu navigated, page layouts configured. Headless 360 draws a line under that era. Every capability on the Salesforce platform is now reachable as an API, an MCP tool, or a CLI command. Sixty new MCP tools and thirty preconfigured coding skills shipped at launch. The practical implication is that AI coding agents can now build and act inside your Salesforce org without a browser open anywhere. Salesforce cited a 40% cycle time reduction for development workflows as an early benchmark. The DevOps Center MCP brings programmatic access into any CI/CD pipeline, and Natural Language DevOps lets developers describe what they want to deploy rather than configuring it step by step. Agentforce Vibes 2.0: org-aware AI development Most AI coding tools write code that looks correct but does not know what objects, fields, profiles, flows, or integrations exist in your specific org. Agentforce Vibes 2.0 solves that. It uses the Salesforce Unified Catalog to provide context-aware suggestions from the first prompt. Four work modes ship with Vibes 2.0. Agentic mode for autonomous task completion. Plan mode for back-and-forth review before any code is written. Ask mode for questions about how the org or its code works, without triggering changes. Debug mode for inspecting what is happening in production and proposing a fix before applying it. Multi-model support is included: Claude Sonnet, GPT-5, and open source models. For organisations with model commitments or data residency requirements, that is material. Vibes 2.0 enters preview in May 2026. The free tier is being removed; a paid subscription is required. AgentExchange: one marketplace for everything AppExchange launched in 2006 and became the marketplace that nearly 90 percent of Salesforce customers used to extend the platform. It just became AgentExchange. The rename reflects a structural consolidation: AppExchange, the Slack Marketplace, and the Agentforce ecosystem are now unified into a single AI-searchable catalog. Ten thousand Salesforce apps, 2,600 Slack apps, and over 1,000 agents and MCP servers from partners including Google, DocuSign, and Notion now live in one place. One-click activation replaces the previous multi-step install process. A $50M Builders Fund provides investment, engineering support, and go-to-market backing for ISVs and partners building in the new ecosystem. Partner results from the announcement: DocuSign cut time to signature by 60 percent after listing on the new marketplace. Notion reduced its average sales cycle from four months to three weeks. Agent Script goes open source Agent Script is the scripting language Salesforce built to solve a specific problem: AI agents are probabilistic. They reason their way through scenarios and can arrive at unexpected outcomes because that is how LLM reasoning works. For enterprise deployments, that unpredictability is often a blocker. Agent Script adds a deterministic layer on top: you define the fixed logic and the LLM handles the reasoning in between the defined steps. At TDX 2026, Salesforce open-sourced the full specification, including the parser and compiler, on GitHub. The open-source move is a platform bet. Salesforce is inviting the broader developer ecosystem to build agent authoring tools on top of a shared language specification rather than a proprietary SDK. Furthermore, it makes Agent Script readable and auditable by compliance teams who do not write code. “Why should you ever log into Salesforce again?” Parker Harris, Salesforce Co-Founder Said before TDX 2026 — not a provocation, but the product roadmap. Every Salesforce capability is now reachable as an API, MCP tool, or CLI command. What this means for your org right now The honest answer is: less than the announcement energy suggests, and more than you can safely ignore. For orgs that are not yet using Agentforce at all, TDX 2026 reduced the distance between a prototype and a deployed agent. The infrastructure, APIs, MCP tools, Agent Script, a governed marketplace, is now in place. The question is no longer whether you can build on it; it is whether your org’s metadata, data quality, and team readiness support doing so reliably. For orgs already running Agentforce in production, Headless 360 and Agent Script are the most immediately relevant announcements. Headless 360 changes how integrations and CI/CD pipelines interact with the platform. Agent Script changes how you define and govern agent behavior at scale. Role Most relevant TDX announcement What to do now Salesforce Admin External Client Apps enforcement tightening in Summer ’26 alongside the sandbox upgrade. AgentExchange consolidation changes how you install managed packages. Act now Audit Connected Apps before May 9. Review AgentExchange for any solutions your org has been looking at. Developer Headless 360 ships 60+ MCP tools and enables AI coding agents to work directly inside Salesforce orgs. Agentforce Vibes 2.0 previews in May with org metadata awareness and four work modes. Plan for Assess your metadata hygiene — Vibes
Salesforce Tracks Field History. Just Not Enough of It
Salesforce tracks field history out of the box. Most admins know this. What they also know is that the native tracking has a ceiling of 20 fields per object, a retention window of 18 months, and a reporting layer that makes it genuinely difficult to answer the question: what changed, when, and who did it? For most orgs running real sales, compliance, or operations workflows, those limits are not theoretical. They are the reason someone eventually asks for something the system cannot produce. What native Field History Tracking actually gives you Salesforce’s built-in Field History Tracking works by logging changes to specified fields on standard and custom objects. When a field value changes, Salesforce records the old value, the new value, the timestamp, and the user who made the change. That information appears in a related list on the record. This is genuinely useful as far as it goes. For a small team with straightforward audit needs and a limited number of objects to monitor, it covers the basics without any configuration beyond selecting the fields to track. The limits become visible when the needs become real. Twenty fields per object is not a large number for an org where a Sales team, an Ops team, and a CS team are all working on the same objects with different fields they care about. Eighteen months is a short window for any compliance use case where a contract or customer relationship spans multiple years. And the related list view, while functional for looking up a single record, is not a reporting surface. ⚠ What happens when a deal value changes and nobody knows why The situation A rep closes a deal at $48,000. Commission is calculated. Three weeks later, the Opportunity Amount in Salesforce reads $38,000. The rep says the value was changed without authorisation. The manager says it was never $48,000. The deal was one of hundreds closed that quarter. Without True Field History The Amount field was not one of the 20 tracked fields — or the change happened during a bulk import that bypasses native logging — or it happened 19 months ago, outside the retention window. No verifiable record exists. The dispute is resolved by whoever has more leverage in the room. With True Field History The full history of the Amount field is available as a Salesforce report: original value, every change since creation, the user who made each change, and the timestamp. The dispute takes five minutes to resolve, and the answer is based on data, not memory. What True Field History does differently True Field History is a native Salesforce app built to remove the ceilings that the built-in tracking imposes. It runs inside your existing Salesforce org, uses the same objects and security model your team already works with, and does not require external infrastructure or a separate data store. The difference is in what gets tracked, how long it is retained, and what you can do with the data once it exists. Capability Native Field History Tracking True Field History Fields tracked per object 20 fields maximum Hard Salesforce platform limit — applies to all standard and custom objects Unlimited Track as many fields as your compliance or operations requirements need Data retention period 18 months Changes older than 18 months are purged automatically by Salesforce Configurable Retain history for as long as your business or regulatory requirements specify Reportability Related list only View history on one record at a time — cannot be included in standard Salesforce reports or dashboards Full Salesforce reporting History data is queryable via Reports and Dashboards — analyse across records, users, and time periods API and system user changes Partial API changes to tracked fields are logged, but still subject to the 20-field cap and retention window Full coverage All changes captured — human edits, integration users, API calls, and system processes Bulk and import changes Not logged Data Loader and bulk API changes are excluded from native field history by default Captured Import and bulk operation changes are logged with user, timestamp, and source Cross-record analysis Not available No way to report on which fields changed most, which users made the most edits, or change patterns across the org Available Build reports on change frequency, user activity, object-level trends, and pre/post-change values at scale Compliance audit readiness Limited Adequate for basic lookups within the 18-month window if the field was tracked — insufficient for formal audits on older data Purpose-built Designed to produce the complete, date-stamped change history that auditors and compliance teams require Installation Native — no install needed Native Salesforce app Installed in your org — no external infrastructure or separate data store No field cap True Field History tracks as many fields as your compliance, operations, or business requirements need — not as many as Salesforce’s 20-field limit allows. For objects with complex workflows where many fields carry business-critical information, this removes the prioritisation problem: you no longer have to decide which 20 fields matter most. Retention that matches your business timeline The 18-month native retention window is shorter than many contract cycles, audit requirements, or customer relationship timelines. True Field History retains the history you need for as long as your business requires it, without the automatic purge that native tracking applies. History that is actually reportable The related list view in native Salesforce is not a reporting surface. It shows you the history of one record at a time, which is fine for lookups but useless for analysis. True Field History stores change data in a structure that Salesforce Reports and Dashboards can query. That means you can answer questions like: which fields changed most frequently last quarter, which users made the most modifications to closed Opportunities, or which accounts had their contract value changed in the 30 days before renewal. System and API changes captured Changes made by integration users, system administrators, or API processes are logged alongside changes made by human users. For orgs with active integrations,