For CRM and ERP data teams have stopped trusting
Microsoft Dynamics 365
A Dynamics 365 rollout usually ships the modules and stops short of the workflow underneath them, leaving plugins undocumented and security roles copied from a template nobody reviewed. This practice treats the configuration as a delivery outcome: plugin and workflow logic, role design, environment migration and Dataverse integration owned end to end, not handed off half finished.
How a Dynamics 365 configuration gets designed here
Where configuration ends and a plugin genuinely earns its place.
90 secSample frame · video pending01Before a plugin gets written
Configuration or custom code is a real decision.
Every Dynamics build tempts a developer toward custom plugin code before checking whether native configuration already solves it. Four questions settle the call before code gets written.
Can a business rule or flow do this?
Business rules and Power Automate cover most validation and notification needs without a line of plugin code. Reaching for a plugin first usually means a maintenance burden nobody asked for.
Does the logic need to run synchronously?
A plugin runs inside the platform transaction and can block a save, while a Power Automate flow runs after the fact. Anything that must stop a bad record from saving belongs in a plugin.
How many environments does it need to survive?
Configuration inside solutions moves cleanly between development, test and production. Code embedded directly in an environment without a managed solution rarely survives the next migration intact.
Who maintains this after we leave?
Your internal admin can usually maintain a configured business rule. A custom plugin needs a developer on call, so that cost belongs in the decision, not a surprise afterwards.
| Configuration | Custom plugin | |
|---|---|---|
| Runs inside the save transaction | No | Yes |
| Survives environment migration cleanly | Usually | With a managed solution |
| Who can maintain it later | Your admin team | A Dynamics developer |
| Best fit | Validation, notifications, simple rules | Complex, transaction-critical logic |
02Agreed before configuration starts
The ledger that keeps a Dynamics build honest
Dynamics engagements slip when the scope of customization gets assumed rather than agreed in writing. This ledger fixes what you bring, what we configure or build, what returns to you, and what your team keeps control of throughout.
- Your side
You bring
- The current Dynamics instance and its unused or misconfigured modules
- How your sales, service or finance team actually works today
- Any existing customizations nobody has documented
- Our side
We build
- Forms, views and business rules reconfigured around the real process
- Security roles modelled on actual job functions
- Workflow and plugin logic only where configuration cannot meet the need
- Your side
You receive
- A Dynamics instance the team actually works inside
- Documentation of every customization and why it exists
- A security model that survives an audit
Never leaves you
- Ownership of the sales and service process itself
- The Dynamics licence and tenant relationship with Microsoft
- Authority over what gets automated next
Where the line sitsWe reconfigure the platform around your process; you keep the decision on how that process should actually run.
03From process map to go-live
Four stages, each closing on real evidence
Dynamics builds that disappoint usually skipped a stage here rather than a step inside one. This system closes each stage with an artefact your business owner can actually check.
Map the process, not just the module
Sales, service or finance workflows get walked with the people who run them before a single field gets configured. Customization decisions trace back to that walkthrough instead of a generic template.
A configuration plan before a build planConfigure before you customize
Business rules, views and Power Automate flows get built first, and a plugin only enters once configuration genuinely cannot meet the requirement. Most Dynamics builds need far less custom code than the first draft assumes.
Native first, code only where it earns its keepDesign security roles deliberately
Access gets modelled around real job functions rather than copied from the out-of-box template and expanded by exception. A model built this way survives an audit instead of merely passing one.
Roles that match how the business actually worksMigrate and validate before go-live
Every migrated record gets mapped, reconciled and signed off by a named business owner before the old system switches off. Go-live happens once the data is trusted, not once the calendar says so.
Records reconciled before cutover, not after
04What actually moves the number
Four drivers, priced from the assessment
Dynamics work is priced against the scoping assessment, because these four factors change effort by multiples rather than by small percentages.
Number of modules in scope
A single sales-module configuration costs less than a combined sales, service and finance rollout touching several teams' processes at once.
Custom plugin and workflow depth
Native configuration is quick to price, while transaction-critical plugin logic with its own test suite takes meaningfully longer to build and verify.
Data quality going into migration
Clean, well-structured source data migrates in days. Years of inconsistent records demand cleansing work that often outweighs the migration itself.
Number of environments and integrations
A standalone instance is simpler than one wired into Power BI, SharePoint and a finance system, each with its own contract to honour.
05Evidence and proof
Dynamics 365 builds trusted by the teams inside them.
Dynamics 365 proof is a system every team actually works inside, not a launch email declaring victory. Every record here waits for written client approval before production.
Explore case studiesA CRM finally trusted by the sales team it was built for.
Vela Ledger's sales team tracked deals in spreadsheets beside a Dynamics 365 instance nobody used. Reconfiguring forms and roles around the real sales process brought every deal back inside the platform.
- Deals tracked inside Dynamics
- 9 in 10
- Spreadsheet trackers retired
- 6
Two Dynamics environments merged into one trusted record.
Nexa Foundry ran finance in one Dynamics environment and operations in another, each holding its own version of the same customer. A mapped migration reconciled both into a single environment with one system of record.
- Environments consolidated
- 2 to 1
- Reconciliation exceptions found
- Mapped and resolved
Our security model finally matches how the team actually works, not a template someone downloaded years ago.
Sample · pending client approval
06Read this first
When Dynamics 365 is the wrong answer
Implementing a full CRM and ERP suite for a need that one simple form could solve is over-engineering dressed up as ambition. The exits below are marked plainly.
- Microsoft Power Platform
You need one form, not a platform
A single Power Apps canvas app or SharePoint list often serves a narrow need better than standing up Dynamics modules around it.
Your processes are still changing weekly
Configuring a CRM around a process still being redesigned means reconfiguring it again shortly after launch. Stabilise the process first.
- Team extension
You need Dynamics developers, not a delivery team
If your team already owns the Dynamics roadmap and just needs hands, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | Modules and scope are known | Access decisions and priorities | Configuration and delivery |
| Delivery pod | Requirements will evolve across modules | Product decisions each cycle | Engineering and testing |
| Team extension | Your leads own the Dynamics roadmap | Architecture and standards | Named developers and continuity |
07Straight answers
Asked before a Dynamics 365 budget is signed off.
01Do you configure Dynamics 365 or write custom code?
Both, decided against those four questions rather than habit. Most requirements are met through configuration and Power Automate, with plugin code reserved for logic that genuinely must run inside the save transaction.
02Can you migrate us from an older CRM or a different Dynamics environment?
Yes, and migration is priced and planned as its own stage with a named business owner for every object. Old environments do not get retired until reconciliation confirms nothing was lost in the move.
03Do you support Dynamics 365 Sales, Customer Service and Finance and Operations?
Yes, across all the core modules, and most engagements touch more than one because sales, service and finance data usually needs to agree with each other.
04How do you handle security roles for a large or complex team?
Roles get modelled on actual job functions rather than the out-of-box defaults expanded by exception. That model gets documented, so the next person to touch permissions inherits a design, not a guess.
05What does Dynamics 365 consulting cost?
Priced against module count, customization depth and migration complexity, from the scoping assessment. A single-module configuration costs far less than a combined sales, service and finance rollout.
06Can you integrate Dynamics with our other Microsoft tools?
Yes, Power BI reporting, SharePoint document storage and Power Automate workflows are common integration points, each scoped and tested as part of the same engagement rather than bolted on afterward.
07Do you build the Dynamics configuration and support it afterwards?
Yes, ongoing support and small enhancements can continue after go-live under the same team that built the configuration, so context does not get lost at handover.
08Is this a staffing arrangement or a delivery engagement?
A delivery engagement. We scope, configure, build and migrate as a commissioned team accountable for the outcome, rather than placing one developer inside your existing team.