Redesigning a Dynamics 365 Sales Process That Fights How You Actually Sell

Is poor Dynamics 365 Sales adoption a training problem or a process problem?

Usually a process problem that looks like a training problem. The signs are consistent: the pipeline is full of opportunities parked in the first stage, mandatory fields hold the same placeholder value on hundreds of records, managers still run the Monday meeting off a spreadsheet, and the deals that matter most are discussed in WhatsApp groups and written on paper because the system slows the seller down at exactly the moment the deal is moving. None of that is fixed by teaching people where the buttons are.

Our adoption and training page makes the general argument, and its section on why we fix the system before we teach it lists the changes that remove resistance. This page is the method behind the largest of those changes for a sales team: redesigning the process model itself so that the business process flow, the fields and the ownership rules describe how your people actually sell.

How do you test whether Dynamics 365 matches how your team actually sells?

Map the real sequence first, then compare it to the configuration, then count. Sit with two or three sellers from each segment and write down what they do from first contact to signed order, in their words and in their order, including the parts that happen on the phone, in WhatsApp and in a notebook. Then open the opportunity business process flow and the lead and opportunity forms and lay them side by side with that sequence.

The count that settles the argument is simple: every place where the system asks for a value the rep cannot honestly know at that moment. Budget before the first meeting. Close date on the day a lead arrives. Decision maker before anyone has met the buyer. Each one produces either a junk value or a record that never gets created, and both destroy the data. The table shows what the comparison typically surfaces.

What should you freeze before you change anything?

A sales process redesign touches the numbers people are paid on, so the first work is deciding what does not move while the rest does. Freeze these before any configuration change, write them down, and tell the sales team they are frozen and until when.

• The definition of closed won and the report commission is calculated from. If commission is paid from a figure that lives outside Dynamics 365, say so and leave that calculation alone until a quarter boundary.
• Record ownership on open opportunities. No bulk reassignment during the quarter, even where the current owner is wrong, because ownership drives both the pipeline view and, in most businesses, who gets paid.
• The existing stage values and option set values. New stages are added alongside, never by deleting or renumbering the old ones, because historical reports and any integration read those values.
• A dated snapshot of the open pipeline, exported and stored, so every change afterwards can be reconciled against a baseline rather than against memory.
• New field requests. Nothing new is added to the lead or opportunity forms until the minimisation work below is done, or the redesign simply adds more fields on top of the old ones.
• Integrations and imports that write to leads, contacts, accounts and opportunities. Know which ones exist and pause changes to them, because they bypass the form and much of what you are about to redesign.

How should business process flow stages be defined so they gate on evidence, not filled boxes?

A business process flow in Dynamics 365 can mark steps as required, and a seller cannot move to the next stage until those steps have a value. That is useful and also the root of most garbage data, because a required step only checks that a field is not empty. It cannot check that the value is true. So define each stage by the evidence that proves the deal has earned the next one, and make the required step point at something that is hard to fake: a related contact with a recorded role, a completed meeting activity, an attached quote record, a date the customer gave rather than one the seller guessed.

Keep stages to what a buyer does, not what a seller hopes. Where a check has to hold regardless of how the record was changed, including imports and integrations, it belongs in server-side logic such as a real-time validation or a plug-in, because form requirements and business process flow steps apply in the user interface and do not stop an integration writing directly to the table. The table is an illustration of the shape, not a template to copy.

Which mandatory fields should you remove, and when should each field be asked?

Go through every required field on the lead, contact, account and opportunity forms with the people who fill them in, and put each field into one of four buckets. Most organisations find that the list of fields reports actually consume is far shorter than the list of fields the form demands.

• Needed now and knowable now: keep it required, on the quick create form, where the rep captures it in seconds.
• Needed but not knowable yet: move it to the business process flow stage where it becomes known, or make it conditional with a business rule, so it is asked when the rep can answer it.
• Derivable from something else: remove it from the form and fill it from email, activity, the account or a flow, as described in the next section.
• Nobody reads it: remove it from the form. Keep the column for history if it holds data, but stop asking for it.
• Split estimates from facts. A seller estimate for close date and revenue is legitimate and useful for forecasting; it should not sit in the same field as the date the customer committed to.
• Remember that field-level business required only applies on forms. If an import or integration creates the record, the requirement is not enforced, which is one reason junk and blank values coexist on the same field.

What can Dynamics 365 Sales infer from email and activity instead of asking reps?

More than most implementations use, and less than some marketing implies, so it helps to separate the platform features from the licence-dependent ones. Server-side synchronization with Exchange Online synchronises email, appointments and tasks between Outlook and Dynamics 365, and the Dynamics 365 App for Outlook lets a seller track an email or meeting against the right account, contact or opportunity without leaving the inbox. Once activities are tracked reliably, a great deal of what forms usually ask for can be derived: last contact date, who at the account has been met, whether a proposal was sent, and how long an opportunity has been silent.

The richer features are where care is needed. Automatic capture of untracked emails and meetings, sales accelerator sequences, predictive lead and opportunity scoring, relationship insights and several Copilot capabilities depend on which Dynamics 365 Sales licence each user holds, on admin enablement and on the current release wave, and Microsoft changes that packaging over time. We check what your tenant is actually licensed for before designing a field around any of them, rather than removing a field on the promise of a feature you do not have.

How do you stop duplicate records when deals are tracked in WhatsApp, paper and spreadsheets?

Duplicates in a sales CRM are rarely a data problem and almost always an ownership problem. When the fast path for a seller is a WhatsApp chat and a notebook, the CRM record is created late, by whoever remembers, often twice, and sometimes by an import from a spreadsheet somebody kept on the side. Fix the rules in this order.

• Publish duplicate detection rules for accounts, contacts and leads on the matching keys that are actually reliable in your data, such as normalised email address, company registration number or website domain, rather than names alone. Dataverse checks them when records are created or updated in the app and during import, and duplicate detection jobs can find what already exists.
• Know where the rules do not reach. Records created through the Web API are not checked unless the integration asks for duplicate detection, so for integrations the stronger control is an alternate key that makes the platform reject a second record with the same identifier.
• Merge rather than delete. Accounts, contacts and leads can be merged in Dynamics 365 so activities and child records move to the surviving record, which keeps the history sellers care about.
• One owner per record, with collaborators added rather than records copied. Dataverse records have a single owner, so a second seller working the account belongs on an access team or the opportunity sales team, not on a duplicate opportunity of their own.
• Give WhatsApp and paper a faster route into the CRM than the notebook. A quick create form on the mobile app that captures the contact, the account and one line of context takes less time than writing it down. There is no out of the box capture of personal WhatsApp chats into Dynamics 365 Sales; if WhatsApp is genuinely the channel, the realistic option is a WhatsApp Business Platform integration on a business number, designed and scoped as its own piece of work.
• Decide which rescued deals are new pipeline and which are not. A deal typed in from WhatsApp in week six was not created in week six, so capture the original first contact date and a source value, or it will inflate new pipeline and distort the quarter.

How do you run a 90-day redesign without double-counting deals or breaking commission mid-quarter?

Sequence the work against the commercial calendar, not the project plan. Ideally the 90 days start just after a quarter opens so the ownership and stage changes that affect pay land at the next boundary. The phases below are the shape we use; the exact dates depend on your quarter and on how much data has to be brought in.

When is the problem not the sales process at all?

Sometimes the process is fine and the build is broken: flows failing, a data model that cannot answer the questions the business asks, or customisations made directly in production. That calls for an independent health check or a project rescue, not a redesign. Sometimes the platform is the wrong size: a small team with a linear pipeline and no other department on the record may be better served by a lighter CRM, and our honest comparison with Pipedrive and HubSpot says so. And sometimes per-user Microsoft licensing is the real obstacle, in which case a custom-built CRM shaped to the sales process from the start is the alternative.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

What does a sales process redesign with Solzet involve?

Senior consultants and full-stack developers with 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery run the mapping sessions, redesign the business process flow, forms, duplicate rules and ownership model, build the flows, plug-ins and custom PCF controls where configuration runs out, and stay through the pilot and the quarter boundary. The wider scope of a Sales implementation is on our Dynamics 365 Sales service page, and the role-by-role training that follows a redesign is on the adoption and training page.

We work from Yerevan, Armenia, in GMT+4, in English, Armenian and Russian, in your tenant through accounts you create and can revoke. We do not implement Dynamics 365 Finance, Business Central or other ERP systems, so where commission is calculated in one of those, we design the CRM side to feed it cleanly and leave the calculation with whoever owns that system.