Across recent Salesforce releases, a pattern has become hard to ignore. New features land with clear ambition, often closing real gaps and getting immediate attention from admins, developers, and architects. But many arrive without full parity with existing tools or the depth needed for proper enterprise use. Customers are encouraged to try them early, only to find that real production readiness often comes one or more releases later as missing functionality is filled in.
This is not about features being broken. Most work as they’re designed. The issue is that they don’t always go far enough to fully replace what came before or meet the expectations set when they are announced. That gap between “usable” and “ready for production” is becoming more noticeable, especially in areas where Salesforce is modernising core parts of the platform, like page building, automation, and UI design.
For architects and senior platform teams, this creates a familiar dilemma. Do you adopt early and live with the limitations, or stick with older tools that are more complete but clearly being phased out? Increasingly, there is no simple or stable answer.
The “Release Early” Pattern in Salesforce
Salesforce has always embraced iterative delivery. Three releases a year, continuous innovation, and fast evolution of the platform have been central to its success. Many of the platform’s most important capabilities today were not fully formed at launch but matured over time through incremental enhancements and customer feedback.
However, the last few years have made this pattern more visible in structural ways. Rather than isolated gaps, we are seeing entire categories of functionality introduced in a deliberately partial state, with parity and completeness arriving later.
A clear example is the rollout of “Dynamic” page features. Dynamic Forms, Dynamic Actions, and Dynamic Related Lists, and so on, represented a significant shift away from traditional page layouts. The promise was compelling: more granular control, conditional visibility, and a more flexible UI composition model. However, early versions of these features lacked full feature parity with standard Page Layouts. Even today, Page Layouts remain necessary.
This has created a hybrid reality in most enterprise implementations. Rather than replacing Page Layouts, Dynamic Forms have become an enhancement layer that still depends on legacy constructs. The same is true for Dynamic Actions, which initially lacked the depth required to fully replace traditional button and action configuration across all record types and scenarios.
A similar pattern is emerging in Flow. Salesforce has positioned Flow as the strategic replacement for legacy automation tools such as Workflow Rules and Process Builder. In practice, Flow is unquestionably powerful, but certain features have historically arrived without the full set of capabilities expected for production use.
The Kanban component within Flow is a good example. At first glance, it offers a useful visual way to represent records in a staged process. However, its initial implementation is static. Users cannot drag and drop cards between columns in a way that would typically be expected from a Kanban-style interface. That missing interaction fundamentally limits its usefulness in operational contexts where movement between stages is the primary action.
Another example is the Flow Data Table component. While it provides a structured way to display tabular data inside Flow screens, early iterations lacked inline edit capabilities. This meant users could view data but not modify it directly within the component, significantly reducing its value in end-to-end guided processes where data entry and review typically happen in the same interaction.
Another clear example of the “release early” approach is AI. Salesforce’s AI portfolio has undergone a remarkable number of iterations, rebrands, and strategic shifts over the past two years. We’ve seen the evolution from Einstein to Agentforce, from Topics to sub-agents, and from the AppExchange to the AgentExchange.
While this pace of innovation reflects Salesforce’s determination to stay at the forefront of the AI market, it has also created a moving target for customers and partners trying to keep up with the latest terminology, capabilities, and best practices.
Individually, these limitations are understandable. Collectively, they form a recognisable pattern: features are released with core scaffolding in place, but without the full interaction model that would allow them to replace established alternatives.
Why This Approach Exists
There are strong reasons why Salesforce continues to ship features in this way. It is also worth saying that this approach is not unique to Salesforce. Releasing early, shipping an MVP, iterating based on feedback, and maturing features over time is standard across SaaS and platform companies. You see the same pattern at Microsoft, Google, AWS, and most modern product-led organizations. In fact, for cloud platforms, it is often the default approach because it allows faster innovation, faster validation, and reduces the risk of building the wrong thing in isolation.
Within Salesforce itself, the platform is no longer a single-product system but a vast ecosystem spanning CRM, data management, integration, AI, automation, and industry-specific solutions. The complexity involved in delivering fully mature enterprise functionality across all of these domains is significant.
One driver is feedback velocity. By releasing earlier, Salesforce can observe how customers actually use features in production environments rather than relying solely on internal assumptions. Many requirements only emerge once features are exposed to real business processes, edge cases, and organizational constraints.
There is also a competitive reality. In areas such as AI and automation, speed to market matters. Waiting for full feature completeness before release risks falling behind competitors or delaying customer access to innovation that could already provide value in its early form.
From a product perspective, this model is logical. It enables iterative improvement, prioritization based on real-world usage, and faster validation of product direction.
The difficulty is not in the reasoning behind it. The difficulty is in how it impacts customers who are asked to adopt features that are functionally real but architecturally incomplete.
The Customer-Side Problem
For Salesforce professionals, the impact of this model is felt most acutely in planning and architecture. Admins are asked to evaluate new features that may not yet be stable enough for full deployment. Developers are asked to build with tools whose capabilities are still evolving. Architects are asked to design long-term solutions around components that may look significantly different within a few release cycles.
This creates a subtle but persistent uncertainty in platform decision-making. A feature may be “ready to use”, but not necessarily “ready to standardize on”. That distinction is critical in enterprise environments where solutions are expected to last for years rather than releases.
The result is a cautious adoption pattern. Many organizations now pilot new features extensively before committing to them in production. In some cases, they deliberately delay adoption until feature parity with legacy functionality is clearly established. This is not resistance to change, but a rational response to repeated cycles of partial maturity.
It also changes the nature of architectural confidence. Instead of designing around stable platform capabilities, teams increasingly design around what is likely to become stable. That introduces a forward-looking dependency on roadmap interpretation that did not exist as strongly in earlier phases of the platform.
The Hidden Cost of Incomplete Features
The long-term impact of this pattern is often described as technical debt, but in reality, it is more accurately platform decision debt. Organizations make architectural choices based on what Salesforce can do today. When those capabilities evolve, those decisions are not automatically resolved.
For example, an organization may build complex UI logic using custom components or third-party tools because Dynamic Forms does not yet support a required use case. When Salesforce later adds that capability, the organization is left maintaining a parallel solution that may no longer be necessary, but cannot be removed without migration effort and risk.
The same applies in automation. If Flow lacks a key interaction pattern, such as editable data tables or fully interactive Kanban-style movement, teams may build custom screen components or rely on external systems. When Salesforce later enhances Flow, organizations must reassess whether to refactor existing builds or continue supporting legacy implementations.
This creates a compounding effect. Each partial feature release introduces the possibility of future redesign work. Over time, large organizations accumulate a landscape of “almost replaced” solutions that still require maintenance.
Is This a Startup Habit That Never Fully Changed?
There is also a cultural dimension worth acknowledging. Salesforce’s development philosophy was shaped during a period when rapid iteration was a competitive advantage. Shipping early, learning from customers, and improving continuously allowed Salesforce to outpace slower enterprise software vendors.
That mindset remains deeply embedded in the platform. However, the expectations of its customer base have changed significantly. Salesforce now supports some of the largest and most complex organisations in the world. These customers do not simply want access to new features. They want confidence that those features are stable enough to form part of long-term operating models.
The challenge is that these two goals are sometimes in tension. Speed encourages early release. Stability requires maturity before adoption. Salesforce continues to operate in the space between those two priorities.
Final Thoughts: What Is “Done Enough”?
Ultimately, the issue is not whether Salesforce should stop shipping features early. Iteration is a necessary part of modern software development, particularly at the scale Salesforce operates.
The more important question is how clearly the platform communicates maturity. At what point is a feature considered ready for standardization rather than experimentation? How much functionality, parity, and governance need to exist before customers are expected to build long-term solutions on top of it?
Features like Dynamic Forms, Dynamic Actions, and Dynamic Related Lists illustrate this challenge clearly. They represented the future direction of the platform, but they have not fully replaced the constructs they are intended to modernize. Similarly, Flow continues to evolve with powerful enhancements, but certain interaction patterns still lag behind what users would expect from a fully mature replacement for legacy UI components and automation tools.
For customers, the goal is not perfection. It is predictability. Innovation is valuable, but it becomes significantly more powerful when paired with clarity about readiness.
Because in the end, Salesforce does not just ship features. It shapes architectural decisions across entire organizations. And the cost of getting the timing wrong is rarely borne by the platform itself, but by the customers building on top of it.
