Business software has moved between two ideas for as long as businesses have bought it. One holds that a single platform doing most things adequately beats a collection of tools each doing one thing well. The other holds the reverse. Neither idea has ever won outright. Each has its decade, and the shift between them follows a change in two costs: what specialisation offers, and what integration demands. Both costs have moved again, and the movement favours the consolidated platform.
Three decades of swinging
The integrated enterprise suites of the 1990s promised one system and one database for finance, operations and people. They delivered it, with the compromise that every department accepted a generic version of its own work. When software moved to the cloud, that compromise stopped being necessary. A marketing team could subscribe to a purpose-built email tool on a Monday and be sending by Friday. Events, surveys, document signing, research distribution and meeting notes each acquired a specialist product, priced per seat and adopted by the team that needed it, without a procurement cycle or an IT project.
The growth was visible from a distance. Scott Brinker’s marketing technology map counted around 150 products in 2011 and more than 14,000 by 2024. Salesforce’s AppExchange, launched in 2006, rested on the premise that the CRM would sit at the centre while specialists supplied the edges. Salesforce itself assembled much of its product line by acquiring specialists: ExactTarget and Pardot for marketing, MuleSoft for integration, Tableau for analytics, Slack for communication.
Every one of those decisions was sound. Specialist tools earned their place because the gap between what a general platform could do and what a department needed was wide, and connecting a new product to the CRM was comparatively cheap. A sync, a connector, a nightly job. The specialist covered the gap and the connector covered the distance.
The two costs that decide each swing
The pendulum moves when those two costs change places. Specialisation wins while the functionality gap is wide and integration is cheap. Consolidation wins when the gap narrows and integration grows expensive.
The gap has narrowed. Salesforce has spent a decade turning itself from a CRM with customisation options into a platform for building business applications. Apex handles logic that configuration cannot reach. Lightning Web Components allow interfaces shaped around a specific workflow. Flow handles orchestration. A fund manager’s event registration, adviser onboarding or research entitlement process can now take the shape of a purpose-built tool while living on the same data model as the rest of distribution.
Integration, meanwhile, has grown more expensive in ways that rarely appear on the original business case. Each external tool brings its own definition of a contact, its own permissions, its own audit trail, its own renewal and its own security review. The connector that seemed trivial in year one becomes, by year five, a piece of software someone must understand, monitor and repair whenever a field changes on either side. Across a distribution team running eight or ten such tools, the maintenance is continuous and mostly invisible.
A specialist tool that reads and writes CRM data all day is a second front door to the same house, with its own locks and its own key register.
Why AI accelerates the swing
Artificial intelligence has added a third cost, and it falls heavily on fragmentation. Claudeforce, Agentforce and every comparable system reason over the data they can see, under the permissions that govern it. Where contact history, event attendance, email engagement and fund flows sit in one data model, a model can draw a straight line between them. Where they sit in six systems, it meets six definitions of an adviser and six timestamps for the same meeting, and has to reconcile them before it can say anything useful.
Consolidation was once justified by licence savings and administrative tidiness. The argument now concerns coherence. The value of AI inside a distribution team rises with how much of the team’s activity lives in one place, described one way. Each specialist tool outside the platform is a room the model cannot enter, or can enter only through a translator.
The swing does not make every external system redundant. Tools that originate data the CRM could never produce, such as investment platform flow data, research ratings or market pricing, belong outside and feed in. The pressure falls on a narrower category: software whose main function is to present and edit information that already lives in the CRM. Those tools depended most on the functionality gap, and the gap is where the platform has moved furthest.
The judgement in the middle
Deciding what belongs on the platform and what stays outside it is a design question with lasting consequences. Pull too much in and the org fills with bespoke components that only their builders fully understand. Leave too much out and the data model fractures in exactly the places AI needs it whole. The right boundary depends on where a firm’s data originates, which processes carry compliance weight, and how the firm expects AI to take part in the work over the next several years.
The specialist tools of the last fifteen years answered the conditions of their time, and answered them well. Those conditions have changed. The same logic that sent departments towards purpose-built software now brings them back to the platform, because the purpose can be built where the data already lives.
Every generation of business software learns again how expensive meaning is to move.
Q: Does consolidating specialist tools onto Salesforce increase licence costs?
Sometimes, though the comparison is wider than licences. Salesforce Platform licences cover people who need custom applications without full CRM access, at a lower price than a Sales Cloud seat. The retired tool’s subscription, connector maintenance, security reviews and administration time all sit on the other side. Across several specialist tools, the total often favours the platform.
Q: What happens to historical data when a specialist tool is retired?
Historical records need a home before the subscription ends. Most specialist tools export their data, but the export reflects that tool’s structure, which rarely matches the CRM’s. Mapping old event attendance, email engagement or document records into Salesforce objects takes planning, particularly where history carries compliance significance. Retiring the tool is quick. Preserving what it knew takes longer.
Q: Does the move back to platforms reduce the role of AppExchange?
AppExchange packages install onto Salesforce and run against its data model, so they sit on the consolidated side of the swing. A managed package storing data in Salesforce objects behaves very differently from an external tool that syncs a separate copy. The pressure falls on software that keeps its own version of CRM data outside the platform.
Q: Is custom functionality on Salesforce harder to support than a vendor product?
It can be. A vendor carries the maintenance of its own product, including updates, security and compatibility. A custom build on Salesforce inherits the platform’s security model and release cycle, but its logic belongs to the firm. Documentation, testing and a clear owner determine whether a custom component remains an asset or becomes something nobody wants to touch.
Q: Can an AI agent work across Salesforce and external tools at the same time?
It can, through connectors and MCP tools, but each external system adds a separate permission model, data definition and point of failure. The agent must reconcile those differences before reasoning about them, and reconciliation errors are difficult to see. Answers drawn from a single data model are easier to trace, audit and trust.