Hire Microsoft Dynamics 365 experts
Hire Microsoft Dynamics 365 finance and operations developers
In short
MS Dynamics Guys provides developers who write X++, the programming language of Microsoft Dynamics 365 Finance and Supply Chain Management. The developer builds extensions, data entities, integrations and batch jobs in your repository, under your lead's direction. Your process owners and functional consultant decide how posting and inventory behave. Each developer is assessed on extension design and failure diagnosis before you meet them. Work on Dynamics AX 2012, the older product, is a separate role.
When an X++ developer from MS Dynamics Guys fits your team
In Finance and Supply Chain Management, the person who decides how posting or inventory works is rarely the person who writes the X++ code. This role writes it. It fits when your process owners and functional consultant can say what should happen. The gap is then building, testing or repairing the code.
Team situations that suit an X++ developer
- Your functional consultant has approved designs that are waiting for X++ code.
- Recurring imports or OData (Open Data Protocol) calls from other systems fail, and nobody can say whether data, code or throttling causes the errors.
- Batch jobs started to fail after a service update, and nobody owns the code behind them.
- You inherited extensions from a partner that has left, with no automated tests and no design notes.
Another role or service fits better when
- The open questions are about posting, inventory or setup, not code. Start with a Finance consultant or a Supply Chain Management consultant, or compare consultant roles first.
- The open decision is architecture: how apps, integrations and security fit together. A solution architect makes it, and the developer builds to it.
- The gap is middleware, monitoring and reconciliation across several systems. That is work for an integration engineer.
- Legacy data must be loaded into Finance or Supply Chain Management and reconciled. A data migration engineer owns the loads and the reconciliation. The developer builds a data entity only when no standard entity fits.
- Your system is still Dynamics AX 2012. Its code needs AX skills, and a move needs a migration plan first.
- Your system is Microsoft Dynamics 365 Business Central, which uses another programming language, AL. See Business Central developers.
What belongs to the X++ developer, and what to the functional consultant?
Each row is a task that both roles touch. The developer owns the code, the functional consultant owns the process design and setup, and your team keeps the business decisions.
| Task | X++ developer | Functional consultant | Your team |
|---|---|---|---|
| Posting, inventory and other setup, including Electronic reporting (ER) formats | Writes code only for what setup and ER cannot do, and explains why | Designs, configures and tests the setup | The process owner approves how the process behaves |
| Extensions, data entities, service endpoints and batch classes | Builds, tests and documents them in your repository | Writes the design and the test scripts | Your lead sets the priority |
| A failed integration message or batch job | Fixes causes in code, retry behavior and throttling | Fixes mapping and master data | The process owner decides what is processed again |
| Security for new menu items and services | Creates a privilege for each new entry point | Maps duties to security roles | Your administrator assigns users to roles |
Electronic reporting is Microsoft's tool for formats such as payment files and regulatory reports. Microsoft designed it for business users, who configure formats without a developer. So the developer checks setup, ER and standard features first, and writes code only for the gap that remains.
Microsoft's implementation guidance warns against making a technical role accountable for business outcomes. In this split, the developer answers for the code, and your process owner answers for how the process works.
If you need the consultant as well, MS Dynamics Guys can add one to the same workstream: see Finance consultants or Supply Chain Management consultants.
Work an X++ developer can own in your team
Finance and Supply Chain Management do not support changes to Microsoft's code, so the developer changes standard behavior only through extensions. Each row names the work and what your people provide.
| Area | What the developer delivers | What your team provides |
|---|---|---|
| Business logic | Class extensions with Chain of Command: a wrapper around a standard method that must call next, so Microsoft's logic still runs. Event handlers where a standard event fits better. | An approved design, and a process owner who confirms the new behavior |
| Tables and forms | Table and form extensions that add fields, indexes, methods and controls without editing Microsoft's objects | Naming rules and the extension model that holds your code |
| Data entities and services | Data entities for imports, exports and OData calls, and custom services where no entity fits the task | The owner of each connected system, and the data rules that both sides follow |
| Business events | New business events, built as extensions, that tell other systems when something happens. Microsoft designed them to notify, not to export data. | The receiving endpoint, such as Azure Service Bus or Power Automate, under your own subscription |
| Batch classes | Batch jobs that are safe to retry, with a written rule for what happens when a task runs twice | The batch schedule and the time windows in which jobs may run |
| Security | A privilege for each new menu item and service operation, so that only the intended roles can use it | Role design, and user assignment by your administrator |
| Automated tests | Unit and component tests with SysTest, Microsoft's X++ test framework, in a test model that your build runs | Agreed test data, and the rule for where tests must pass before a release |
| Builds and packages | Builds that compile your models into packages, and the deployable package that your release process applies | Your release calendar, and the person who approves each production deployment |
When no extension point exists. Some methods are closed to wrapping, for example methods marked [Hookable(false)]. The developer then looks for another method or event first. If none fits, the developer drafts an extensibility request to Microsoft. Microsoft does not promise to deliver every request and does not ship them as hotfixes, so the design note also names a fallback.
Microsoft Dynamics 365 Commerce work belongs to a Commerce developer, not to this role. That includes channel code, such as point of sale (POS) extensions. It also includes the X++ in Commerce headquarters that serves the stores, such as Commerce Data Exchange (CDX) jobs and statement posting. See Commerce specialists.
Dynamics AX 2012 code needs a different role
How we assess an X++ developer before you meet them
Each candidate works through one written scenario with invented data in a demonstration environment, not in your system. The scenario covers extension design and the diagnosis of failures. A reviewer who works in X++ checks the work and asks the candidate to explain each choice. You receive the written result before your interview, and only candidates who pass are introduced.
| Skill | Exercise | Evidence you receive |
|---|---|---|
| Extension design | Turn a short functional specification into a design: the objects to extend, the methods to wrap and the events to handle | An extension design note |
| Extension points | The design needs a method marked [Hookable(false)]. Find another extension point, or draft an extensibility request with a fallback. | The alternative, or the draft request and its fallback |
| Integration diagnosis | A recurring import ends with the status ProcessedWithErrors. The middleware log shows 429 Too Many Requests responses, which tell a caller to slow down. Separate data, code and throttling causes. | A diagnosis note that ranks each cause with its evidence |
| Batch retries | A batch task failed when the database connection dropped for a moment. Decide whether the class may be marked as retryable, and show what happens if a task runs twice. | A retry decision with an idempotency check |
| Security | Users cannot see a new menu item. Trace the privilege, duty and role, then test with a user who has only the intended role. | The privilege fix and the role test |
| Tests and release | Write a SysTest test for the change, run the build and write release notes for the package | Test results, build output and release notes |
Idempotent means that running a step twice gives the same result as running it once. How we assess specialists explains who reviews each exercise and what an assessment cannot show.
The extension-design task also appears in the buyer scorecard for Microsoft Dynamics 365 specialists, so you can give candidates from other suppliers the same task.
Example first work package: a failing recurring vendor invoice import
One X++ developer, a team under one lead, or a defined fix
Two questions pick the option. Who on your side can plan X++ work around the next service update? Who should answer for the result: your company, or MS Dynamics Guys against criteria you approve?
| Option | Who plans the daily work | Who answers for the result | Suits a team that |
|---|---|---|---|
| One developer in your team: staff augmentation | Your lead, through your backlog and your sprint plan | Your company owns the outcome. The developer answers for the quality of each change. | Has a lead who can set priorities and review X++ code |
Allocation, working hours, overlap with your team, minimum term, notice and replacement are agreed in writing per engagement. Staff augmentation versus project delivery compares the three models and includes a decision worksheet.
From role brief to a working X++ environment
The hiring hub's page on how a role brief becomes a shortlist covers the general path, with no fixed durations. The steps below add what an X++ role needs from your side. That means an environment with enough database capacity, access to your build pipeline and a place in your service update calendar.
Role brief
Name your apps and version, the modules in scope, the backlog waiting for code, where your repository and build pipeline live, and your release calendar. Add who directs the work, the hours to cover and how long you need the role.
Fit review
Send two or three backlog items or tickets, with sensitive data removed. Our written reply says which need X++ code and which belong to setup, data loads or the calling system. It also says whether we can staff the role.
Assessed candidates only
The reviewer's written result comes with each profile. It shows how the candidate separated data, code and throttling causes in the failing import.
Your interview
Your lead or a senior X++ developer interviews each candidate. Bring one real failing job or waiting design, with sensitive data removed, and ask which evidence the candidate would read first. You decide who joins.
Written agreement
The agreement states who directs the work, who reviews X++ code and who approves each deployable package for production. It also covers intellectual property, working hours, overlap, notice and replacement.
Named access
No access is granted before the agreement is signed. Your administrator then issues named accounts for source control and the build pipeline. A developer environment and a sandbox follow, each with only the security roles the work needs. Production access is granted for one task at a time.
Onboarding and first acceptance
Your team walks the developer through your models, integrations and batch schedule. The first task is a small real item with written acceptance criteria, and your lead accepts it before larger work starts.
Before the first day, prepare the accounts, the environments and the first task with an onboarding checklist for external specialists.
Can an X++ developer from MS Dynamics Guys work in our repository and release process?
Yes. The developer works in your source control, follows your branch and review rules and releases only through your process. Four things need to be ready before the first task.
- Repository access. A named account in your source control. Code reaches your main branch only after a review by someone your lead names.
- A developer environment. X++ is written in Visual Studio, connected to a development environment. Since February 16, 2026, new customers start cloud projects for Finance and Supply Chain Management in the Power Platform admin center, not in Lifecycle Services. In Power Platform, your administrator creates a unified developer environment (UDE) for each developer. A UDE is a sandbox for one person's X++ work, not the Power Platform environment type called Developer. Each UDE needs at least 1 gigabyte of free Operations database capacity and 1 gigabyte of free Dataverse database capacity. Customers with an existing Lifecycle Services project can keep using it.
- A sandbox for tests. The developer tests each package in a sandbox, with test data that your team approves, before you release it.
- Release approval on your side. Your release manager decides when a deployable package reaches production. The developer prepares the package, the release notes and the checks to run after deployment.
Your lead sets priorities through your backlog, and the developer reports progress in your tools. The developer does not change production data or setup directly. When a fix needs production access, your administrator grants it for that task.
If nobody on your side can review X++ code yet, say so in the role brief. We then agree in writing who reviews the code before the start.
Evidence you can inspect before the first commit
No client names, reviews or case studies appear on this page. A client story would need that client's written permission first.
MS Dynamics Guys wrote the notes below for this page as an original demonstration of strong answers to the X++ scenario. They come from no client system and from no candidate. The scoring rubric shows how a reviewer grades notes like these.
| What the candidate sees | What a strong answer checks first | What the notes conclude |
|---|---|---|
| A recurring import message ends with the status ProcessedWithErrors | The execution errors for that message and the rejected rows in staging, before any code is read | Three rows name a vendor account that does not exist. That is master data for the process owner. One row fails a check in custom code, which is a defect for the developer. |
| The middleware log shows 429 Too Many Requests on the same night | Which calls received the 429 responses. Microsoft currently exempts recurring integrations and the data management framework from its service protection limits. | The 429 responses came from separate OData calls that look up vendors, so throttling did not reject the rows. The OData caller still needs to wait and retry, and its owner receives a note. |
| A batch task failed when the database connection dropped for a moment | What happens if the task runs twice, before the class is marked as retryable | The task sends a confirmation email. It must check a log of sent emails first, so that a retry does not send a duplicate. |
| Users cannot find a new menu item | A test with a user who has only the intended role, not an administrator account | No privilege grants the new menu item. The developer creates one and adds it to the duty that the functional consultant chose. |
The design wraps a method marked [Hookable(false)] | Whether another method or event in the same process can carry the logic | The design moves to a standard event that fits. If none had fit, the note would draft an extensibility request with a fallback. |
The notes give each cause an owner. Master data goes to the process owner, throttling to the owner of the calling system and code defects to the developer. A candidate who sends every error to the developer has not separated the causes.
Questions about hiring X++ developers
Can the same developer maintain our Dynamics AX 2012 system?
Not as part of this role. AX 2012 customizations usually change Microsoft's code directly, so they need AX skills and an AX environment. Microsoft also does not plan to take extensibility requests for AX 2012.
The X++ developer helps once you move. Microsoft currently supports upgrades to finance and operations apps only from AX 2012 R2 and R3. After the migration plan decides which customizations to keep, the developer rebuilds each one as an extension and records which AX object it replaces.
Can the developer fix failing integrations and batch jobs in our live system?
Yes, within the access your administrator grants. The developer reads the evidence first. For data management jobs, that is the job history, the staging data and the execution log. For recurring imports, it is each message's status and its execution errors. Code fixes are built in a development environment, tested in a sandbox and released through your process. Rows rejected for data reasons stay your process owner's decision: correct them in staging, or fix the source file and import it again.
How do Microsoft's service updates affect our extensions?
Microsoft built the extension model so that updates are less likely to affect custom code. Your extensions still run against new standard code, so each update needs a test. You take at least two of Microsoft's four service updates a year, and an automatic update reaches your sandbox seven days before production.
For each update you take, the developer compiles your models against the new version in a development environment and runs the SysTest tests. The developer then deploys the package to the updated sandbox, runs the integration checks and writes a readiness note. Your process owners then retest the processes they rely on.
Plan the test tools as well. Microsoft ends support for the Regression suite automation tool (RSAT) after May 15, 2027, and it advises against RSAT for unit tests. Code-level tests belong in SysTest.
Does the developer need to be online when our batch jobs and imports run?
Usually not. Most diagnosis works from job histories and logs on the next working day. The evidence does not stay forever: files submitted to a recurring import are deleted after seven days. Agree in writing which hours the developer covers and whether anyone is on call. Name the exceptions too, such as go-live weekends, the test week before a service update and the batch runs your month-end close depends on. Put your time zone and batch schedule in the role brief.
If we change suppliers later, can the next team build and release our extensions?
Yes, if the next team can rebuild every deployable package from your systems. The code alone is not enough. Your systems must also hold the model files with their dependencies and the build definition. They must also hold the packages of independent software vendor (ISV) solutions that your extensions reference. A release log shows which package version runs in each environment. Before a planned exit, the developer rebuilds one package and deploys it to a sandbox with a person you name. The steps are then proven, not only written. Ownership of the code follows the intellectual property terms of the agreement.
Who pays for the developer's environment and database capacity?
Usually you do. Your Finance and Supply Chain Management environments and licenses belong to your tenant, and you buy them separately from the engagement. Each UDE draws on your tenant's Operations and Dataverse database capacity, so check that capacity before the start date. Under an existing Lifecycle Services project, ask your administrator what your current development environments cost. The developer's rate basis is agreed in writing per engagement, and this page quotes no figures. Plan your team's time as well, because code reviews, test data and acceptance take hours on your side. The guide to the cost of hiring a Microsoft Dynamics 365 developer compares these costs across products.
Tell us what is waiting for X++ code
Share your apps and version, the extensions or interfaces involved, your release calendar and who will direct the work. Our written reply sorts the work into X++ code, setup and middleware before anyone is introduced.
Product documentation referenced on this page
- X++ language reference Microsoft Learn, checked October 4, 2026
- Extensibility home page Microsoft Learn, checked October 4, 2026
- Class extension: method wrapping and Chain of Command Microsoft Learn, checked October 4, 2026
- Extensibility requests Microsoft Learn, checked October 4, 2026
- Data entities overview Microsoft Learn, checked October 4, 2026
- Data management overview Microsoft Learn, checked October 4, 2026
- Recurring integrations Microsoft Learn, checked October 4, 2026
- Service protection API limits Microsoft Learn, checked October 4, 2026
- Business events overview Microsoft Learn, checked October 4, 2026
- Enable batch retries Microsoft Learn, checked October 4, 2026
- Role-based security Microsoft Learn, checked October 4, 2026
- Security architecture Microsoft Learn, checked October 4, 2026
- Testing and validations Microsoft Learn, checked October 4, 2026
- Regression suite automation tool (RSAT) Microsoft Learn, checked October 4, 2026
- Models and packages Microsoft Learn, checked October 4, 2026
- Electronic reporting (ER) overview Microsoft Learn, checked October 4, 2026
- Service update availability Microsoft Learn, checked October 4, 2026
- Unified developer experience for finance and operations apps Microsoft Learn, checked October 4, 2026
- Unified environment types and templates for finance and operations apps Microsoft Learn, checked October 4, 2026
- Tutorial: Provision a new environment with an ERP-based template Microsoft Learn, checked October 4, 2026
- Create and manage environments in the Power Platform admin center Microsoft Learn, checked October 4, 2026
- Lifecycle Services project creation freeze Microsoft Learn, checked October 4, 2026
- Enable custom Commerce Data Exchange synchronization via extension Microsoft Learn, checked October 4, 2026
- Upgrade from AX 2012 to finance and operations Microsoft Learn, checked October 4, 2026
- Organize your Microsoft Dynamics 365 project team Microsoft Learn, checked October 4, 2026
- Types of tests that implementation projects use Microsoft Learn, checked October 4, 2026