A Salesforce rollout can be delivered on time, pass user acceptance testing and still fail in practice. Users may log in, avoid the new feature and keep the real process in spreadsheets, inboxes or private notes.
That is why login count is a weak adoption metric. A login proves that somebody entered Salesforce. It does not prove they completed the new process, captured usable data or received the promised benefit.
Good adoption measurement connects four things: who used the feature, what they did, whether they did it correctly and what changed for the business.
Define the behaviour before choosing the metric
“Increase Salesforce adoption” is too vague to measure. Name the feature or process and describe the behaviour that success requires.
For example:
- sales representatives update Opportunity stages before the weekly forecast;
- service agents use a guided screen flow to triage new Cases;
- account managers record renewal risks in the agreed fields;
- managers review a pipeline dashboard before coaching meetings;
- operations users stop maintaining a parallel spreadsheet.
Each statement gives you an observable action, a population and often a cadence. Only then can you choose useful metrics.
Measure adoption as a funnel
A practical adoption model has four levels.
1. Access
Can the intended users reach the feature?
Measures might include active licences, permission assignments, logins, page access and errors caused by missing permissions. Access is necessary, but it is only the top of the funnel.
2. Activity
Are users performing the expected action?
Track records created or updated, screen-flow runs, report views, task completion or another feature-specific event. Segment by team, role, manager, region or cohort so one enthusiastic group does not hide another group's non-use.
3. Quality and completion
Are users completing the process correctly?
Look at required-field completion, valid stage progression, duplicate rate, abandoned flow interviews, validation failures and records later corrected by an operations team. High activity with poor data quality can be a sign of compliance without understanding.
4. Outcome
Did the behaviour produce the result the rollout promised?
Examples include faster case resolution, more complete forecasts, fewer manual handoffs, shorter onboarding time or reduced spreadsheet work. Outcome metrics often live outside the feature itself and may take longer to change.
Do not claim causation from a simple before-and-after chart. Use the trend as a prompt for investigation, and combine it with user feedback and process knowledge.
Use a baseline and cohorts
Measure the old process before launch when possible. Without a baseline, “400 records created” has no context.
Useful comparisons include:
- four weeks before and after training;
- pilot team versus teams not yet enabled;
- new users versus experienced users;
- managers versus individual contributors;
- regions with different process owners;
- the first month after launch versus the third month.
Cohorts reveal where a rollout needs help. An overall adoption rate of 70% may conceal one team at 95% and another at 20%. The intervention should be different for each.
Choose a denominator that means something
Adoption percentages are easy to inflate with the wrong denominator.
If 60 people used a feature, ask “out of whom?” Possible denominators include:
- all active Salesforce users;
- users assigned the relevant permission;
- users in roles expected to perform the process;
- users who encountered an eligible record;
- users active during the measurement window.
The correct denominator follows the business behaviour. A service-only feature should not be divided by every sales and finance user in the org.
Distinguish screen flows from background automation
A user directly starts a screen flow, so a completed interview can be a useful adoption signal. Record-triggered and other background automation are different: the user may adopt the business process without ever knowing the flow exists.
For background processes, measure the records or field transitions the automation supports rather than treating “flow runs” as user activity. Label inferred measures clearly.
Also monitor reliability. If usage falls after a rise in failures, the adoption problem may be a broken process rather than resistance to change. Pair adoption data with Flow Health and support feedback.
Combine system evidence with human evidence
Usage data tells you what happened. It often cannot tell you why.
Use short interviews, office hours, support tickets and manager feedback to test explanations:
- Is the feature hard to find?
- Is a required field unclear?
- Does the process duplicate work done elsewhere?
- Is page performance slowing users down?
- Are users missing access?
- Does the feature solve the problem they actually have?
Avoid blaming users for low adoption before checking the design. A workaround is data about the system.
Use Salesforce's native adoption signals
The Lightning Usage App provides useful platform-level measures, including daily and monthly active users in Lightning Experience and the mobile app, the most-viewed pages, the slowest desktop record pages, switches back to Salesforce Classic and active licence counts. Its data can't be exported to reports from the UI; Salesforce points to the Lightning Usage App API for that.
Native reports can measure record creation and updates, field completion and process outcomes. Custom report types, dashboard components and login history add further signals. Document each metric's retention and coverage so a blank period is not mistaken for zero activity.
Build an adoption scorecard people can act on
A weekly or monthly scorecard should answer:
- What feature and population are we measuring?
- What changed during the period?
- Which teams are ahead or behind?
- Is usage sustained or falling after launch?
- Are failures or performance affecting the trend?
- Is data quality improving with activity?
- What action will the owner take next?
Keep the measures stable long enough to establish a trend. Changing the definition every month makes improvement impossible to prove.
How orgadmin.ai measures a feature
The orgadmin.ai Adoption Tracker lets a team define a named feature as the objects and flows that represent it. It can then trend records created and updated, screen-flow runs, logins and per-user activity over a selected window.
Optional SOQL filters narrow an object to the records that count—for example, one record type or business unit. Each series is queried independently so one inaccessible object does not blank the whole view.
Coverage is stated rather than hidden. Screen flows can be measured from interview data when Salesforce retains it; background automation is better inferred from the records it writes. Login history is also bounded by Salesforce retention.
The tracker tells you where to investigate. It does not prove that a rollout caused a business outcome, and it should be paired with user feedback.
What to do when adoption is low
Choose the response that matches the evidence:
- Low access: fix permissions, navigation or licence assignment.
- Low discovery: improve page placement and communication.
- High starts, low completion: simplify the process and inspect failures.
- High usage, poor quality: clarify definitions, defaults and validation.
- One team lagging: work with its manager and observe the real workflow.
- Sustained non-use: reconsider whether the feature deserves further investment.
The last option matters. Adoption tracking is not only a way to force usage. It can reveal that a feature should be redesigned or retired, which is valuable input for technical-debt triage.
Measure the thing you actually shipped
Start with one feature, one expected behaviour and one user population. Establish the baseline, track activity and quality by cohort, and connect the trend to a named owner and intervention.
Start a free orgadmin.ai trial to define a feature and build a live adoption view from a connected Salesforce org.