Salesforce Integration Services, What the Work Involves
Sales lives in Salesforce, billing lives somewhere else, and someone spends every Friday afternoon reconciling the two by hand. That Friday afternoon reconciliation is the tell. Salesforce integration services connect the systems a team already relies on, billing, support, marketing, product data, so information moves automatically instead of getting copied by hand, and the person doing that copying gets their Friday back. SALESFORCE INTEGRATION / PROJECT STAGES Billing system 1 Data mapping 2 Sync architecture 3 Error handling 4 Sandbox testing 5 Monitoring Salesforce Real example, from our case studies Salesforce + Stripe, 6 weeks, renewals +28% Five stages between two disconnected systems and one live sync — mapping and architecture decided before anything is built. What disconnected systems actually cost The cost is not just the hour someone loses matching two spreadsheets. It’s the renewal risk that sits in a billing system for three days before sales ever sees it, or the field that gets mistyped during manual reconciliation and quietly feeds every report built on top of it afterward. A number that’s wrong on a Friday is wrong in every report pulled the following Monday, and by then nobody’s checking the original source anymore, they’re checking Salesforce. What a proper integration project actually involves 1Data mapping firstDeciding which system owns which field, and what happens when the two disagree, before a single line of integration code gets written 2Sync architecture chosen on purposeReal time API sync for anything time sensitive, a payment failure, a churn signal, and scheduled batch sync for anything that can wait a few hours, decided deliberately rather than defaulted to whichever is easier to build 3Error handling built in from the startThe other system will go down eventually, or send back something malformed, and a silent failure that nobody notices for a week is worse than a loud one that pages someone immediately 4Sandbox testing with data shaped like the real thingChecking both directions of the sync, not just the direction that was top of mind when the project got scoped 5Monitoring that continues after launchA sync that worked on day one and quietly stopped on day forty is the failure mode that costs the most trust, so something has to keep watching it What this looks like in practice TrueSolv connected Salesforce and Stripe for a UK fintech SaaS company in six weeks, syncing subscription and payment data directly onto Account records instead of leaving billing and sales to reconcile manually. Renewal rates rose 28 percent, and reconciliation time dropped by roughly three quarters. See the full Salesforce Stripe integration case study for the breakdown, from the discovery call to the churn alerts firing in production. A number that’s wrong on a Friday is wrong in every report pulled the following Monday. The fix isn’t a faster reconciliation process. It’s not needing one. Book an integration consultation through our contact form, and follow TrueSolv on LinkedIn for more Salesforce integration notes. Salesforce IntegrationSalesforce ConsultingCRM AutomationData SyncTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What disconnected systems cost 02What the work involves 03What this looks like in practice 5 project stages 1Data mapping 2Sync architecture 3Error handling 4Sandbox testing 5Monitoring Reconciling two systems by hand? Book a consultation to scope what connecting them would look like. Book a consultation → About the Author AS Anastasia RashkinaSalesforce Developer at TrueSolv
Field History Tracking Salesforce Can’t Do Past 20 Fields
A record looks wrong, three people had edit access, and nobody remembers who touched it last. Standard Salesforce field history tracking caps at 20 fields per object and keeps changes for only 18 months, with no real reporting layer beyond a related list on one record at a time. For any team where a data dispute carries business or legal weight, that ceiling turns into exactly the question the system can’t answer. NATIVE TRACKING VS TRUE FIELD HISTORY Fields tracked per object NATIVE 20 max TRUE FIELD HISTORY Unlimited Retention window NATIVE 18 months TRUE FIELD HISTORY Configurable Reporting NATIVE One record, one list TRUE FIELD HISTORY Full reports Also captured Bulk imports API & integration users Cross-record trends Native Salesforce tracking is a starting point. For compliance-heavy teams, the ceiling is a risk, not an inconvenience. Three ceilings native tracking hits — fields, retention, reporting — removed on all three. Where the built-in limit actually bites Twenty fields per object isn’t much when a sales team, an ops team, and a support team are all working the same object with different fields they each care about. Eighteen months is short for anything spanning a full contract or customer relationship. And the related list view works fine for looking up one record, but it isn’t a reporting surface, so there’s no way to ask which fields changed most last quarter or which users made the most edits. Picture a deal that closed at one amount, and three weeks later the Opportunity shows a lower number. The rep says it was changed without authorization. The manager disagrees. If that field wasn’t one of the 20 tracked, or the change happened during a bulk import, or it happened outside the 18-month window, there’s no verifiable record. The dispute gets settled by whoever argues harder, not by data. How True Field History extends it True Field History — how it extends native tracking 🗂Tracks as many fields as compliance or operations actually need, not capped at 20 📅Retention configured to match the business’s own timeline instead of an automatic 18-month purge 📊History stored so Salesforce Reports and Dashboards can query it directly, across records and users, not one record at a time 🔌Captures changes from integration users and API processes alongside human edits, so bulk imports don’t create a blind spot 🏗Runs natively inside the existing org on the same objects and security model, no external data store to stand up A compliance team asking for the full change history on a contract from two years back used to get the same answer every time. Native tracking had already purged it, or the field in question was never one of the 20. With True Field History, that request becomes a Salesforce report showing every value, user, and timestamp involved, ready in minutes instead of stalling a finance or healthcare audit. Book a True Field History demo through our contact form, and follow TrueSolv on LinkedIn and Instagram for more Salesforce product content. True Field HistorySalesforce ComplianceData GovernanceSalesforce ToolsTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Where the native limit bites 02How True Field History extends it Native vs True Field History Fields tracked20 max→Unlimited Retention18 months→Configurable Reporting1 record, 1 list→Full reports Field history that stops at 20 fields? True Field History removes the field cap, the retention limit, and the reporting gap. Book a demo → About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
Agentforce Implementation, Where to Actually Start
Everyone is talking about autonomous agents in Salesforce, but few teams can name one concrete first step. The honest answer to where to start with Agentforce implementation is with one workflow, not a strategy. Pick a single repetitive task your team can already describe clearly, ground the agent in Salesforce data and content you already trust, and get that one agent live before touching a second use case. AGENTFORCE IMPLEMENTATION / FIRST STEP TODAY Manual workflow Readiness assessment Blueprint & grounding First live agent WHERE TEAMS ACTUALLY START Case deflection Email drafting Agent-assisted replies Start narrow. One workflow, one agent, a human still in the loop. From today’s manual step to a first live agent — readiness assessment, blueprint, then go live. What Agentforce can actually do right now Agentforce uses the automations and integrations already in your Salesforce org as callable actions, then pairs those actions with answers pulled from your CRM data and approved content. It works inside topics and routing you define, not as an open-ended assistant that figures out your business on its own. That’s not a limitation to apologize for. It’s what makes an agent’s answers traceable back to data your business actually owns, instead of a plausible-sounding guess. Where teams actually start 💬Case deflectionThe agent answers common support questions from your knowledge base before a ticket ever reaches a human queue. ✉️Email draftingThe agent prepares a first-pass reply grounded in the case history, and a rep reviews it before anything goes out. 🤝Agent-assisted repliesInside Slack or the service console, the agent surfaces a likely answer with its source, and a person still makes the call. Every one of these keeps a human in the loop on the first pass. That’s by design. The point of a first use case is proving the agent’s answers hold up against real questions, not handing it the keys on day one. What an Agentforce implementation with TrueSolv involves It starts with a readiness assessment, a review of your org, data sources, and target workflows to confirm what Agentforce can support now and what needs prep first. From there, a use case workshop turns one workflow into a clear blueprint, with topics, allowed actions, handoff rules, and success metrics defined before any building starts. Data grounding comes next, configuring the agent to answer from your Salesforce data and approved sources, alongside a knowledge cleanup pass so it pulls one consistent answer instead of three conflicting versions. Agent Builder configuration sets up the topic structure, routing, and guardrails, and a Flow and Apex action library lets the agent actually complete tasks inside Salesforce, not just talk about them. Structured testing on topic and action selection runs before rollout, and monitoring stays on after go-live so the agent keeps improving on real usage instead of staying frozen at launch. The point of a first use case is proving the agent’s answers hold up against real questions, not handing it the keys on day one. Book an Agentforce readiness call through our contact form, and follow TrueSolv on LinkedIn for more on where this technology is actually ready today. AgentforceSalesforce AIAI AgentsSalesforce ConsultingTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What Agentforce can do now 02Where teams actually start 03What implementation involves Implementation steps 1Readiness assessment 2Use case workshop & blueprint 3Data grounding & KB cleanup 4Agent Builder configuration 5Testing & rollout 6Monitoring after go-live Ready for a first agent? Book a readiness call to scope one workflow and get a real blueprint. Book a readiness call → About the Author AS Anastasia SokolovaSalesforce Developer at TrueSolv
Task Tracker Salesforce App That Keeps Deadlines Visible
Tasks live in Trello or Asana, deals live in Salesforce, and the manager finds out about a missed deadline last. A task tracker Salesforce app fixes that by keeping tasks, due dates, and priorities on the same record as the deal or case they belong to, so a missed deadline shows up on the account itself instead of surfacing three tools away, days after it mattered. OUTSIDE SALESFORCE Trello / Asana board Email thread ! Manager finds out last True Task Tracker SALESFORCE Task & due date Priority tag Comments & files One task list, tied to the deal it belongs to. Trello board, email thread, and a manager finding out last — all replaced by one task list on the Salesforce record. Why splitting tasks and CRM data costs more than convenience A rep works from a board in one tab while the deal record sits open in another, and the two never fully sync. A task gets marked done in Trello and the opportunity record never reflects it. A follow-up call slips because the person who owns the deal isn’t the person watching the board, and the two tools were never going to tell each other. That’s not a discipline problem. It’s a system problem. Two tools with two sources of truth will always drift, and the gap between them always costs someone — a rep who missed a follow-up, a manager scanning a pipeline that doesn’t show the half-overdue task still sitting in Asana. What comes with it True Task Tracker — what’s included 📋Tasks created, assigned, and managed with due dates — right on the record they belong to, no separate login 🏷Flexible tags to prioritize and categorize, plus custom columns for how your team actually works 🔔Instant notifications when a task changes, so a status update doesn’t wait to be noticed hours later in a different tool 📎Files and comments attached directly to the task, instead of scattered across email threads and Slack conversations ↕️Drag-and-drop task movement for updating status without a form to fill out — the way boards work, inside Salesforce Who gets the clearest win A sales team gets the clearest result first. Follow-up tasks sit directly on the opportunity, so a manager scanning the pipeline sees exactly which deals have an overdue task without opening a separate board to check. A support team benefits just as much. Escalation tasks get assigned with a due date and a priority tag right on the case, and the comments and attachments that explain the escalation stay with it instead of living in three different Slack threads. The support lead sees what’s overdue, who owns it, and why it was flagged — all from the same record view they’re already in. The deadline was always real. Now it lives where the deal does. Request a True Task Tracker demo through our contact form, and follow TrueSolv on LinkedIn and Instagram for more tools built to keep work inside Salesforce. True Task TrackerSalesforce ProductivitySales OpsCRM ToolsTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01Why splitting tools costs more 02What’s included 03Who gets the clearest win Deadlines still living in a separate board? True Task Tracker puts tasks, due dates, and priorities directly on the Salesforce record. Request a demo → 5 things included 📋Tasks + due dates on the record 🏷Flexible tags + custom columns 🔔Instant notifications on change 📎Files + comments on the task ↕️Drag-and-drop status update About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
Salesforce Health Check Signs Your Org Needs an Audit
The org keeps growing, automations keep piling up, and nobody has reviewed access permissions in years. You know an org needs a Salesforce Health Check when the same handful of symptoms start showing up together. Reports that give a different number depending on who pulls them. Permission sets nobody remembers granting. Flows nobody wants to touch because nobody is sure what they’d break. If two or three of those sound familiar, the org is already overdue. INSIDE THE ORG ! Unused field ! Orphaned Flow ! Permission creep ! Duplicate records Health Check HEALTH CHECK REPORT Security & access Data quality Performance & scale Org structure Licenses & contracts Integrations & API Six domains, one report, no guessing what’s actually wrong. Four warning signs inside the org — one six-domain Health Check report that names every one of them. What an unaudited org tends to look like Custom fields nobody remembers the purpose ofStill sitting on every page layout, slowing down load times, and appearing on reports where they were never meant to. Orphaned Flows referencing deleted objects or fieldsActive automations pointing at things that no longer exist — running silently, failing silently, or doing nothing at all. Permission sets that have grown broader with every hire and never been trimmedThe easiest fix at onboarding time becomes a security exposure the moment someone changes roles or leaves the company. Duplicate records quietly skewing every report that touches themTwo records for the same account mean two pipelines, two activity histories, and one number nobody fully trusts. Why this is a risk now, not a someday problem None of this happens on purpose. It happens because Salesforce is flexible enough to absorb years of quick fixes without ever forcing a cleanup, so the org keeps working just well enough that nobody schedules the review. A former employee with an active login is a live exposure the moment they leave, not a theoretical one. Reports that take too long to load or automations that quietly conflict cost real working hours every single week, not just at renewal time. The longer the mess sits, the more new work gets built on top of it, and the more expensive the eventual cleanup gets. What a Salesforce Health Check covers A TrueSolv Health Check reviews six domains in one pass: Security and access controls. Data quality and management. System performance and scalability. Org structure and customization. License and contract usage. Integrations and API health. The client walks away with a findings report running twenty to forty pages, each issue rated by severity with a plain language explanation and a specific fix. An executive summary condenses the top priorities for anyone who wasn’t in the weeds. An action item list with effort estimates plugs straight into a sprint, and a quick wins checklist flags what an admin can fix the same afternoon. The org keeps working just well enough that nobody schedules the review. That’s what makes the mess expensive — it compounds every week you don’t look at it. Run the free Salesforce Health Check self-assessment for an instant score, or book the full audit through the contact form. Follow TrueSolv on LinkedIn for more org cleanup notes. Salesforce Health CheckSalesforce SecurityCRM AuditSalesforce AdminTrueSolv Share: LinkedIn Twitter / X Copy link In this article 01What an unaudited org looks like 02Why this is a risk now 03What the Health Check covers 6 audit domains 🔐Security & access 🗄️Data quality ⚡Performance & scale 🏗️Org structure 📋Licenses & contracts 🔌Integrations & API Not sure where the org stands? Book the full six-domain audit or run the free self-assessment for an instant score. Book the Health Check → About the Author ST Sergey TrusovCEO & Salesforce Architect at TrueSolv
Time Tracking Salesforce App for Teams Who Bill by the Hour
The plan is in Salesforce. The reports are in Salesforce. The hours still don’t add up. A time tracking Salesforce app closes that gap by logging hours straight against the project, client, or case record the team already works from, so nothing gets guessed at the end of the week or copied over from another tool later. OUTSIDE SALESFORCE Spreadsheet Sticky note Guesswork True Time Tracker SALESFORCE Project & task hours Client hours & billing Vacation & holidays Every hour logged once, right where the record already lives. Three disconnected tools — one clean Salesforce record. Three tools that never agreed on the same number Most teams don’t actually lack a time tracking system. They have three or four of them, and none talk to Salesforce. A shared spreadsheet nobody fully trusts. A sticky note on someone’s monitor. A message that says “put me down for six hours on the Meridian account” sent from memory two days after the work happened. Every one of these lives outside the CRM, which means every hour logged there has already drifted from what actually happened. That drift moves in one direction, and it’s the wrong one. A project lead pulls a report from Salesforce expecting it to reflect reality and finds hours that were rounded up, rounded down, or simply estimated. Staffing decisions get made off numbers nobody fully believes, and the next project gets resourced on a picture of the last one that was never quite accurate to start with. How True Time Tracker works True Time Tracker removes the extra tool from that equation entirely. Hours get logged on tasks, projects, and clients directly inside Salesforce, right next to the records they describe, with no second login and no end-of-week reconstruction. What comes with it ⏱Hours logged straight against the task, project, or client record — no separate system to check, no copy-paste at the end of the week 📁Project and client details managed in one place, so nothing gets duplicated elsewhere and the report you pull on Friday matches the hours logged on Monday 📅Vacation and holiday days tracked alongside billable time, for a full picture of team capacity — not just who worked, but who was actually available 🔗Jira and GitLab activity connected in, so development work doesn’t need to be logged twice — it comes in from the tool where it was already recorded What this looks like in practice Picture a five-person consulting team billing three clients a week. Without a native tool, hours sit in a spreadsheet until Friday, get typed into Salesforce from memory, and rarely match the invoice a client eventually questions. With True Time Tracker, every hour is logged the moment the work happens, tied to the right client record, and ready for a report that same afternoon instead of the following Monday. The hours were always real. Now the record of them is too. Book a walkthrough of True Time Tracker through our contact form, and follow TrueSolv on LinkedIn and Instagram for more Salesforce tools built around how services teams actually work. SalesforceTrue Time TrackerTime TrackingSalesforce ToolsCRM Automation Share: LinkedIn Twitter / X Copy link In this article 01Three tools that never agreed 02How True Time Tracker works 03What this looks like in practice Hours still guessed at end of week? True Time Tracker logs hours straight against the Salesforce record the moment work happens. Book a walkthrough → What’s included ⏱Hours against tasks, projects, clients 📁Project & client in one place 📅Vacation + billable time together 🔗Jira & GitLab connected in About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
We Celebrated Seven Years the Way We Do Most Things
We are a distributed team across Tbilisi and Dubai, so there was never going to be one office with balloons taped to the ceiling. Instead, seven years got celebrated the way most of our workdays already happen — on a call, across time zones, and somehow still louder than expected. Here is what actually went down. TrueSolv — Year 7 Anniversary CallAugust 2026 · Full team · 1 video call 🎂7 years of Salesforce work 2countries on one call 3hours, no formal agenda 🇬🇪 Tbilisi, Georgia·🇦🇪 Dubai, UAE The format: games, not an agenda We made a deliberate decision not to structure the anniversary call around a retrospective deck or a metrics review. Seven years of those exist already. This one was structured around games, which turned out to be the right call. The format was loose: a full-team video call, a mix of people from both offices in the same frame, and three blocks of activity with no formal agenda between them. What we actually played The first block was company trivia — questions about the project history, the early years, the decisions that look obvious in retrospect and were genuinely uncertain at the time. The format was simple: a question, everyone answers, the person who gets it right gets to ask the follow-up question. Some questions were easy. Some were not. The one about which client project arrived with the strangest technical requirement — a Salesforce org that needed to track inventory for a museum, including items that had not been catalogued yet — produced a genuine debate about whether “null but billable” is a real data state. (The answer is yes, apparently, if the contract says so.) The second block was an online quiz platform — faster, more competitive, not limited to people who had been around long enough to know the company history. This levelled the playing field significantly and produced the discovery that our most competitive team member on a quiz platform is not the person anyone would have predicted. The third block was show-and-tell. Each person picked one thing from the past year — a project, a technical problem, a moment — and described it in two minutes. No slides. No preparation required. The two-minute constraint was the part that made it work: enough time to say something specific, not enough time to turn it into a presentation. Best moments from the anniversary callCompany trivia, unexpected answers, and the quiz that humbled some of us From company trivia 🏛️Which project had the strangest technical requirement?A museum inventory system that needed to track items that had not been catalogued yet. The resulting 20-minute discussion about whether “null but billable” is a valid CRM data state is now a recurring reference. 🤔What was the first Salesforce object we ever built a custom trigger for?Nobody got this right on the first guess. The people who joined in years 4 through 7 had to take it on faith that the answer was accurate. From the online quiz 🏆Most competitive team member on a quiz platformNot the person anyone would have predicted. They were very calm about winning. Suspiciously calm. 😐Highest-scoring moment in show-and-tell (informal)Someone sharing a debugging session where the bug turned out to be a missing comma in a JSON payload that took four hours to find. The room recognised it immediately. General observation 💡What a distributed team celebration actually isIt is not a party. It is a few hours where the work stops being the only thing people share. Seven years of that is a lot of shared context — and it turns out to be louder than expected when you put it all in one call. The part that is hard to describe to people who have not worked distributed A distributed team that has been working together for years accumulates shared context in a specific, gradual way. There are no hallway conversations. There are no off-the-cuff lunches. The shared context that builds in a co-located office — the running jokes, the inside references, the “you had to be there” stories — has to be built intentionally in a distributed one. What struck me about the anniversary call was how much of that context exists without anyone having planned it. Stories about the same project told from different angles by people who worked on it at different times. References to client situations that everyone understood without explanation. A team that has been doing good work together for long enough that the good work has become its own kind of shared language. That is not something you schedule into a company retrospective. It builds in the work, over time. Seven years is enough time to accumulate a lot of it. To everyone who has been part of this in any form — client, partner, or team member who moved on to something else — thank you. Seven years of this kind of work is not small. Follow us on LinkedIn and Instagram for more of what it is actually like working with a distributed Salesforce team. TrueSolvTeam CultureSalesforce Consulting7 Year Anniversary Share: LinkedIn Twitter / X Copy link In this article 01Games, not an agenda 02What we actually played 03Working distributed Anniversary call, at a glance 7 years of TrueSolv 2 countries, 1 call 3 game blocks, 0 slides About the Author DS Daria SavelievaSalesforce Consultant & Content Lead at TrueSolv
Your QBR Ended. Did Anyone Actually Write Down What Was Decided in Salesforce?
A quarterly business review ends. The participants close their laptops. The Salesforce event gets marked complete. The action items — the ones that were verbally agreed, the ones someone typed into their notes app, the ones that should drive the next 90 days of the account relationship — exist somewhere between four people’s memory and a shared document nobody will open again. Three weeks later, the account is flagged at risk. True Event Scheduler adds one thing to every QBR, renewal call, and executive meeting in Salesforce: a closed loop. QBR Lifecycle: Without vs. With True Event Scheduler ✗ QBR without True Event Scheduler 1QBR held. Significant prep, two hours of executive time, meaningful conversation.Meeting 2Salesforce event marked “complete.” Note field: “QBR held — good conversation.” No outcome captured.Same day 3Action items from the call exist in four different places: two note apps, one email thread, one Slack message.Day 1 4Account flagged as potentially at risk. Executive asks: “What was the outcome of the QBR?” Nobody can produce a definitive answer.Day 21 5Follow-up call scheduled to clarify what was decided three weeks ago. Relationship friction.Day 25 No outcome in CRM. Executive time wasted twice. Account risk undetected for 3 weeks. ✓ QBR with True Event Scheduler 1QBR held. Same prep, same executive time, same conversation.Meeting 2AE marks event complete. Required outcome field prompts selection: account is “At Risk — pricing concerns raised.”Same day 3Outcome triggers automatic tasks: priority follow-up for CS lead within 24 hours, executive alert for the AE’s manager.Automatic 4CS lead completes follow-up call. Outcome updated. Account risk is actively managed from day one.Day 2 5Executive reviews QBR dashboard. Account visible as At Risk with follow-up confirmed complete. Full picture, no surprise.Day 7 Outcome captured. Risk visible immediately. Executive time invested once. The QBR accountability gap A quarterly business review is a high-stakes, high-cost interaction. The account executive prepared for two hours. The customer success manager pulled together a health report. Two executives — one from each side — gave up a slot in their calendar. The call took 45 minutes. A significant amount of information changed hands. And then the Salesforce event gets marked complete with a note that says “QBR held — good conversation.” No outcome captured, no follow-up assigned, no record of what was agreed. The investment that went into the call produced exactly zero actionable data in the CRM. This is not a people failure. It is a system failure. The system does not require an outcome before the event can be closed. So none of those things happen reliably. What True Event Scheduler adds for executive meetings Required outcome field before close An event record cannot be marked complete without an outcome selection. For QBRs, the outcome options reflect the actual result of the conversation — not the generic “call completed” that native Salesforce offers. Renewed, At Risk, Expanded, Deferred, Needs Executive Follow-Up. Marking the event complete takes 30 seconds. The outcome is captured at the moment when everyone’s memory of the call is freshest, not three days later when nobody can remember. Automatic follow-up task creation from outcome An At Risk outcome creates a priority follow-up task assigned to the CS lead within 24 hours. A Needs Executive Follow-Up outcome creates a task assigned to the AE with an escalation to their manager. An Expanded outcome creates a task to log the expansion opportunity and begin the proposal process. The tasks are created automatically based on what was decided — not what someone remembered to add later. The practical result: the decision made in the QBR room produces a task in Salesforce before the participants have left the building. Executive visibility dashboard A single view of every QBR across the account base: the meeting date, the outcome selected, the follow-up tasks created, and whether those tasks have been completed. An executive reviewing account health at the start of a quarter can see in one screen which QBRs resulted in risk flags, which produced expansion opportunities, and which have follow-ups that have been open for 45 days. QBR Outcome Options — True Event SchedulerRequired selection before the event can be marked complete RenewedCustomer confirmed renewal intent. Timeline and pricing agreed or close to agreed.→ Creates task: log renewal Opportunity and initiate contract process At RiskConcerns raised — pricing, product gaps, competitor evaluation, satisfaction issues. Renewal not confirmed.→ Creates priority CS follow-up task (24-hour window) and manager alert ExpandedCustomer expressed interest in additional seats, products, or features. Expansion opportunity identified.→ Creates task to log expansion Opportunity and begin proposal process DeferredRenewal decision pushed to a later date — budget timing, stakeholder change, internal process delay.→ Creates follow-up task with deferred timeline and reason captured in notes Needs Executive Follow-UpIssues raised that require escalation beyond the AE — executive sponsor alignment, commercial terms, strategic concerns.→ Creates task assigned to AE with escalation to their manager, flagged for executive review Why this matters more at larger deal sizes At $15,000 ACV, a missed follow-up after a QBR is a missed opportunity. At $120,000 ACV, a missed follow-up after a QBR is a potential churn event that costs more than a year of CRM subscription fees to recover from — if it is recoverable at all. The accountability gap that True Event Scheduler closes is present at every deal size. The consequence of that gap compounds with deal value. A single at-risk enterprise account that went 45 days without appropriate follow-up because the QBR outcome was never captured is a specific, calculable cost. ⚡ SalesforceAcme Corp — Q2 QBR → Complete Event Q2 2026 Quarterly Business ReviewTrue Event Scheduler Date and timeJune 25, 2026 · 10:00 AM – 10:50 AM AttendeesSarah M. (AE) · James K. (CS) · Client: VP Operations + Director of IT QBR Outcome * required to complete Renewed At Risk Expanded Deferred Needs Executive Follow-Up Outcome notes *Pricing concerns raised — client comparing against competitor at 20% lower cost. VP Operations supportive but IT Director mentioned budget review in August. Follow-up needed
Salesforce MFA Enforcement July 2026
Salesforce is not asking anymore. Starting July 1 in production, users who open a report will need to re-verify their identity even if they just logged in. By July 20, every internal user in every production org will need multi-factor authentication — not as a recommendation, but as a locked system setting that admins cannot disable. Five enforcement changes, three deadline dates, and zero tolerance for orgs that are not ready. Date What changes Who it affects July 1 Step-up MFA on every reportAny user who runs or views a report is prompted to re-verify identity, even after a recent login. All orgs, not Shield-only. All users who access reports. Users not enrolled in MFA are blocked at this step-up prompt — not just at login. July 1 Phishing-resistant MFA for privileged usersSystem Admins and users with Modify All Data, View All Data, or Manage Users must switch to hardware keys or passkeys. Authenticator apps no longer qualify. System Administrator profile users, plus anyone with Modify All Data, View All Data, or Manage Users via permission set — not just via profile. July 13 Transaction Security Policies auto-created for Shield orgsShield orgs without a custom export TSP get one auto-created for exports over 10,000 records. Shield-licensed orgs only. Orgs with existing export TSPs are unaffected. Auto-created policies may need review before this date. July 20 Full MFA locked for all internal usersSalesforce locks the MFA setting. Admins cannot disable it. Any user not enrolled is blocked from login entirely. All internal users in all production orgs. No exceptions, no grace period. Unenrolled users cannot log in after this date. July 20 MFA Opt Out permission stops workingThe self-service exemption permission for automation and integration users ceases to function. Integration users and automation service accounts currently using the opt-out permission. Must file a Salesforce Support case before July 20 for a supported exemption. Change 1: Step-up MFA on every report — July 1 From July 1, any user who runs or views a report in Salesforce is prompted to verify their identity again, even if they authenticated at login minutes earlier. This applies to all reports, not just exports, and not just Shield-licensed orgs. It is platform-wide. The practical impact on end users is a second prompt in their session flow when they access report functionality. Orgs with high report usage — sales dashboards, weekly pipeline reviews, regular operational reporting — should communicate this change to their users in advance. A verification prompt that appears without warning reads as a potential security incident to users who were not expecting it. The enrollment implication is more significant: any user who accesses reports and is not enrolled in an MFA method will be blocked at this step-up verification. Enrollment must be complete before July 1 for report-heavy users specifically, not just before July 20 for the general rollout. Change 2: Phishing-resistant MFA for privileged users — July 1 System Administrators and users with Modify All Data, View All Data, or Manage Users permissions must switch to a phishing-resistant authentication method by July 1. An authenticator app — the method most admins currently use — no longer qualifies for these privilege levels. Phishing-resistant methods at GA include hardware security keys compliant with FIDO2 (YubiKey and similar devices) and passkeys stored on a trusted device. Biometric authenticators on modern devices qualify when configured as passkeys. The action required for admins right now is an audit of which users hold elevated permissions in production. The Admin profile is obvious. The less obvious group is permission sets that grant Modify All Data, View All Data, or Manage Users without giving the System Administrator profile — these users are subject to the same requirement and are frequently missed in pre-enforcement preparation. Change 3: Transaction Security Policies for report exports — July 13 Shield-licensed orgs that do not have a custom Transaction Security Policy governing report exports will have one automatically created by Salesforce on July 13. The auto-created TSP applies to exports over 10,000 records and adds a verification step or block depending on the default configuration. Orgs with Shield that have already configured export TSPs are unaffected. Orgs with Shield that have not configured them should review the auto-created policy before July 13 and determine whether the default behavior is appropriate for their specific export patterns. Auto-created policies are a starting point, not a final configuration. Change 4: Full MFA for all internal users — July 20 On July 20, Salesforce locks the Multi-Factor Authentication setting in all production orgs. The setting cannot be disabled by an admin after this date. Any internal user who is not enrolled in an MFA method is blocked from logging in until enrollment is completed. What gets blocked if users are not enrolled on July 20: complete login block for any internal user without an enrolled MFA method. They cannot log in at all — not to read email, not to view their opportunities, not to run a report. The fix is to complete enrollment, which takes time that may not exist in the middle of a blocked login incident. The recommended approach is to complete enrollment for all internal users before July 13 — one week before the final deadline — to allow time to address any enrollment issues before the lock takes effect. Change 5: MFA exemption permission stops working — July 20 The MFA Opt Out of Multi-Factor Authentication permission, which some orgs have used to exempt automation users and integration service accounts from MFA requirements, stops functioning on July 20. Integration users and automation service accounts that use this permission for their login flow must be handled through an alternative path before the deadline. The supported path for integration and automation users who require a login flow incompatible with MFA is a Salesforce Support case filed before July 20, documenting the specific use case and requesting an exemption through the supported process. The self-service permission-based exemption will not be available after enforcement. ⚠What gets blocked —
Salesforce Flow Orchestration is Free in Summer 26
Flow Orchestration used to cost extra. Now it does not. Starting with Summer ’26, Flow Orchestration runs are included in Enterprise, Performance, Unlimited, and Developer editions without usage-based limits. If you ruled it out before because of the pricing, that calculation is gone. Here is what Flow Orchestration actually does, and why it is worth a fresh look. What Flow Orchestration actually is A regular Flow handles a trigger and a sequence of automated steps. It runs, completes, and is done — typically in seconds, with no pause for a human to weigh in partway through. Flow Orchestration is built for a different category of process: multi-step, multi-user business processes that require coordination across people, systems, and time. The work needs to pause, wait for a specific person to make a decision, branch based on that decision, and continue — all in a monitored, auditable way, potentially over hours, days, or weeks. The distinction matters because many processes that orgs currently handle through a combination of email, manual task assignment, and someone remembering to follow up are exactly the kind of process Orchestration is built for. The reason most orgs have not built these in Salesforce is that Orchestration previously carried a usage-based cost that made it hard to justify for internal process automation rather than customer-facing workflows. Characteristic Regular Flow Flow Orchestration Duration Runs and completes in seconds. No pause for human input mid-process. Can span hours, days, or weeks — pauses at human steps and resumes when action is taken. Human involvement Limited to triggering the flow or responding to a single approval step bolted on separately. Built-in stages where specific people are assigned tasks, make decisions, and the process branches based on their input. Visibility No persistent status view. Once running, you cannot easily see “where” the flow currently is. Defined stage model — anyone can see which stage a process instance is currently in and who owns it. Multi-department coordination Difficult — typically requires chaining multiple flows and manual handoffs between departments. Native — parallel and sequential stages across different teams with a single coordinated process instance. Best for Record updates, notifications, single-step automations, data validation, immediate actions triggered by a record change. Onboarding processes, approval chains, multi-department workflows — anything where “who does this next and when” is the core challenge. Cost (Summer ’26) Included in all editions, as always. Now free Included in Enterprise, Performance, Unlimited, and Developer editions — no usage-based limits. A simple orchestration, structurally The shape of an orchestration is consistent regardless of the specific process: a system step does something automatically, a human step pauses and waits for a person to act, the orchestration branches based on what that person decided, and the process continues — potentially with more human steps, more branches, and a final system step that records the outcome. A Simple Flow Orchestration — Four Stages Stage 1 System action e.g. create record AUTOMATED Stage 2 Human approval Manager reviews and decides PAUSES & WAITS Stage 3 System action e.g. update fields AUTOMATED Stage 4 Branch → Approved path → Rejected path OUTCOME RECORDED Status, owner, and stage are visible to anyone checking on the process — not just whoever is currently assigned. What makes this different from a Flow with an Approval Process attached is the structure and visibility. Orchestration gives you a defined stage model — each stage has a clear owner, a clear set of possible outcomes, and a status that is visible to anyone checking on the process, not just the person whose turn it currently is. For processes spanning multiple departments, that visibility is often the missing piece. Three workflows worth building now that it is free New employee onboarding across IT, HR, and the hiring manager Onboarding touches multiple departments with sequential and parallel dependencies: IT needs to provision accounts, HR needs to complete paperwork, the hiring manager needs to prepare the first-week schedule, and some of these steps depend on others completing first. An orchestration can sequence IT provisioning after HR confirms the start date, run HR paperwork and manager prep in parallel, and surface a single status view to whoever is coordinating the new hire’s first day. The alternative — the current state at most orgs — is a checklist in a shared document and a series of Slack messages asking whether each step is done yet. Orchestration replaces the asking with visibility. Contract approval chain with parallel legal and finance review A contract above a certain value needs review from legal and finance before it reaches an executive for final sign-off. Legal and finance review can happen in parallel — neither depends on the other — but the executive sign-off step depends on both being complete. Orchestration models this directly: a parallel stage for legal and finance, a convergence point that waits for both to complete, then a sequential executive approval stage. The audit trail shows who reviewed what and when, without anyone needing to track it manually. Deal desk workflow for non-standard pricing approvals Non-standard pricing requests — discounts above a threshold, custom payment terms, non-standard contract clauses — typically need sign-off from sales leadership, finance, and sometimes RevOps, in an order that depends on the specific request. An orchestration can route the request to the right combination of approvers based on the deal characteristics, track where it currently sits, and notify the rep when a decision is made. The business value here is speed: deal desk requests that currently take days because they sit in someone’s inbox move faster when the orchestration actively routes and tracks them, and the rep has visibility into where the holdup is rather than just waiting. 3 Workflows Worth Building Now That Orchestration Is FreeProcesses most orgs currently run on email, shared docs, and hoping someone follows up 👋New employee onboardingIT provisioning, HR paperwork, and hiring manager prep — sequenced and parallelised with a single status view for whoever is coordinating the new hire’s first day.Stages: HR confirms start date