Dynamics 365 is an enterprise platform designed to support hundreds of different business types, team sizes, and industries. Out of the box, it surfaces capabilities relevant to all of them. Most teams need a fraction of that. When the configuration does not match the actual work, users face a system that feels overwhelming rather than useful, and adoption suffers as a result. This article explains what right-sizing means in practice, how to do it, and why it is one of the highest-impact things you can do for user adoption.
Why does Dynamics 365 feel too complex for most users?
The complexity criticism levelled at Dynamics 365 is legitimate, but it is often misdiagnosed. The platform itself is not too complex for the work being done. The configuration is too broad. There is a significant difference between the two.
A standard Dynamics 365 Sales installation presents a user with navigation options for Sales, Marketing, Customer Service, Field Service, Project Operations, and more. Within each area, there are dozens of record types, views, and configuration options. A salesperson whose job is to manage a pipeline of forty prospects and log their activity does not need most of this. They need a clean list of their accounts, a simple way to log a call or meeting, and a clear view of where each deal stands. The rest is noise.
When a salesperson opens the system and sees all of it, the cognitive load is real. They have to navigate past things that are not relevant to their job to get to the things that are. Over time, this friction accumulates. The system starts to feel like more work than it is worth, and the workarounds begin.
What does right-sizing a Dynamics 365 configuration actually involve?
Right-sizing is the process of configuring the system so that each user role sees only what is relevant to their specific job, and the system supports the actual workflow rather than a generic or idealised version of it. It is not about removing functionality. It is about removing visual noise and friction for users who do not need that functionality.
The work falls into five areas: navigation simplification, form customisation, view configuration, pipeline alignment, and dashboard design. Each one addresses a specific source of complexity that contributes to low adoption.
Navigation simplification
The navigation bar in Dynamics 365 can be configured by role. A salesperson should see Sales, their key dashboards, and nothing else. A customer service representative should see Customer Service and the specific queues and views relevant to their team. A manager should see everything their direct reports see, plus the reporting views they need for oversight.
Removing irrelevant navigation items is one of the fastest wins in any right-sizing exercise. It takes less than an hour to configure per role and produces an immediate reduction in perceived complexity. Users who have been navigating past three modules they do not use to get to the one they do will notice the difference on the same day.
Form customisation
The default forms in Dynamics 365 display every field that has ever been considered useful for a given record type. The contact form, for example, includes fields for job title, department, parent account, business phone, mobile phone, email, address, birthday, anniversary, LinkedIn profile, Twitter handle, and dozens more. Most organisations use fewer than half of these.
Form customisation means removing fields that are not used, grouping the fields that are used logically, and ordering them to match the natural flow of how users work through a record. Required fields should be at the top. Rarely used but occasionally relevant fields can sit in a collapsed section. Fields that nobody ever fills in should be hidden or removed entirely.
The goal is a form that a user can complete in under two minutes for the most common record types. When it takes longer than that, completion rates drop and data quality degrades.
View configuration
Views are the lists that users see when they navigate to a record type. The default account view in Dynamics 365 shows account name, phone, address, primary contact, and a handful of other fields. For most sales teams, what they actually want to see is account name, last activity date, open opportunities, assigned owner, and next follow-up task.
Building role-specific views that surface the most useful information for each team's daily work removes the need for users to customise their own views or work around an unhelpful default. A salesperson who opens their account list and immediately sees what matters to them that day is significantly more likely to use the system consistently than one who has to filter, sort, and adjust before they can see anything useful.
Views can also embed filters that are permanently useful for a given role. A customer service view that always shows open cases assigned to the current user, sorted by due date, removes a repetitive filtering step from the start of every shift.
Pipeline alignment
The opportunity pipeline is where the gap between the configured system and the real sales process tends to be most visible. Default pipeline stages in Dynamics 365 are generic placeholders. Most implementations customise them, but the customisation often reflects how leadership thinks the sales process works rather than how it actually works in practice.
Right-sizing the pipeline means working with the sales team to define stages that reflect how deals genuinely progress for your specific business. It means asking what has to be true for a deal to move from one stage to the next, what information should be captured at each stage, and what the typical reasons are for a deal to stall or regress. The resulting stage model is one that salespeople recognise as accurate rather than as a bureaucratic overlay on their real work.
When the pipeline matches reality, salespeople update it because doing so is useful to them. When it does not match reality, they update it only to satisfy reporting requirements, and the data quality reflects that distinction clearly.
Dashboard design
The default Dynamics 365 dashboards are generic summaries that provide a starting point but rarely match the specific information needs of a given team. A sales manager's dashboard should show pipeline by stage, activities logged this week, deals closing this month, and follow-ups overdue. A customer service manager's dashboard should show open cases by priority, average resolution time, and cases approaching SLA breach.
Building role-specific dashboards that surface these metrics directly is one of the most visible ways to demonstrate the value of the system to managers. When a manager opens the CRM and immediately sees the information they need to run their team, their engagement with the system increases. And as established in other articles in this series, manager engagement is the single most reliable driver of team adoption.
How do you approach a right-sizing exercise in practice?
Start by mapping the most frequent tasks for each role. Not everything a role does, but the five or six things they do every day. For a salesperson, this might be: check pipeline, log a call, update an opportunity stage, set a follow-up task, and review account history before a meeting. For a customer service rep: check case queue, update case status, log activity, escalate a case, and close a resolved case.
For each task, trace the path through the current system. How many clicks does it take to complete? What fields or steps are encountered along the way that are not relevant to this task? Where does the user have to scroll, filter, or search to find what they need? Each unnecessary step is a candidate for removal or simplification.
The output of this exercise is a prioritised list of configuration changes. Start with the changes that reduce the most friction for the most frequent tasks. These produce the fastest visible improvement in user experience and the quickest impact on adoption.
Right-sizing is not a one-time project. The system should be reviewed after each release wave, when team workflows change, and when adoption data suggests users are struggling with specific areas. The goal is a system that keeps pace with how the business works, not one that is configured once and left unchanged for years.
What is the relationship between right-sizing and adoption?
A well right-sized system does not guarantee adoption. People and process factors still matter enormously. But a poorly right-sized system almost guarantees low adoption, because it places unnecessary friction in front of every user, every day.
Configuration is the foundation. When the system is genuinely easy to use for the specific job each role performs, the other elements of an adoption programme, training, manager reinforcement, data quality standards, become significantly more effective. Users who are not fighting the system can focus on building good habits. Users who are constantly navigating complexity cannot.
The organisations that achieve the best adoption outcomes from Dynamics 365 are not the ones with the most sophisticated configurations. They are the ones with the most appropriate configurations for their teams. Simplicity, accuracy, and relevance matter more than capability breadth. Right-sizing is how you get there.
Related reading
Frequently asked questions
What does right-sizing a Dynamics 365 configuration mean?
Right-sizing means configuring Dynamics 365 so that each user role sees only what is relevant to their specific job, and the system supports the actual workflow rather than a generic version of it. It involves hiding irrelevant fields and views, simplifying forms, configuring pipeline stages to match how your team actually works, and building dashboards that surface information people genuinely use.
Why is Dynamics 365 so complex for users?
Dynamics 365 is an enterprise platform designed for hundreds of different business types. Out of the box, it surfaces capabilities relevant to all of them. Most organisations use a fraction of that capability, but if the system has not been configured to hide what is not relevant, users see the full platform regardless. The complexity is the result of under-configuration, and it is entirely fixable.
How do you simplify Dynamics 365 without losing functionality?
Simplification is achieved through role-based security profiles, form customisation, view configuration, and dashboard design. Hiding a field or view does not remove the underlying functionality. It removes the visual noise for roles that do not need it. A system administrator can access everything. A salesperson sees only what is relevant to selling.
What is a role-based view in Dynamics 365?
A role-based view is a configured view of a record or list that shows only the fields and actions relevant to a specific job role. A salesperson's account view might show last activity date, opportunity value, and next follow-up. A customer service rep's view of the same account might show open cases and SLA status. Both draw from the same record but surface different information based on what each role needs.
How often should a Dynamics 365 configuration be reviewed?
Configuration should be reviewed after each release wave, which Microsoft delivers twice yearly in April and October. It should also be reviewed when team workflows change significantly, when new roles are added, and when adoption metrics suggest users are struggling. Configuration is not a one-time task. It should evolve with how the business works.
Can you right-size Dynamics 365 without a developer?
Most right-sizing work does not require development. Form customisation, view configuration, security role adjustments, dashboard design, and pipeline stage changes can all be done by an experienced functional consultant without writing code. Custom fields and complex workflow automation may require Power Platform skills, but the majority of simplification work that drives adoption improvement is achievable within the standard configuration toolset.
Is your Dynamics 365 configured for your team or for everyone?
Clearpath reviews your current configuration against how your team actually works and rebuilds it around the real workflow. Faster to use, easier to adopt, and built to last.
Written and maintained by Martin Prosser, Microsoft Dynamics 365 specialist with over a decade of hands-on experience. Last reviewed: February 2026.