Salesforce’s decision to bring Agentforce into its Free and SMB-focused suites has now lowered the barrier to entry for AI for a lot of its customers, making a clear statement about where the platform is heading and how quickly those capabilities are becoming standard. For many businesses, it’s an easy win that opens up more functionality and has no additional cost to get started.
But moments like this also tend to spark a different kind of conversation across the ecosystem. As Salesforce continues to expand what its platform can do natively, it inevitably moves closer to areas that partners, consultants, and independent builders have been developing for years. For some, that’s a natural evolution of a maturing platform. For others, it raises an uncomfortable question – what happens when the thing you’ve built suddenly becomes a built-in feature?
When the Platform Builds What You Built
Pavel Konan is a Salesforce Consultant who has spent years helping SMB customers get more value from their CRM. More recently, he began building his own AI-powered solution, DealScope, designed to summarize activity data and generate emails directly from Salesforce context – something he told SF Ben that clients had been consistently asking for but struggling to access natively.
For a while, that decision looked like it was working. Then, in the middle of a call with a new prospect, this quickly changed when asked: ‘How is it better to what Salesforce offers?’
Until that point, Pavel hadn’t seen the latest Agentforce updates. What followed was a sudden realization that the product he had spent significant time building had effectively been replicated natively.
Pavel explained that he was shocked and surprised, especially as Salesforce’s new offerings overlap with DealScope’s offerings – summarization features and email drafting.
“I first thought maybe I need to close right now and free up my time,” Pavel explained. “Probably a lot of people do too, [as] they also maybe feel themselves now at high risk. What’s the next step?”
While there is overlap, Pavel doesn’t see the two solutions as identical in practice. After testing the native functionality, he felt that much of it still lacked depth and context, particularly when working with real activity data inside records. In his view, the difference isn’t just about what the feature does, but how useful it is in day-to-day workflows.
That distinction highlights how native features may often prioritize accessibility and ease of use, making them suitable for a wide range of customers. But more specialized tools tend to go further, tailoring outputs to specific use cases and environments. For builders like Pavel, that gap – between what’s available and what’s truly useful – may be where the opportunity still lies.
A Familiar Pattern Moving Faster Than Before
For builders on the AppExchange who have spent a long time in the Salesforce ecosystem, this kind of overlap isn’t really new at all.
The platform has a long history of expanding its native capabilities into areas that were once the domain of partners and ISVs. In many ways, that’s part of what has made Salesforce so successful – continuously evolving to meet customer demand and reduce the reliance on additional tools.
Founder and CEO of Groundwork Apps, Paul Battisson, told SF Ben that Salesforce has always had the ability to build out features that ISVs cover, and that it’s happened often during his career and will likely happen again in the future. But it doesn’t necessarily have to be seen as a bad thing.
Paul said: “If anything, it could be seen as a validation that the idea you have and problem you are solving is a real problem for customers.”
This idea of validation is quite an important counterpoint in this conversation. When Salesforce builds something natively, it often signals that a use case has reached a level of importance where it needs to be accessible to a broader audience. In that sense, it could be argued that such markets are expanding rather than shrinking, bringing more awareness to a problem that specialists have already been solving (such as Pavel).
But Paul also mentioned a caveat to this argument, saying: “For vendors, the key is understanding what differentiates you from Salesforce and their offerings, and extending beyond them where possible for specific industries, domains, or features.”
Where This Leaves the Salesforce Ecosystem
While stories like Pavel’s highlight how quickly new features can overlap with existing products, the picture looks slightly different at enterprise scale.
Speaking to system integrators working on large, complex implementations, the reality is that native functionality often still falls short of what’s required in product environments. In many cases, Salesforce’s built-in tools are seen as a starting point rather than a complete solution – particularly in areas like DevOps, security, and data management, where depth and reliability are critical.
The gap between “available” and “enterprise-ready” is where much of the ecosystem reportedly continues to operate.
Jari Salomaa, CEO and Co-Founder of Valo and a former Salesforce product leader, suggested that the underlying reason for this is that no two Salesforce implementations are usually ever the same. The key issues, according to Jari, lie in business logic and context.
“Depending on how the customer and the partner collaborate together to build the solution, that’s really the end result,” Jari explained.
That variability makes it quite difficult for any single platform to fully standardize solutions, especially as more businesses layer on integrations, and, more prevalently, AI-driven solutions and workflows.
He voiced that it’s very rare that you have both an experienced developer and a perfect setup. For this reason, you’re going to need that additional solutioning to close what he called “that last mile”.
The “last mile” that Jari mentions is where many ISVs continue to differentiate. Rather than competing directly with Salesforce’s baseline capabilities, they are solving for the complexity that emerges once those capabilities are applied in more real-world scenarios/environments.
At the same time, however, it’s very hard to ignore that structural advantage that Salesforce still holds.
“It’s already there, already installed, already in use,” Jari explained. “There’s already champions and people know how to use it… and that gives an advantage.”
This is what makes the current shifts we’re seeing more complicated than a simple case of replacement. Salesforce doesn’t necessarily need to outperform every vendor feature-for-feature. It only really needs to be good enough, and easy enough to adopt – to become that default choice.
But as the platform expands, so does the complexity that surrounds it, especially with the more recent introductions of AI and agent-based workflows being implemented.
Jari said: “The architecture is just getting incredibly complex… You have all these agents, transactions, data flows. How do you ensure audit, security, guardrails? I’m not jealous of any enterprise architect trying to piece that together.”
So in that sense, the ecosystem’s role may not be shrinking, but evolving (which we’re seeing a lot of across the board). Because while Salesforce continues to expand what’s possible natively, it still relies on partners and vendors to help customers make sense of what that actually looks like in practice.
Final Thoughts
Salesforce expanding into new product areas isn’t a fresh concept, but the speed at which we’re seeing it happen definitely is. Agentforce highlights how quickly baseline functionality can become native, particularly in fast-moving areas like AI. For some builders, that’s going to create some pressure. But others see it as validation of the problems they’ve been solving.
What feels clear now is that the ecosystem is moving up the value chain rather than disappearing in any way. Native tools may “win” on accessibility, but complexity and specialization still leave plenty of room for partners and ISVs.
Builders still have a real opportunity to challenge this narrative. Just because Salesforce launches a feature doesn’t mean it replaces what you do. In many cases, you can still outperform it, just at a different layer.
