Five Dynamics 365 apps, each with its own traps
Sales
Leads, opportunities, quotes and forecasts. The usual trap is copying every field from the old CRM; salespeople then stop updating records within weeks.
- βLead to opportunity process
- βProduct catalog and price lists
- βForecast categories
- βOutlook and Teams integration
Customer Service
Cases, queues, entitlements and knowledge articles. Routing rules decide whether customers wait, so they get designed with the people who answer the phone.
- βCase types and SLAs
- βUnified routing to queues
- βKnowledge base
- βEmail and portal channels
Field Service
Work orders, scheduling and the mobile app. Technicians judge the whole project by how the mobile app behaves on a patchy signal.
- βWork order types and incidents
- βResource scheduling board
- βCustomer assets
- βMobile app offline profile
Finance and Supply Chain Management
General ledger, procurement, inventory, warehousing and production for larger, often multi-country businesses. Chart of accounts and financial dimensions come first, because everything else posts to them.
- βLegal entities and dimensions
- βProcure to pay
- βWarehouse management
- βDual-write to Dataverse
Why Dynamics 365 projects overrun, in our experience
The software is rarely the problem. Projects run long when decisions sit unanswered, when the design tries to replicate the old system screen by screen, and when data migration is left until the final weeks. Each of those is a management issue, not a technical one, and each can be seen coming.
We keep a decision log from the first workshop. Every open question has an owner on your side and a date, and it is visible to your sponsor. When a question has sat too long, we raise it rather than guessing an answer and building on the guess.
We also push back on customization. The customer engagement apps are highly configurable, and most requests can be met with forms, views, business rules and flows. Code gets written only where configuration genuinely cannot do the job, because every plug-in is something you have to maintain through two Microsoft release waves each year.
The phases of a Dynamics 365 rollout
- 1
Initiate
Confirm scope, team, environments and the decision log. The scoping call sets the plan and the commercial terms, which are agreed in writing before work starts.
- 2
Design
Workshops by process area produce a solution design document: what is standard, what is configured, what connects to other systems and what is custom. You sign it off.
- 3
Build and iterate
Configuration happens in short cycles with demos to your key users, so problems surface while they are still cheap to fix.
- 4
Test and rehearse
System testing, integration testing, user acceptance testing and at least one full rehearsal of the data load and cutover on a copy of production.
- 5
Go live and stabilize
Cutover runs from a checklist with named owners. After launch we stay close to your users to fix issues and answer questions until the system settles.

What to ask any implementation partner before you sign
- βWho, by name, will do the configuration work, and will they stay for the whole project?
- βWhere will the solution design be written down, and who signs it off on our side?
- βHow many full rehearsals of data migration and cutover are planned before go-live?
- βWhich requirements do you expect to meet with custom code, and why can configuration not cover them?
- βHow will our team be trained, and who will own the system after the partner steps back?
- βWhat happens to the source code, solutions and documentation if we part ways?
Implementation questions from buyers
Do you implement Business Central on this page too?
No, Business Central has its own page because the product, the delivery approach and the typical customer are different. This page covers the Dataverse-based customer engagement apps and Finance and Supply Chain Management. If you are unsure which family you belong in, our consulting work starts exactly there. Many mid-sized firms run Business Central for finance alongside Dynamics 365 Sales for their pipeline.
Can you implement Sales now and Customer Service later?
Yes, and it is often the sensible path. Because both apps share Dataverse, the account and contact records built for Sales are the same ones Customer Service will use later. We design the first phase with the second in mind, so nothing has to be rebuilt. The roadmap makes that sequence explicit.
How long will our implementation take?
It depends on the apps, the number of users and locations, the integrations and the state of your data, so we do not quote a duration on a web page. The scoping call sets the plan, and the timeline is written into the proposal with the assumptions it rests on. If an assumption changes, the plan is updated openly rather than quietly slipping.
Who owns the configuration and code after go-live?
You do. Configuration and any custom components are packaged as Dataverse solutions or, for Finance and Supply Chain Management, as models in source control, and you keep access to all of it. Documentation of the design and of every customization is handed over. If you later move to another partner, they start with the full picture.
Do you work with Microsoft FastTrack?
Where a customer qualifies for Microsoft FastTrack, we work alongside the FastTrack architect and take part in the Success by Design checkpoints. Those sessions are useful because they force risks into the open early. Not every project qualifies, and a well-run project does not depend on it.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.
