Most implementation projects start with a single question: “What are we missing?” As analysts, we gather requirements, add new fields, build more Flows, and deploy new objects. The system grows, the feature list is complete, and each iteration delivers exactly what was planned. On paper, everything looks perfect.
And then comes that all-too-familiar moment. Users start bypassing the CRM, data is incomplete, and the sales pipeline is no longer reliable. In these situations, the natural reaction is to look for missing functionality. In reality, however, the problem rarely lies in what the system lacks. More often, the issue is usability. In other words: friction.
What is “friction” in Salesforce?
Friction can be understood as any cognitive or operational resistance a user encounters while trying to complete a task. Unlike classic system errors, it doesn’t show up in obvious ways. It doesn’t block work outright. Instead, it’s the accumulation of small, recurring inconveniences that, over time, change user behavior.
That’s exactly why it’s so hard to detect. Technically, the system works fine, but users start bypassing it, finding workarounds outside the system, or putting tasks off for “later.” As a result, data quality drops, and the organization loses trust in the tool that was supposed to be its foundation. In most cases, this isn’t due to a lack of features, but excessive complexity in places that shouldn’t be complex in the first place.
Where does friction hide?
In practice, friction usually takes three common forms you’ll find in most mature orgs.
The first is cognitive friction (cognitive load), primarily visible in cluttered interfaces. Instead of focusing on the task, the user first has to filter out most of the information on the screen. A classic example is an Opportunity record with dozens of fields, when only a handful are actually used in a given context. When this happens, users stop reading and start scanning; they ignore parts of the information and make decisions based on an incomplete picture. This isn’t the sign of a “rich system,” but the consequence of failing to prioritize information. Showing everything “just in case” frequently turns out to be a design flaw.
The second area is process friction, which usually manifests as an excessive number of steps required to complete a simple operation. Often referred to as “click debt,” this is frequently just a surface symptom of a deeper issue: technical debt accumulating in automations. In practice, this means users have to manually retype data, click through multiple screens to make a single update, or deal with unpredictable logic caused by overlapping Flows, Apex, and SOQL queries. Over time, this leads to a situation where users keep parallel notes in Excel or Slack, and Salesforce stops being an operational tool, turning into a mere reporting system.
One example from a project is the Opportunity status update process in one company. Originally, it required navigating through several screens and manually filling out multiple fields. After simplifying it to a single dedicated action available directly from the record view, the number of steps was drastically reduced. The real impact wasn’t just in the process itself, but in the data: the completeness of key pipeline information increased because users stopped putting updates off until later.
The third form is informational friction, often described as a low signal-to-noise ratio, and is most obvious in reports and dashboards. Elaborate dashboards might look comprehensive, but if they don’t lead to a specific decision, they don’t reduce uncertainty. In these cases, users get data, but without the context to act on it. Consequently, trust in the reports drops, and along with it, the motivation to maintain good input data. The issue isn’t a lack of information, but a lack of interpretation in the context of real business decisions.
How do we measure friction?
One reason friction gets ignored is the lack of obvious metrics. Standard adoption KPIs, like login rates, don’t reflect the quality of the user experience. It’s better to look for indirect signals that show how the system is actually being used.
A good indicator is the completion rate of optional fields. If users consistently only fill in the required fields, it might mean the interface is too complex or unintuitive. A similar insight comes from analyzing Time-in-Stage; extended time in stage often isn’t caused by real business delays, but by the operational cost of simply changing a status. It’s also worth monitoring the use of private notes and unstructured tasks. A growing number of these, combined with empty structured data fields, is a clear signal that users are bypassing the system rather than collaborating with it.
The analyst’s role: from builder to performance engineer
In many organizations, an analyst’s role is still viewed through the lens of how many features they deliver. However, in mature systems, the ability to simplify is becoming increasingly valuable.
Instead of striving for interface completeness, it’s better to focus on building context. Tools like Dynamic Forms and Dynamic Actions let you adapt the view to the current stage of the process and the user’s role, limiting the number of elements visible at any one time. Similarly, real-time support solutions like In-App Guidance are gaining traction, moving knowledge out of documentation and directly to the point of action.
AI-driven automation is also starting to play a crucial role, taking over operational tasks like summarizing communications or auto-filling data. In this context, a well-designed system isn’t one that requires more work from the user, but one that actively reduces it.
Conclusion
In enterprise systems, the problem is rarely a lack of functionality. Much more often, it’s the resistance the system puts up against the user in their daily work. Friction analysis helps identify this resistance and consciously reduce it.
This isn’t just a UX concern. It’s a direct business outcome: better adoption, higher data quality, and greater reliability of the processes built on that data. In this sense, simplifying a system doesn’t mean stripping away its capabilities. It’s the prerequisite for actually using them.
