Hire Microsoft Dynamics 365 experts

Hire Microsoft Dynamics 365 CRM developers

In short

MS Dynamics Guys provides Microsoft Dynamics 365 CRM (customer relationship management) developers who join your delivery team. They build and maintain C# plug-ins and custom APIs (application programming interfaces) on Dataverse, and form scripts in your CRM apps. Where standard controls fall short, they build Power Apps component framework (PCF) controls. Your lead sets the priorities. Before work starts, we agree in writing who reviews code, who tests and who approves releases. Share your CRM app, backlog and working hours to discuss the role.

Discuss a CRM developer See CRM development services

When a CRM developer from MS Dynamics Guys fits your team

This role goes by three names: Dataverse developer, Microsoft Dynamics CRM developer and Microsoft Dynamics 365 CRM developer. All three mean C# and script work on Dataverse, the platform under Microsoft Dynamics 365 Sales, Customer Service and Field Service. Someone on your side still decides what to build.

Team situations that call for this role

A release backlog nobody can code. Plug-in fixes, script changes and custom API requests slip from release to release, because nobody on your team writes C# for Dataverse.
Plug-ins nobody dares to change. A previous partner left assemblies, scripts and step registrations, and some steps may exist in only one environment. Your team cannot say what runs when a record is saved.
Configuration has reached its limit. Your team tried business rules and flows first, and some rules need logic that these tools cannot express.
Slow or failing saves. Users wait for saves or see errors, and someone must trace the plug-ins and scripts behind the form.
Another system needs a stable operation. Your integration team needs one defined operation on the Dataverse side, not direct table updates.

When another role or a project fits better

Most of the work is workshops, configuration, security roles and user acceptance testing (UAT). A Microsoft Dynamics 365 CRM consultant fits better.
The gap is environment setup, data import templates or the settings of a standard integration, not code. A technical consultant fits that work better. The page on Microsoft Dynamics 365 consultant roles explains where that role ends and development starts.
Your sales process must become lead, opportunity, pipeline and forecast settings that sales operations can test. A Microsoft Dynamics 365 Sales consultant fits that work better.
You want an agreed result delivered and accepted, not a person to direct. Choose a CRM development project.
The work is a canvas app or a set of cloud flows, not code that runs inside the save. A Power Apps developer or a Power Automate developer fits better. When one release changes apps, flows and tables together, a Power Platform developer fits that work.
Your system is Microsoft Dynamics 365 Business Central. Its extensions are written in AL, the programming language of Business Central, so a Business Central developer fits better.
Your system is Microsoft Dynamics 365 Finance or Supply Chain Management. Their extensions are written in X++, the programming language of finance and operations apps. A finance and operations developer fits better.
Nobody on your side can decide the rule behind each item or accept the result. Work through the engagement model worksheet before you add anyone.

Work a CRM developer can own

The developer owns the technical side of each item your lead assigns. Every item ends with something your team can review, test and keep.

CRM developer work from MS Dynamics Guys: what you receive and where the role stops
Work	What you receive	Where the role stops
C# plug-ins on Dataverse events	Code with unit tests, the step registration in your solution, and a design note on each step's stage, mode and filtering columns. The Plug-in Registration tool calls these columns Filtering Attributes.	Your process owner decides the rule and the message users see
Custom APIs	The API definition, the plug-in behind it, example requests and a note for the calling teams	Changes inside the calling systems stay with their owners
Form scripts in JavaScript or TypeScript	Web resources that use only the documented client API	Your CRM consultant or administrator first checks whether a business rule can do the job, as Microsoft recommends
PCF controls, where needed	A TypeScript control in your solution, checked with a keyboard and a screen reader	Your process owner agrees on the interaction before the build and accepts the control with real users
Solution changes and release preparation	Changes in your solution and source control, a managed build for test, and release notes	Your release approver decides when production imports happen
Defects and slow saves	A root-cause note based on traces, and a fix with a test that fails without it	Your process owner approves fixes that users notice, such as moving a check to a background step. If large data volumes cause the slowness, your data owners decide what to clean up or archive.
The Dataverse side of an integration	Operations and queries within service protection limits, with retries that wait as long as Dataverse asks	Middleware, monitoring and reconciliation of the whole interface belong to an integration engineer or an integration project

Can a developer from MS Dynamics Guys work within our current CRM solution?

Yes. Joining an existing solution is the normal start, not a special case. The developer builds inside your solution, under your publisher and its customization prefix. Components belong to the publisher of the solution where they were first created. Once a managed solution ships a component, its publisher is fixed, so a supplier's own publisher would stay on your components.

Before changing anything, the developer writes a short inventory for your lead. Your lead decides which findings become backlog items:

Plug-in assemblies and steps, with their stages, modes and filtering columns. The Plug-in Registration tool puts new registrations in the Default Solution. They reach other environments only once someone adds them to your solution, so some steps may exist in one environment only.
Custom APIs, form scripts and PCF controls, and the systems that depend on them.
Changes layered above your solution, including changes made directly in production, and the environment variables the code reads.

If another partner still maintains some of your solutions, agree in writing with that partner which solutions the developer may change. The developer does not change the partner's components without that agreement.

MS Dynamics Guys can also review the whole environment as a project and recommend what to keep, repair or retire. See CRM development and customization.

We confirm these version boundaries before we introduce anyone:

Microsoft Dynamics 365 online on Dataverse is the default scope of this role.
Microsoft Dynamics 365 Customer Engagement (on-premises) adds server, deployment and upgrade work. Tell us the exact version first. Microsoft does not support PCF controls in on-premises environments. On-premises experience is a separate decision for each role.
A move from on-premises to online is a migration project with its own plan. See migration and upgrade planning.
Field Service mobile and offline scenarios need Field Service experience on top of Dataverse skills, which we confirm for each candidate.

What the developer needs from your people

A developer cannot take over the decisions your team makes. Name these people before the first day:

A lead who sets priorities, answers business questions quickly and accepts finished items.
A code reviewer for pull requests. If nobody on your team reviews Dataverse code yet, agree in writing who does, for example a second MS Dynamics Guys engineer.
An administrator who creates named accounts, assigns security roles and licenses, and grants repository access. An invited guest user cannot open the apps until your tenant assigns a license and a security role. Only users with the System Administrator role can read the trace lines that plug-in code writes, so decide who reads them in each environment.
A process owner who defines the rule behind each item and the tests that prove it.
A release approver who decides when a managed solution reaches production.

How MS Dynamics Guys assesses a CRM developer

The core exercise is a plug-in review. The candidate reads a short sample plug-in that we wrote. Then they explain what happens to the save when the code succeeds, throws an error or runs later. The answers show whether a developer knows what their code does to live data.

CRM developer assessment: skill, review method and evidence
Skill	How we review it	Evidence the review produces
Transaction and error behavior	The candidate explains each step's stage (PreValidation, PreOperation or PostOperation) and mode (synchronous or asynchronous). They also say whether the step runs inside the database transaction, what rolls back when it throws and what the user sees.	Written review notes on the sample, ranked by risk
When code is the wrong tool	The candidate says which parts of the sample rule a business rule or a flow could handle instead, and why the rest needs a plug-in	A keep-or-replace note for each step, with the reason
Step registration	The candidate plans the registration of a new rule: message, stage, mode, filtering columns, images and the user the step runs as	A registration plan your reviewer can check against the code
Custom API design	The candidate designs one operation for another system: function or action, inputs, outputs, errors and the privilege a caller needs	A short API definition with the reason for each choice
Form scripts	The candidate reviews a form script, marks what a business rule could do instead and flags code that reaches into the page structure	An annotated script review
PCF controls	A walkthrough of a control the candidate built outside client work. If there is none, or your role needs no PCF work, a design discussion on a control we describe.	Notes on lifecycle, packaging and accessibility
Solutions and application lifecycle management (ALM)	The candidate explains how the sample change reaches production through solutions, source control, environment variables and a pipeline	Release steps, including how to turn a faulty step off
Tests	The candidate writes or outlines unit tests that run the sample rule without a live environment	Test cases for valid, invalid and missing values

Every candidate goes through the same technical screening process before an introduction.

Questions to ask in your own interview

Ask these questions with the person who reviews your Dataverse code. Each answer shows a decision that would otherwise surface only in a pull request or a failed release.

Interview questions for a Microsoft Dynamics 365 CRM developer
Question you can ask	A strong answer covers
When would you use a plug-in instead of a Power Automate flow?	Before choosing, the candidate asks three questions. Which entry points must the rule cover? Must the result be saved in the same transaction? Who will change the logic later? A candidate who picks the same tool for every rule is a warning sign.
How do you stop a plug-in from triggering itself again?	Filtering columns on the Update step, and values set in the PreOperation stage instead of a second update. No business logic built on the `Depth` value, which Microsoft reserves for loop prevention.
A user reports a generic error on save. How do you find the cause?	The plug-in trace log, if logging is on, before the daily cleanup job deletes records older than 24 hours. Then each step's stage and mode, a replay in a sandbox, and a fix with a test.
How does a change get from your machine to production?	Unmanaged in development, files in source control, managed in test and production, environment variables for settings, and a pipeline. Plug-in steps travel in the solution, not by hand in each environment.
What does your code do when Dataverse returns 429 Too Many Requests?	It waits for the time in the Retry-After header, then retries. It also lowers request volume or parallel calls instead of retrying at once.
How do you secure a custom API?	An Execute Privilege Name set to an existing privilege, and rights checks in the plug-in. No silent elevation, such as plug-in code that calls Dataverse as a more privileged user than the caller.

An illustrative first work package

Illustrative example: not a client case

This example is illustrative. It is not a client case, and it is not a delivery-time promise. Timing depends on your access, your reviews and your release calendar.

In this example, the developer works inside your team. Your lead assigns the item and accepts it when the criteria below are met.

The backlog item. Your finance team wants a rule: a subsidiary account's credit limit must not exceed its parent account's limit. The rule must hold for form saves, data imports and Web API calls. Your consultant confirms that configuration cannot express it, so the item goes to the developer.

What the developer delivers:

A one-page design note on the steps, stage, filtering columns, pre-image and error text. For this rule, that means Create and Update steps on the account table in the PreValidation stage, which usually runs before the database transaction starts. Credit limit and parent account are the filtering columns of the Update step, and the pre-image supplies values that an update does not send.
The plug-in code and its unit tests, in a pull request to your repository.
The assembly and both steps, added to your existing solution under your publisher prefix.
Test evidence from your test environment: one form save, one import file and one Web API call.
Release notes with the import steps, and how to turn the steps off if the release causes problems.

Acceptance criteria:

A credit limit above the parent's limit is rejected with the agreed message on all three entry points.
Valid changes save as before, and updates that do not include credit limit or parent account do not run the check.
Unit tests cover lower, equal, higher and missing values, and they pass in your pipeline.
The managed solution imports into test without manual steps.
Your reviewer approves the pull request, and your release approver signs off the release.

Two questions stay open and become new backlog items. What happens to existing subsidiaries when a parent's limit drops? Which amounts are compared when accounts use different currencies?

Outsourced CRM developer or outsourced result: ways to engage

Buyers who ask for an outsourced CRM developer may want a person who works in their backlog, or a result that MS Dynamics Guys delivers. One question decides: can someone on your side direct the developer day to day and accept each item? If yes, add a developer to your team. A missing Dataverse code reviewer does not rule that out. The agreement then names one, for example a second MS Dynamics Guys engineer. If you need delivery against an agreed scope instead of day-to-day direction, discuss a CRM development project. Your business owner still approves the scope and accepts the result against written criteria.

Ways to engage a CRM developer and who directs the work
Option	Who directs the work	What MS Dynamics Guys answers for	More about the model
One developer in your team	Your lead, through your backlog, stand-ups and review rules	The developer's skills, conduct and continuity under the agreement	Staff augmentation

Allocation, notice, minimum term, replacement process and rate basis are agreed in writing for each engagement. This page quotes no rates and no start dates. The guide to staff augmentation and project delivery sets the models side by side, with their risks and pricing bases.

How a CRM developer engagement starts

No step has a fixed duration, and we give no shortlist date or start date in advance. How a role brief becomes a shortlist covers the general path. These steps show what changes for a CRM developer.

You send a role brief
Name the CRM app and version, and whether it runs online or on-premises. List the backlog items, your repository and pipeline tools, your working hours and who will direct the developer.
We review scope and fit
We sort your backlog items into code for a developer, configuration for a CRM consultant or a result for a CRM development project. Before anyone is introduced, we confirm in writing whether we can staff the role and cover the hours you need.
You meet assessed candidates
You see real profiles only for people who passed the plug-in review, each with a written summary of the assessment. We do not show sample profiles or availability lists.
Technical interview
Your lead and your code reviewer interview each candidate, starting from the questions on this page. You decide who joins.
Written agreement
It names who reviews code, who tests and who approves releases, and the first work item with its acceptance criteria. It also covers shared hours, allocation, notice, minimum term, replacement, rate basis, confidentiality and ownership of the work.
Access, onboarding and first acceptance
Named accounts with the smallest roles the work needs, development before production, and a walkthrough of your solution. Then the first item is reviewed and accepted against its criteria.

Proof you can check yourself

This page shows no client names, testimonials or case studies. Instead of claims, you can check the work itself:

The written summary of each candidate's plug-in review, with the risks they found, the risks they missed and questions for your interview.
The first pull request in your repository, with unit tests that run in your pipeline before anything reaches production.
The demonstration below, which shows the kind of notes the plug-in review produces.

You can also read how we assess specialists, including who reviews each exercise and what an assessment cannot show.

Demonstration: review notes on a sample plug-in written for this page, not client code
Finding in the sample	Why it matters	Change the reviewer asks for
An Update step with no filtering columns	The plug-in runs on every update of the table, even when nothing it checks has changed	Register only the columns that the rule reads
A PostOperation step that updates the same record again	The second update starts a new Update event, so the logic can repeat and every save slows down	Set the values in the PreOperation stage, so they are saved with the original operation
A synchronous PostOperation step that throws a generic exception	The whole operation rolls back, and the user sees a generic error instead of the reason	Check the rule in the PreValidation stage and throw `InvalidPluginExecutionException` with a clear message
A synchronous call to an external service with no timeout	The .NET default timeout is 100 seconds, and the whole operation must finish within 2 minutes. The user waits the entire time	Set a short timeout, or move the call to an asynchronous step or an integration
Service and context objects stored in class fields	Dataverse caches plug-in instances and can run one instance on several threads, so data can leak between calls	Keep the class stateless and read everything from the execution context

This is an original demonstration. It does not come from a client system, and it does not describe a candidate. In a real assessment, the candidate writes notes like these, then explains step by step what each problem does to the transaction.

Practical questions about hiring a CRM developer

Where does the developer's work end and a CRM consultant's begin?

A CRM developer from MS Dynamics Guys implements code items under your lead's direction. Configuration and code travel in the same Dataverse solution, so the boundary follows the assigned requirement. The developer may add a column that a plug-in fills or the form event that loads a script. A CRM functional consultant, or your administrator, owns process configuration: forms, views, business rules, security roles and UAT scripts. Rules that configuration cannot express reach the developer as written requirements. If you need delivery against agreed acceptance criteria rather than a person in your team, discuss a CRM development project.

Why does the assessment review a plug-in instead of asking for new code?

Most developers who join an existing solution first work in code that someone else wrote. The review shows whether the candidate can predict what a plug-in does to a live save before changing it. The candidate also writes or outlines unit tests for the sample rule, so the summary covers writing code too. If your role also needs a coding task, how we assess specialists explains when we can use an exercise you provide.

What changes when the CRM developer works remotely or in another time zone?

The developer works in your systems, but their hours may differ from yours, so plan for failed saves as well as meetings. By default, a daily job deletes plug-in trace records once they are older than 24 hours. Agree who keeps a copy of the trace when a save fails outside the developer's hours. Then plan shared time for pull request reviews and production imports. Put the hours you need in your role brief. Before any introduction, we confirm whether candidates can cover them.

Does a solution file include the source code of our plug-ins?

No. A solution carries the compiled plug-in assembly, not the C# source code that the next developer needs. So the C# and TypeScript source goes into your repository from the first commit. Components go into your solution under your own publisher. The agreement sets ownership of code and documents before work starts.

Can someone else release our plug-ins if the developer leaves or is away?

Yes, if releases do not depend on one person's machine or account. Plug-in steps travel inside your solution, and your pipeline builds the solution from your repository. Give a second person on your team the rights to run that pipeline and to import the managed solution. A release can then go ahead while the developer is away, and your release approver still decides when it reaches production. Notice and the replacement process are agreed in writing for each engagement.

Which costs come with a CRM developer besides the rate?

The rate basis is agreed in writing for each engagement, and this page quotes no rates. Two other costs are easy to miss. If a second MS Dynamics Guys engineer reviews the code because nobody on your side can, the agreement includes that review time. The license for the developer's account in your tenant is a cost on your side. Time-based pricing is common when a specialist joins your team, and scope-based pricing when a supplier owns a defined result. Comparing staff augmentation with project delivery shows how the two share risk.

What does the handover record for each plug-in step and custom API?

For each plug-in step and custom API, the written handover records its purpose, what triggers or calls it, and the tests that cover it. It lists the environment variables the code reads. It also names each step that needs secure configuration, because a solution export leaves that configuration out. Beyond that, it covers open items, design decisions, known risks and how to build and release the solution. The handover stays in your workspace, and your administrator removes the developer's accounts on the last day.

Discuss a CRM developer for your backlog

Send a few plug-in, script or custom API items from your backlog, with the CRM app and version. Say whether their source code is in your repository, and who will review code and approve releases. We reply with questions or a proposed role before any introduction.