Connected Apps Are Being Retired in Salesforce
Starting with Spring ’26, Salesforce disabled the creation of new Connected Apps by default across all orgs. Your existing ones still work for now. But the direction is clear: External Client Apps are the future, and the clock is running. This guide covers what changed, why Salesforce made this move, what External Client Apps actually give you, which apps are and are not affected, and a step-by-step migration walkthrough through App Manager. The second half is a structured checklist for the audit before you migrate and the testing after. The TLS certificate changes happening in the same release are covered at the end, because both come from the same security-first motivation. Spring ’26 Migration Timeline & TLS Certificate Phase-Down Connected Apps → External Client Apps 1 Winter ’26 New Connected App creation disabled by default in new orgs Opt-in 2 Spring ’26 New creation disabled across all orgs — Support request required Enforced 3 Summer ’26 Expected enforcement deadline — plan migration before this Deadline 4 Summer ’26 Triple DES for SAML SSO stops working completely Hard Stop TLS Certificate Lifespan Phase-Down (CA-signed certificates only) A Until Mar 14, 2026 Max lifespan 398 days (previous standard) B Mar 15, 2026 Max lifespan drops to 200 days Now C Mar 15, 2027 Max lifespan drops to 100 days Plan for D Mar 15, 2029 Max lifespan drops to 47 days — automation required Automate Why Salesforce is making this change Connected Apps have been part of Salesforce for over a decade. If you have ever set up OAuth for a third-party integration, configured Data Loader, or connected a custom web application to the Salesforce API, you have used one. They are everywhere, and most of them work fine. The problem is not the apps that are configured properly. The problem is the ones that are not, and the architecture that makes unsafe configurations easy to create. By default, Connected Apps allow any API-enabled user in an org to self-authorise a connection to an external application, without admin approval. That is how phishing and vishing attacks that targeted Salesforce orgs worked: trick a user into authorising a malicious Connected App, and the attacker has API access to the org’s data. Salesforce responded by tightening this behaviour, but the structural issue remained. External Client Apps take a different starting position. They adopt a closed security posture by default. Access is not granted unless an administrator explicitly permits it. Furthermore, the architecture separates developer configuration from admin policy, which means a developer building an integration cannot inadvertently override security settings that the admin put in place. What changed in Spring ’26, specifically The rollout has been gradual. In Winter ’26, Salesforce disabled Connected App creation by default in new orgs, with an option for admins to re-enable it manually. Spring ’26 tightened that further: new Connected App creation is now disabled across all orgs, including existing ones. Getting the ability back requires a Salesforce Support request, and Salesforce has been clear that this option will eventually disappear entirely. Two categories of Connected Apps are not affected by this change. Connected Apps created as part of a managed package continue to work and can still be created in that context. Connected Apps used for Slack in the legacy Agentforce Builder are also excluded. Everything else follows the new default. Any new integration from Spring ’26 onward must be built as an External Client App. ⚠ What happens if you try to create a new Connected App without a Support request The New Connected App button no longer appears in App Manager — the option is gone from the UI entirely. Attempting to create one via the Metadata API returns an error. There is no workaround inside the platform. Any new integration built after Spring ’26 that requires its own OAuth client must use an External Client App instead. If a specific business case genuinely requires a new Connected App, you must open a Salesforce Support case and explicitly request the capability. Salesforce may or may not grant it, and this option will be removed in a future release. What External Client Apps offer that Connected Apps do not External Client Apps are not just Connected Apps with a new name. The differences are architectural, and several of them matter a lot depending on how your org is set up. Separation of developer settings and admin policies In a Connected App, the developer configuration and admin security policies live in the same record. A developer with edit access to the Connected App can change the OAuth scopes, the IP restrictions, and the session policies. In an External Client App, those roles are separated. Developers manage the technical settings; admins manage the access policies. Neither can override the other without the appropriate permission. For ISVs and AppExchange partners, this matters enormously. It means the admin installing your package can control how it behaves in their org without touching the underlying app configuration. Second-generation packaging support External Client Apps are designed specifically for second-generation packaging, or 2GP. Connected Apps technically work with 2GP, but the process required manual steps that were fragile and time-consuming. ECAs package cleanly, distribute correctly, and integrate naturally with source control and CI/CD pipelines via the Metadata API. For admins managing integrations rather than building packages, the practical difference is that ECAs behave more predictably in sandboxes and scratch orgs. Scratch Org support for External Client Apps was added in Spring ’26, which makes the developer testing cycle considerably cleaner. Closed security posture by default A new External Client App is not accessible to any user until an administrator explicitly grants access. There is no self-authorisation pathway by default. This is the core security difference from Connected Apps, and it is the reason Salesforce is moving in this direction. What ECAs do not yet support Two important gaps remain. External Client Apps do not support the Username-Password OAuth flow. If any of your existing Connected Apps use this flow, you cannot migrate them
The SaaS Salesforce Setup Roadmap
Setting up Salesforce for a SaaS company is not the same as setting it up for a real estate agency or a professional services firm. Subscriptions, trials, renewals, MRR, none of that exists in a default Salesforce org. Getting it right means building a system that reflects how SaaS revenue actually works: from the first lead through to the second and third renewal. This is the setup roadmap used with SaaS companies at every growth stage. SaaS Salesforce Setup — Three-Phase Roadmap Phase 1 Pipeline Control 2 – 15 people SaaS-configured objects (MRR, ACV, trial stages) Website lead capture via Web-to-Lead Email and calendar auto-sync Basic quota tracking Clean data migration Foundation Phase 2 Process & Prevention 15 – 30 people Contract Management object New Business vs Renewal quota split Round Robin lead assignment Calendly integration Outbound activity logging Scale-Ready Phase 3 Revenue Intelligence 30 – 50 people Product data via Segment / PostHog Stripe subscription sync Automated Renewal Opportunities Quotes object and PDF proposals RevOps forecasting Fully Connected Build in sequence — each phase is the foundation for the next The roadmap breaks into three phases, each tied to the problems that appear at a specific team size. Phase 1 is about getting your data into one place and your pipeline under control. Phase 2 is about building process before things break. Phase 3 is about connecting your product and revenue data so the whole system works without manual intervention. Most SaaS companies skip Phase 1 entirely, configure a few things in Phase 2, and then wonder why Phase 3 never delivers the visibility they expected. ⚠ What breaks when you skip Phase 1 and go straight to Phase 3 No clean data foundation Stripe sync and product events write to duplicate or incomplete records. Automation fires on bad data. No stage or quota logic RevOps forecasting has nothing reliable to forecast. Pipeline reviews become guesswork in a different tool. No email or activity sync Automated tasks get created on leads with no interaction history. Reps ignore them because there is no context. No Contract Management object Renewal Opportunity automation has no subscription terms to read. The automation cannot trigger correctly. No team training or adoption The Phase 3 system sits unused while the team works in spreadsheets. The investment does not produce results. Phase 1 (2–15 people): Get the pipeline under control At this stage, most SaaS teams have contacts in a spreadsheet, deals tracked in someone’s head, and follow-up happening through email threads. Salesforce at Phase 1 has one job: get everything into one system and make it usable for a small team with no dedicated ops person. Configure core objects for SaaS context A default Salesforce org is built for transactional sales. The standard Opportunity fields assume a one-time deal. For SaaS, you need subscription-aware fields from the start. That means adding fields for Monthly Recurring Revenue, Annual Contract Value, trial start and end dates, subscription tier, and billing interval. The Lead object also needs updating. Source fields should reflect where SaaS leads actually come from: product sign-up, inbound form, G2 review, or referral. Furthermore, the Opportunity stage names matter more than most teams realise. Default stages like ‘Prospecting’ and ‘Perception Analysis’ mean nothing in a SaaS context. Replace them with stages that reflect your actual sales motion: Trial Active, Demo Scheduled, Proposal Sent, Closed Won, Closed Lost. Set up lead capture from your website Every SaaS website has a form or a trial sign-up button. In most early-stage companies, those leads land in an email inbox or a spreadsheet. Connecting your website forms directly to Salesforce via the Web-to-Lead feature takes an afternoon and immediately removes the manual logging step. For trial sign-ups specifically, the connection between your product and your CRM is worth building early. Even a simple webhook that creates a Lead when a user signs up gives your team visibility into who is in the product — before you build anything more sophisticated. Connect email and calendar Manual activity logging is the reason most CRM data goes stale within three months of implementation. When reps have to log every call and email by hand, they stop doing it. Salesforce Inbox or the standard Gmail and Outlook integrations sync email threads and calendar events automatically. As a result, every Lead and Contact record shows a complete interaction history without anyone updating it manually. That is the baseline that makes everything else in the CRM trustworthy. Set up sales quotas early Most founders skip quota configuration at Phase 1 because the team is too small. That is a mistake. Setting up quota tracking in Salesforce from the beginning creates a performance culture before the team grows. Specifically, it gives you a reference point when you are making your first sales hire: what does good look like, and what is the current baseline? Quota configuration at this stage is simple. Assign monthly or quarterly revenue targets per user, and build a single Salesforce report that shows actuals versus target. That is all you need at 2–15 people. Data migration: clean before you move Almost every SaaS company arrives at Salesforce with a mix of HubSpot exports, Notion tables, and Airtable bases. Before migrating any of that data, spend time cleaning it. Remove duplicates, standardise company names, and decide which fields you actually need to carry over. Moving messy data into Salesforce does not fix the mess. It just moves it into a more expensive system. A clean migration of 500 accurate records is considerably more useful than importing 3,000 records with no confidence in the data. Phase 1 — Pipeline Control Checklist 2–15 people Core object fields configured — MRR, ACV, trial dates, subscription tier on Opportunity; SaaS lead sources on Lead Opportunity stage names updated — replaced with SaaS stages: Trial Active, Demo Scheduled, Proposal Sent, Closed Won, Closed Lost Web-to-Lead connected — website form and trial sign-up button create Lead records automatically Email and calendar sync live — Gmail or Outlook integrated;
How to Find Your SaaS PQL in Salesforce
Product-led growth gets talked about as a marketing strategy. It is actually a data strategy. The moment a user signs up for your free trial, they start telling you exactly how likely they are to pay, through every click, every feature they open, and every session they skip. Most SaaS sales teams have no idea any of that is happening. None of it is in their CRM. What is a Product-Qualified Lead? A Product-Qualified Lead, or PQL, is a user who has reached a meaningful milestone inside your product. They activated a key feature, hit a usage threshold, invited a teammate, or upgraded their storage. Whatever the milestone is, they are doing the thing your product is designed to do. That makes them different from every other lead type in your funnel. A Marketing-Qualified Lead clicked an ad or downloaded an ebook. A Sales-Qualified Lead filled out a demo form. Neither has actually used your product. A PQL has, and in most PLG companies, that difference shows up as a 3% conversion rate versus a 25% one. Furthermore, PQLs are consistently underused. Not because companies do not want to act on them, but because the signal lives somewhere the sales team cannot reach. Why the PQL signal gets wasted without CRM integration Product analytics tools capture this data well. Segment, Mixpanel, PostHog, and Amplitude track every session, every feature interaction, and every drop-off point with precision. The dashboards are detailed. The data is there. However, your sales team is not in those dashboards. They are in the CRM. And in most PLG SaaS companies, those two systems do not talk to each other. The result is a structural disconnect. Your product knows which users activated three core features in a seven-day trial. Your reps are calling people who downloaded a whiteboard template six weeks ago. Meanwhile, the user who is two steps from converting sits uncontacted in your product database, not in your pipeline. This is not a prioritisation problem. It is a data infrastructure problem. Specifically, it is fixable. PLG Trial-to-Paid Funnel in Salesforce Trial Signup by source & channel Activation key feature milestone reached PQL Trigger usage threshold, invite, or score met Sales Action rep task auto-created in Salesforce Closed-Won Here is what four common PQL triggers look like in practice. 1. Trial activation trigger A user activates three core features within seven days of signing up. Salesforce creates a task for a rep to reach out with a targeted expansion message. The rep sees the activation data directly on the Lead record. 2. Churn risk alert A user’s engagement drops below their baseline for 14 consecutive days. Salesforce creates a CS alert before the churn event. The CS team can intervene with full context on what the user did and did not do. 3. Account expansion signal Five or more users at the same account invite colleagues during the trial period. Salesforce scores the Account higher and moves it into an expansion workflow automatically. 4. Free-to-paid attribution A free-to-paid conversion is tracked as a closed Opportunity, connected to the original trial Lead record. Marketing attribution becomes real, not estimated. Situation Without PQL data With PQL data in Salesforce Who reps contact first Demo form leads, regardless of product activity Users who activated key features, ranked by engagement score What reps see on a Lead record Name, email, company, source Features activated, sessions logged, days since last login, PQL status Churn detection Customer cancels, CS finds out after the fact Usage drop triggers CS alert at day 14, before churn event Free-to-paid attribution Estimated or modelled based on last-touch channel Closed Opportunity linked directly to original trial Lead record Account expansion signals No visibility until a user reaches out or upgrades manually Automatic score increase when 5+ teammates invited during trial PLG funnel visibility Sign-up volume and revenue, nothing in between Full funnel: signup, activation rate, PQL rate, closed-won from trial How to build this in Salesforce The most practical starting point is a set of Custom Fields on the Lead or Contact record that reflect product activity. You do not need a full Customer Data Platform to get started. You need a clean data feed and clear trigger logic. 3 PQL triggers worth setting up first 1 Feature activation trigger User activates 3 or more core features within 7 days of signing up. This is the clearest signal that the product is working for them, and the highest-intent moment to start a conversation. Trigger: 3 features in 7 daysAction: Rep task created in Salesforce 2 Churn risk trigger User engagement drops below their personal baseline for 14 consecutive days. Acting at day 14 gives CS enough lead time to re-engage before the user mentally cancels. Trigger: 14-day usage dropAction: CS queue alert in Salesforce 3 Account expansion trigger Five or more users from the same account invite colleagues during the trial period. Team adoption during trial is one of the strongest predictors of a paid conversion at the account level. Trigger: 5+ teammate invitesAction: Account score increase + expansion workflow Step 1: Define your PQL criteria Before any configuration, decide what product-qualified means for your specific product. Pick two or three behaviours that correlate with paid conversion in your existing data. Common examples include activating a specific feature, reaching a usage volume threshold, or completing an onboarding checklist. If you do not have conversion data yet, start with Salesforce Trailhead’s PLG resources or the Salesforce Admins blog for benchmark guidance on typical SaaS activation signals. Step 2: Connect your product data to Salesforce The most common paths are a native integration from your analytics tool, a Salesforce-connected webhook from your product backend, or a middleware tool like Segment Connections or Census. Each approach writes product events into Salesforce fields or Custom Objects. Step 3: Build the trigger logic in Salesforce Flow Use Salesforce Flow to create the automation. When a product field meets your PQL criteria, Flow triggers an action. That action
10 Salesforce Automations Every SaaS Team Should Have
Salesforce is not magic. Out of the box, it is a database with a nice interface. What makes it actually useful for a SaaS company is the layer of automation built on top of it .
Your reps are not losing quota without Salesforce Time Tracking
Time disappears into meetings, emails, and CRM updates that nobody tracks
Salesforce Release Readiness Playbook
Three times a year, Salesforce updates every org on the planet. Most of the changes are invisible. Some are not. The ones that are not tend to surface in the worst possible way: a sales rep cannot save a quote, a service case stops routing, a validation rule that worked yesterday throws an error today. This playbook gives leaders a lightweight process that reduces that risk without turning every release into a two-week internal project. The goal is a repeatable routine that your team can run in a few focused hours per cycle. What leaders should demand each release Most Salesforce release problems are not caused by the platform update itself. They are caused by nobody reviewing what the update does before it reaches production. Salesforce publishes release notes weeks before each production rollout. Sandboxes upgrade to the preview release before production does. That window exists specifically so teams can test. Most organisations do not use it, and then wonder why the release caused a problem. The minimum standard a leader should hold the team to each release: Release notes reviewed someone with platform knowledge has read the notes and flagged updates relevant to your org’s configuration, active automations, and critical workflows. Enforced updates identified Release Updates that Salesforce is auto-enabling in this cycle are listed and tested in sandbox before the production date. Critical business processes tested the flows, approvals, and integrations that revenue depends on have been validated in the updated sandbox. Rollback plan exists if something breaks in production after the release, the team knows what to do and who to call. That is not an extensive programme. It is four questions. If the answers exist and are documented before every production release, the org is in significantly better shape than most. Release updates and the testing workflow Release Updates are the subset of each Salesforce release that matters most for operational risk. These are platform changes that Salesforce will enforce, either optionally now or mandatorily in a future release. Skipping them does not make them go away. It means you find out what they break when Salesforce turns them on without your input. The testing workflow for each release cycle follows the same sequence regardless of release size. The sandbox preview window is the most valuable and most ignored step in this sequence. Sandboxes on preview instances upgrade before production. That gives teams a real-world environment with their own configuration to test against the new release. Using it is not optional for any organisation where Salesforce underpins revenue-critical processes. For enforced updates specifically, the standard is to test them as early in the preview window as possible, not the week before production. An enforced update that breaks an automation needs time to fix. Testing it late removes that time. Communication plan for users Users who encounter unexpected changes in Salesforce without any warning lose trust in the system faster than any feature can rebuild it. A communication plan for each release does not need to be complex. It needs to exist and it needs to reach the right people before the change lands. The communication model that works for most organisations has three components. Pre-release notice sent one week before production. Covers what is changing, which teams are affected, and where to get help if something looks wrong. Plain language, no technical jargon. Release day confirmation a short message confirming the release has gone live and whether everything is working as expected. If there are known issues, state them and give a resolution timeline. Post-release summary sent within a week. Highlights any new features that users can take advantage of, and closes the loop on any issues that were reported. The teams that most frequently need advance notice are sales, service, and anyone using Salesforce daily for revenue-generating work. IT-only communication is not enough. If a change affects how a sales rep closes a deal or how a service agent resolves a case, those people need to know before it happens, not after. For security updates, the communication should also include a brief explanation of why the change is happening. Users who understand the reason for a change adopt it more readily than users who experience it without context. Change management for security updates Security updates in Salesforce releases deserve specific attention because they carry compliance implications and because the consequences of ignoring them accumulate. An update that Salesforce marks as auto-enforced in a future release will be enforced whether or not the org is ready. The only choice is whether to be ready on your timeline or Salesforce’s. Recent releases have included mandatory enforcement of OmniStudio security flags, changes to session handling in outbound messages, the deprecation of Connected Apps in favour of External Client Apps, and certificate lifespan changes that will eventually reduce rotation windows from 398 days to 47 days. Each of these required an action from technical teams. None of them were optional in the long run. The change management approach for security updates follows this pattern: Identify the enforcement date not the release date. The enforcement date is when the behaviour changes in production regardless of org settings. Assess the impact which integrations, components, or user flows are affected. This requires someone with platform knowledge to test in sandbox before the enforcement date. Assign an owner security updates should have a named person responsible for testing and remediating, not just a team or a backlog item. Communicate to affected system owners integration owners and third-party vendors may need to make changes on their side. They need to know before the enforcement date, not after. Document the change what changed, what was tested, what the outcome was. This matters for audit trails and for explaining the change to regulators or internal compliance teams if asked. Create an owner per release stream Release readiness fails most reliably when nobody owns it. When the admin is responsible for their regular workload and release readiness at the same time, without protected time or a
How To Choose A Salesforce Partner In 2026
Every Salesforce partner in 2026 has a deck. Slides about transformation. Words like agentic and data-native and AI-first. All of them sound prepared. Very few of them are asking about your business before they start selling you their methodology. Choosing wrong costs more than the invoice. It costs the months of internal time spent managing a partner that was never the right fit, the rework that follows a go-live nobody was proud of, and the political capital burned explaining to leadership why the CRM still does not do what it was supposed to do. The market in 2026 is noisier than it has ever been There are over two thousand registered Salesforce consulting partners globally. A significant portion of them have restructured their positioning in the last eighteen months to lead with AI. Some of them have earned that positioning. Others have added the word Agentforce to their website and called it a capability. The noise is not the problem. The problem is that buyers have less time to filter it than ever, and the signals that used to indicate quality, certification counts, tier badges, years in the ecosystem, are no longer sufficient differentiators on their own. A Summit-tier partner with eight hundred certified professionals can still assign your project to a team that has never solved a problem like yours. The right question is not which partner is most impressive. It is which partner is most likely to deliver the specific outcome your organisation needs, at the pace you need it, without creating a dependency you cannot get out of. Start with business alignment, not technical credentials The first conversation with a prospective partner should not be about their methodology. It should be about your business. What are the actual outcomes you need Salesforce to produce. Not features, not clouds, not integrations. Outcomes. A partner worth working with will ask what success looks like in twelve months and push back if the answer is vague. They will want to understand your sales motion, your service model, your data landscape, and your internal capacity before they suggest a solution architecture. If a partner has already drafted a proposal before understanding any of that, the proposal is not for your business. It is for the last business that looked roughly similar. Business alignment means the partner understands the commercial problem you are trying to solve and can connect every element of the implementation to that problem. It means they will tell you when a feature you asked for does not actually solve the problem, rather than building it because it was in scope. That kind of honesty is less common than it should be and considerably more valuable than a polished slide on transformation. Time-to-value is a strategy question, not a project management question Most Salesforce implementations take longer than planned. Some of that is scope change. Some of it is data quality problems nobody anticipated. Some of it is a partner that builds for elegance when the business needed something working by the end of the quarter. Time-to-value as a selection criterion means asking prospective partners how they sequence delivery. Do they phase the work so users get something useful early, or do they build the complete solution and hand it over at the end of a long engagement. The second model is fine for certain types of projects. For most CRM implementations, where adoption depends on users seeing value before they form opinions about whether the system works, phased delivery with early wins is materially better. Ask specifically for examples where a partner delivered measurable business value within the first sixty to ninety days of a project. What did that look like. What was the business outcome. If they struggle to answer with specifics, the concept of time-to-value may be on their website but not in their delivery approach. What AI and data depth actually means in a partner context Every partner claims AI capability in 2026. The useful distinction is between partners who can configure Agentforce features and partners who can design an AI strategy that is grounded in how your data is structured, how your processes work, and what your users will actually adopt. The first group can get Einstein features switched on. The second group can tell you why those features will produce poor outputs if the underlying data has not been unified, why a particular agent use case will not work in your service model without process redesign, and what the governance model for AI-generated content needs to look like in your industry. A straightforward way to test this is to ask a prospective partner about a situation where they recommended against an AI feature a client wanted to deploy. If the answer involves a conversation about data quality, user trust, or process readiness rather than just technical constraints, that is a partner operating at the right level of depth. If they have never had that conversation, they are likely saying yes to everything and hoping the outcomes follow. On Data Cloud and Zero Copy specifically, the partner should be able to explain the trade-offs between ingestion and federation without prompting. They should have a position on identity resolution at scale and know where it works well versus where it produces frustrating results. Platform enthusiasm is not the same as platform knowledge. Risk reduction as a selection criterion Risk in a Salesforce implementation comes from several predictable directions. Scope that was never clearly defined. A project team that is strong in presales and thin in delivery. Technical debt from a previous implementation that nobody fully disclosed. Data migration that was underestimated. Change management that was treated as a training exercise rather than an organisational commitment. When evaluating a partner, ask directly how they handle each of these. Not in general terms. With specific examples from projects they have delivered. A partner that has never dealt with a troubled legacy org, a difficult data migration, or a client whose internal teams were not aligned going
Data 360 Lineage For Trusted Numbers
Two reports. Two very differentnumbers. One very uncomfortable meeting. That scenario plays out in revenue reviews, board updates, and pipeline calls more often than most teams admit. When it does, the instinct is to find the right number. The better instinct is to find out why two different numbers existed in the first place. What lineage actually solves in executive reporting The word lineage sounds technical (and maybe a bit historical), but the problems it solves are completely opposite of it. When a metric is wrong, or when two teams are working from different versions of the same metric, the question that matters is not which number is correct. It is: where did this number come from, what touched it along the way, and when did it last change. Lineage answers that question. It creates a traceable record from source data through transformations to the final figure that appears in a report or dashboard. Without it, root-cause analysis turns into a conversation where everyone points at a different system and nobody can prove anything. For decision makers, lineage is the difference between a reporting dispute that takes three days to resolve and one that takes three hours. How to operationalize lineage in governance Lineage by itself is a record. The practical starting point is mapping critical KPIs to their upstream sources. Not every metric needs deep lineage documentation. The ones that drive decisions, that appear in board reporting, that tie to revenue targets or customer commitments, those need a clear owner, a known source, and a documented transformation path. Once that map exists, the next step is defining what triggers a review. A source schema change. A calculation update. A new data connector going live. These are the moments when lineage documentation needs to be updated and when stakeholders need to know that a metric may have changed its meaning even if the number looks similar. Building this into standard change management processes is what separates teams that prevent reporting disputes from teams that spend Monday mornings resolving them. Who owns sources, transformations, and activation One of the more uncomfortable questions lineage surfaces is ownership. When data moves from a source system through a transformation layer and into a report or segment, each step should have a named owner. In practice, it often does not. Source data is owned by whoever manages the integration. Transformations were built by a developer who may no longer be on the team. The report is owned by whoever uses it most frequently, which is not the same as owning the data behind it. Data 360 supports explicit ownership assignment across sources, calculated insights, and activation targets. The governance value of that is not just administrative tidiness. It means that when a number changes unexpectedly, there is a clear escalation path. Someone is accountable for each layer. For RevOps and IT leaders, building that ownership map into onboarding for new data assets is a significantly more effective practice than reconstructing it after a reporting incident. Change control for analytics and segments Segments built in Data 360 can drive marketing journeys, sales prioritization, service routing, and AI agent behavior. When a segment definition changes, the downstream effects can be substantial. A change to an audience filter might quietly exclude a large group of high-value accounts from a nurture sequence. A modified calculation might shift how pipeline is categorised in forecasting. Change control for analytics assets follows the same logic as change control for code. Document what changed. Note who approved it. Record what the definition was before. Make it recoverable. Data 360 Unified Lineage gives this process its foundation by logging transformations and activation events. The approval workflow and the communication to stakeholders still requires a deliberate governance decision. Validation checks before activating new data A new data source going into production without validation checks is a common source of metric drift that nobody notices for weeks. The ingestion works. The records land. The numbers look plausible. But the field mapping is slightly off, the identity resolution rules do not account for a quality issue in the source, and slowly the unified profile becomes less accurate than the system it was meant to improve. Adding validation checkpoints before activating new data is not a significant overhead. It is a comparison of expected record counts, a check on field completeness, a review of identity resolution match rates before the new source is used in reporting or segmentation. Building this into the activation workflow rather than treating it as an optional QA step is what keeps lineage trustworthy over time. A lineage record that shows a clean path through a poorly validated source is not governance. It is a well-documented mistake. What decision makers should prioritize Reporting trust is a business problem with a governance solution. The technical capabilities to track, audit, and govern data from source to activation exist in the platform. What requires a leadership decision is the commitment to build ownership, change control, and validation into standard operating practice rather than treating them as documentation exercises that happen after something breaks. The organizations that do this well tend to share one common trait. They decide that a reporting dispute costs more than the governance process that prevents it, and they act on that before the dispute happens rather than after. Map critical KPIs to their upstream sources and assign a named owner to each layer Define what events trigger a lineage review and communicate changes to stakeholders proactively Add validation checks to the activation workflow so new data earns its place in reporting before it influences decisions Trust in data improves when data has a paper trail, and a paper trail only exists if someone decided it was worth building. TrueSolv can build a lineage-first reporting governance model for your Salesforce and Data 360 environment. Follow our newsletter for data and CRM operations topics. Contact us.
Salesforce External Client Apps Integration
Most Salesforce orgs have integrations that nobody fully owns. They were built by a consultant who left, configured by an admin who no longer remembers the details, and authenticated with credentials that nobody rotates. They work, so nobody touches them. But now Salesforce just made it a lot harder to ignore. The integration sprawl nobody talks about When teams evaluate their Salesforce stack, they focus on licences, features, and adoption. Integrations sit in the background doing their job until they do not. Then everyone scrambles to find the person who built it, locate the credentials, and understand what it even does. This is common. A mid-size org running Salesforce for several years typically has dozens of active integrations. ERP connectors, marketing platforms, data enrichment tools, internal APIs, partner feeds. Each one was set up for a reason. Very few of them were set up with a clear owner, a documented auth pattern, or a rotation schedule. Shared credentials mean a breach in one system can pivot into Salesforce. Unused integrations with live tokens are open doors. Integrations running on admin user accounts are a compliance issue waiting to surface. Why Connected Apps became a governance headache Connected Apps have been the standard way to give external systems access to Salesforce for years. They work. But they were built for a simpler era when integration landscapes were smaller and security expectations were lower. The core problem with Connected Apps at scale is visibility. They are globally available by default, meaning any external system can attempt to authenticate against your org once a Connected App exists. Developer settings and admin policies were intertwined, making it difficult to separate who was responsible for what. And because they were easy to create, orgs ended up with a lot of them, many with broader OAuth scopes than the integration actually needed. The result is a long list of Connected Apps in Setup, some active, some dormant, most with unclear ownership, and a few with permissions that made sense in 2019 and look alarming today. What External Client Apps actually fix Salesforce introduced External Client Apps as the next generation of integration framework, and the design decisions reflect real governance priorities rather than just technical modernisation. The most important change is the default posture. Unlike Connected Apps, an External Client App cannot be used to authenticate against an org unless it is explicitly installed or defined there. Shadow connections, where an external tool authenticates without an architect or admin ever deliberately permitting it, are no longer possible with this model. The second significant change is role separation. Connected Apps blurred the line between the developer who built the integration and the admin who managed it. External Client Apps formalise two distinct configuration layers. Developers define what the app is capable of. Admins in each org control when and how it is used. That separation creates clear ownership, which is what governance actually requires. Third, External Client Apps are built for modern authentication patterns. Older flows that embedded credentials directly are no longer supported. The model enforces explicit client identity, modern OAuth flows, and clear boundaries between authentication, authorisation, and policy enforcement. What this means for your integration register The shift to External Client Apps is an opportunity to build something most orgs are missing: a documented integration register. Not a spreadsheet someone made two years ago. An actual record of every system connecting to Salesforce, with the following information attached to each entry: System name and business purpose. Integration owner, both technical and business-side. Authentication type and OAuth flows in use. Scopes granted and whether they are proportionate to the function. Token rotation schedule and last rotation date. Whether credentials are shared with other integrations or systems. Risk classification: what data can this integration read, write, or delete. This is not an extensive project. Most of the information already exists somewhere. The work is centralising it, assigning owners, and making it part of standard operational practice rather than a one-time audit exercise. Building an approval flow for new integrations One pattern that pays off quickly is a lightweight approval process for new integrations before they go live. Not a bureaucratic gate, but a structured conversation that covers the basics. What does this integration need to access in Salesforce and why. Which authentication flow will it use. Who owns it on both the vendor side and the internal side. What is the plan when credentials need to rotate or the vendor relationship ends. External Client Apps support this pattern well because the separation between developer configuration and admin policy means there is a natural checkpoint. The integration has to be explicitly admitted into the org. That moment is the right time to answer these questions rather than after the fact. Token rotation and monitoring as standard practice Credential rotation is one of those practices most teams agree with in principle and very few apply consistently. With integrations, the problem is that rotation requires coordination between Salesforce, the external system, and whoever manages that vendor relationship. It is easy to defer. External Client Apps support automated credential rotation through the Metadata API, which removes much of the manual friction. For teams running DevOps pipelines, this means rotation can become part of standard operations rather than a quarterly reminder that gets ignored. On the monitoring side, Setup Audit Trail logs policy and setting updates for External Client Apps. Pairing that with event monitoring on API access gives you a clearer picture of what each integration is actually doing versus what it is permitted to do. Anomalies become visible. Dormant integrations surface. Over-permissioned apps become easier to identify and fix. Migration considerations for existing Connected Apps Salesforce has provided a migration path from Connected Apps to External Client Apps, and the trajectory of the platform makes it clear that External Client Apps are the long-term model. That does not mean everything needs to migrate immediately. Working integrations that are not causing governance problems do not need to be touched
