A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Dynamics 365 is a product family rather than a product, and the distinction decides who you should be hiring.
Finance & Operations descends from AX. It is ERP, the extension language is X++, and the people who work in it think in ledgers, warehouses, and production orders. Customer Engagement descends from CRM. It sits on Dataverse, extends through C# plugins and the Power Platform, and the people who work in it think in accounts, cases, and business process flows. Business Central is a third lineage again, out of NAV, aimed at smaller organisations.
Someone strong in one is usually a beginner in another. The branding implies a single skill set and the daily work does not. Adverts that say “Dynamics 365 developer” without naming the application reliably attract the wrong half of the market, and the mismatch tends to surface about two weeks into the engagement.
Finance & Operations, Customer Engagement, or Business Central stated explicitly. The most common mis-hire in the ecosystem starts here.
Reaching for a business rule or Power Automate before writing a plugin. Cheaper to build, cheaper to change, and visible to your admins.
Extending through supported patterns rather than hacks that survive only until the next wave update moves something underneath them.
Table design, relationships, and security roles. Weak modelling here is expensive and disruptive to unwind later.
Understanding the execution pipeline, synchronous versus asynchronous, and why a slow plugin times out a form for everyone.
Design decisions that quietly move users into a more expensive tier. Rarely screened for and routinely costly.
Microsoft ships two major updates a year, and they arrive whether or not you are ready for them.
That cadence is why unsupported customisation is more dangerous here than on a platform you host yourself. Direct database writes, undocumented API use, JavaScript that depends on the shape of a rendered form — all of it works until a wave update changes something beneath it. Then a form stops saving on a Tuesday morning with no deployment of your own to blame, and the person who wrote it left eighteen months ago.
The second cost is licensing, and almost nobody screens for it. Design choices push users between tiers: a custom table that needs full access, a security role granting more than intended, an integration account that turns out to require per-user licensing. The build works exactly as specified, the annual bill moves by a number nobody budgeted, and it is discovered at renewal rather than at design.
The third is the plugin that should have been a flow. Code in Dynamics carries a real tax — it needs a developer, a deployment, and a solution to move it between environments. A business rule or a Power Automate flow doing the same job can be changed by someone in the business in an afternoon. Teams that default to plugins build a codebase they cannot staff, and every small process change re-enters the development queue behind everything else.
Developer (3–5 years). Configures and builds within one application, following patterns already in place. Comfortable with solutions and environments. Needs review on data model and integration decisions.
Senior (5–8 years). Owns the Dataverse model, the security design, and the low-code versus code judgement. Runs requirements sessions with the business and can refuse an unsupported approach with reasons attached.
Solution Architect (8+ years). Cross-application design, the integration estate, ALM across environments, and licensing implications. Worth the premium when you run more than one Dynamics application or a migration is in scope.
Customer Engagement build-outs. Sales and Customer Service configuration with the automation around them. The most frequent request we take.
Power Platform development. Model-driven and canvas apps on Dataverse, usually replacing a process currently held together by a spreadsheet and email. Where the app estate itself is the concern, see Power Platform developers.
Integration work. Connecting Dynamics to an ERP, a finance system, or a warehouse. On programmes touching several systems at once, a solution architect normally owns the interface contracts. See enterprise application services.
Finance & Operations development. X++ extensions, reporting, and data entity work. A narrower market, priced accordingly.
Legacy CRM migration. On-premises Dynamics moving to the cloud, along with the unsupported customisations that inevitably came with it.
ALM and environment hygiene. Solutions, managed layers, and a deployment path that does not rely on somebody making the same change twice by hand. Requested late and worth requesting early.
Week one. They inventory the customisations before adding to them. Expect a list of what runs as plugins, what as flows, what as JavaScript on forms, and which of it is unsupported. Expect them to check solution layering across environments too, because ALM problems in Dynamics are usually older than whatever symptom exposed them.
Weeks two to four. They fix or flag whatever is most likely to break at the next wave update and deliver one visible improvement. Expect at least one request to come back as “this is a business rule, not a plugin”, with an explanation of what that saves you over the following two years.
The warning sign is a developer who writes code for everything. It is faster for them, and it is why so many Dynamics estates need a developer on retainer for changes that should take an admin an afternoon. Ask what they moved out of code, not only what they built. The answer tells you whether you have hired someone who will reduce your dependency on them or quietly deepen it over the next two years.
Advertising for a “Dynamics 365 developer”. Name the application. Without it you will interview Finance & Operations people for a Customer Engagement role and spend a fortnight finding out.
Unsupported customisation for speed. It works now and breaks on Microsoft’s schedule rather than yours. Supported extension points exist precisely because the platform underneath you moves twice a year regardless.
Ignoring licensing until renewal. Ask what a design decision does to your licence position while it is still a design decision. The answer costs far less at that point than after the build has shipped.
Treating Power Platform skills as interchangeable with Dynamics skills. There is genuine overlap in Dataverse and Power Automate, and genuine distance in the application knowledge. A strong canvas app builder may never have configured a business process flow or debugged the plugin pipeline.
Rates depend on application, seniority, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.