Dynamics 365 user adoption is the single biggest problem I see on consulting engagements. Not technical issues, not licensing confusion, not data migration nightmares. The system works fine. The people refuse to use it. And nine times out of ten, it is entirely the fault of whoever ran the implementation.
I have walked into organisations where they have spent hundreds of thousands on Dynamics 365, the system has been live for six months, and the sales team are still tracking deals in Excel. The finance team log in once a week to run a report their boss demands. Everyone else pretends it does not exist. This is not an edge case. This is normal. And it is completely preventable.
The system was built for management, not users
This is the root cause of most adoption failures and almost nobody wants to admit it. The requirements gathering process was dominated by senior leadership who wanted dashboards and reports. Nobody asked the people who would actually be using the system every day what would make their lives easier.
Think about it from the perspective of a sales rep. Before Dynamics 365, they had their own system. Maybe it was a notebook, maybe it was a spreadsheet, maybe it was their inbox. It was messy, sure, but it worked for them. Now you are asking them to log into a system that requires twelve clicks to record a phone call, mandatory fields that make no sense for their workflow, and a dashboard designed to let their manager monitor their activity. Of course they hate it.
The fix starts before a single form is configured. You need to sit down with actual end users and ask them one question: what would save you time? Not what data does management need. What would genuinely make the day to day job less painful? If you cannot answer that question for every user group, you are not ready to start building.
Training was a two hour session six months ago
The most common training approach I see is this: a consultant runs a two hour session the week before go live, someone records it on Teams, and that recording gets emailed around with a note saying "please watch this before Monday." Nobody watches it. On Monday, people log in, get confused, and go back to whatever they were doing before.
Good training for Dynamics 365 looks nothing like this. It needs to be role specific, which means the sales team get trained on sales workflows and the customer service team get trained on case management. Nobody needs to sit through a two hour session covering features they will never touch.
It also needs to happen more than once. I recommend a short session before go live focused purely on the three or four things each role will do every day. Then a follow up two weeks later when people have actually used the system and have real questions. Then another one a month after that. Three sessions spread across six weeks costs less than you think and makes more difference than any amount of customisation.
There are too many mandatory fields
Nothing kills adoption faster than a form full of red asterisks. I have seen lead forms with fifteen mandatory fields. Fifteen. A sales rep gets a promising lead on the phone, wants to quickly log it before they forget, and has to fill in the lead source, industry, annual revenue estimate, number of employees, and six other fields they do not know the answer to yet. So they do not bother.
My rule is simple. At creation, only require the absolute minimum to identify the record. Name, company, maybe email or phone. Everything else can be required at stage transitions. You need the annual revenue before moving a lead to qualified? Fine, require it at that point. But do not ask for it when someone is trying to capture a name before it falls out of their head.
I wrote about this mindset in more detail in my post on customisation versus code in Dynamics 365. The principle is the same: just because you can configure something does not mean you should.
Nobody explained what is in it for them
This one is embarrassingly obvious and almost always overlooked. People are not going to change their behaviour because you sent an email saying the company has invested in a new CRM. They need a selfish reason to use it. What does Dynamics 365 do for them personally?
For a sales rep, that might be automated follow up reminders so they never lose a deal because they forgot to call back. For a customer service agent, it might be seeing the entire customer history without having to search through three different systems. For a manager, it might be not having to chase people for their weekly pipeline update because the data is already there.
Find the personal win for each role and lead with that. Not "the company needs better visibility into the pipeline." That is a management problem. Lead with "you will never lose a deal because you forgot to follow up again." That is a user problem, and users care about user problems.
The system is too slow
Sometimes the adoption problem is genuinely technical. If your Dynamics 365 environment takes four seconds to load a form, people will avoid it. If a workflow fires and locks a record for thirty seconds every time someone saves, they will stop saving. Performance matters enormously for adoption and it is often treated as an afterthought.
Common culprits include synchronous plugins that should be asynchronous, forms loaded with unnecessary subgrids and controls, and business rules that fire on every field change. I have seen a single entity form with eleven subgrids on it. Eleven. It took eight seconds to load. Nobody used it, and honestly, I cannot blame them.
Audit your most used forms. If anything takes more than two seconds to load, fix it before you worry about training or change management. No amount of motivational emails will convince someone to use a slow system when their spreadsheet opens instantly.
There is no champion on the ground
Every successful Dynamics 365 rollout I have been part of had someone inside each department who genuinely liked the system and helped their colleagues. Not a project manager. Not an external consultant. An actual team member who understood the day to day work and could show people how to do things quickly.
These people do not appear by accident. You need to identify them early, give them extra training, involve them in configuration decisions, and give them time to support their team. They are worth their weight in gold because they translate between "consultant speak" and "how we actually work here."
If you do not have a champion in a department, you have a department that will not adopt the system. It really is that straightforward.
Stop blaming the users
The most frustrating thing I hear from project teams is "users are resistant to change." That is not a diagnosis. That is an excuse. Users are resistant to systems that make their jobs harder, ignore their needs, and were designed without their input. Build something that genuinely helps them and you will be amazed how quickly the resistance disappears.
If you are mid implementation and worried about adoption, or if you have already gone live and it is going badly, start with the basics. Talk to five users this week. Not managers, users. Ask them what is painful. Fix the top three things they mention. You will see more improvement from that than from any change management framework or adoption gamification platform.
For more on getting Dynamics 365 implementations right from the start, take a look at my Dynamics 365 consulting services. Because fixing adoption after the fact is always harder than getting it right the first time.
