Technical screening
How we assess Microsoft Dynamics 365 specialists
In short
MS Dynamics Guys assesses each Microsoft Dynamics 365 specialist before you meet them. The candidate completes a practical task for the role and product track, then explains the work to a reviewer from the same track. The reviewer scores it against written criteria. You receive a summary of what we tested and the gaps we found. No assessment proves how someone will work in your environment, so your own interview decides.
What each candidate does: one standard task per role and product track
A product track is one product, or a group of apps built in the same way. Skills carry over only partly between tracks, so each track has its own task. A task can have a few short parts, such as a code review and a test plan. Each linked role page describes the full exercise.
In this table, CRM means customer relationship management: apps such as Microsoft Dynamics 365 Sales and Microsoft Dynamics 365 Customer Service, which run on Microsoft Dataverse. They form one product track.
| Role | Task the candidate completes | What the reviewer checks | What only your interview can test |
|---|---|---|---|
| Microsoft Dynamics 365 CRM developer | Reviews a short Dataverse plug-in that we wrote, and explains what it does to a save when it succeeds, fails or runs later | Transaction and error behavior, step registration, unit tests and the release path through solutions | How the candidate works with your solution layers, your publisher prefix and your release calendar |
| Microsoft Dynamics 365 CRM consultant | Walks a reviewer through a written sales or service process, maps each step to a standard feature or setting, and marks each step that needs code | Standard features tried first, the scope of each rule, access rules for teams that share one system, and one test script a process owner can run | Your real processes, your users and the decisions that only your process owners can make |
| Microsoft Dynamics 365 Sales consultant | Turns a written sales process from an invented company into a configuration plan that a sales operations team could test | Lead and opportunity design, forecast design, access for sales roles and a test for every rule in the plan | Your sales process, your forecast reviews and how your sellers work in Outlook and Microsoft Teams |
| Microsoft Dynamics 365 Business Central developer | Builds a small extension in AL, the Business Central programming language, with automated tests, then explains each extension point it uses | Events instead of copied standard code, tests for valid and invalid input, and code that another developer can maintain | Your installed extensions, the apps you depend on from other publishers and your update calendar |
| Business Central consultant | Explains a posted sales invoice entry by entry, names the setup that decided each account, then plans a month-end reconciliation | Posting logic, dimensions, the order of period-end tasks and a clear line between setup and custom code | Your chart of accounts, your country version and your month-end routine |
| Power Platform developer | Plans solutions and a release path for one workflow that crosses an app, a cloud flow and Dataverse tables, then explains the plan | Solution boundaries, settings that change between environments, who owns each deployed app and flow, and tests across components | Your environments, your governance rules and the owners of each app and flow |
| Power Apps developer | Designs one app with its permissions, then reviews an app that we wrote with planted flaws | The choice of app type, permissions for each user group, queries that still work on large tables and formulas another developer can follow | Your data volumes, your users' devices and who shares and owns each app |
| Power Automate developer | Finds why a cloud flow fails from its run history, then writes a recovery plan | Triggers, error handling, retries that cannot create duplicates, flow ownership and monitoring | Your connections, the accounts that own your flows and your monitoring routine |
| Microsoft Dynamics 365 Finance or Supply Chain Management consultant | Works through one finance or warehouse scenario, including its exceptions, and plans the tests that would prove it before go-live | Process fit, legal entity or warehouse choices, exception handling and the reconciliation of migrated data | Your legal entities, your sites and the sign-off rules of your finance team |
| Finance and operations developer | Designs an extension in X++, the programming language of Microsoft Dynamics 365 Finance and Supply Chain Management, and diagnoses a failing batch job or integration | Extensions only, because these apps do not support changes to Microsoft's code, plus event use and release practice | Your models, the solutions you run from other vendors and your update calendar |
| Technical consultant | Turns one agreed requirement into a specification that a developer could build from | The data the change touches, integration settings, failure handling, release steps and a clear line between setup and code | Your environments, your integrations and the developers who will build from the specification |
| Solution architect | Critiques a reference architecture that we wrote, then compares two options for one integration or security decision | Integration boundaries, security design, expected volumes and response times, and decisions written down with their reasons | Your current systems, your constraints and who approves design decisions in your organization |
| Integration engineer | Maps the records that one interface moves, then plans how failed messages are found, retried and reconciled | Which system owns each record, retries that do not create duplicates, monitoring and a reconciliation check | Your middleware, your monitoring tools and the owners of the other systems |
| Data migration engineer | Maps a sample source extract to target tables, then writes the error and reconciliation report for one trial load | Data profiling, transformation rules, totals that prove nothing was lost, and the limits of a rollback | Your source systems, the quality of your data and how much history you keep |
| Quality assurance (QA) engineer | Plans the tests for one change: a risk ranking, passing and failing test cases, and a report on a planted defect that others can reproduce | Risk ranking, regression scope, a test tool for each layer, permission tests with a restricted test user, and test data without personal data | Your test tools, your release calendar and the business users who run acceptance tests |
| Release engineer | Reviews a release pipeline that we wrote with planted defects, maps where each credential is stored, and explains what a rollback can undo | Approval before production, credentials kept out of code and logs, and the rollback limits of each product | Your pipelines, your environments and who approves a production release |
If your role is not in this table, ask us. Before any assessment starts, we tell you in writing which task applies and what it covers. If we do not offer the role, we say so.
How we design each task
A useful task looks like real work, so the result says something about the job. Five rules shape every task:
- Work, not trivia. The candidate reviews code, configures a process or explains a design, as the role requires. We do not ask exam questions about menu paths or product trivia.
- Original scenarios. MS Dynamics Guys writes the scenarios, code samples and data for its standard tasks. They contain no client code, client data or personal data.
- Small parts. Each part of a task covers one small problem, so it tests judgment, not working speed. Candidates do not do real client work as a test.
- Explained out loud. The candidate walks a reviewer through the work, because the reasoning matters as much as the result.
- One standard per role. A role brief is your short description of one role and the work waiting for it. All candidates for the same role brief get the same task and the same written criteria, so you can compare their results directly.
Microsoft's guidance shapes the criteria. Microsoft advises trying logic that you configure, such as business rules and Power Automate flows, before you write a Dataverse plug-in. So the CRM developer task asks which parts of a sample rule a business rule or a flow could handle instead.
Microsoft recommends AL tests for both successful and failing conditions, so the Business Central developer task asks for both kinds of test.
How does MS Dynamics Guys run an assessment?
These steps show the assessment part of the path from role brief to shortlist in detail. The first two steps happen while we check your role brief with you. The others start after we match candidates to the role. We set no fixed duration for the steps, and we promise no date for a summary.
We map your role brief to the task
We compare the requirements in your role brief with the standard task for the product track. You get a written note on what the task covers and what only your interview can test.
We fit the scenario to your role
If you share backlog items, we adapt the scenario to resemble them, with invented names and data. Every candidate for the role then gets the same version.
The candidate works on the task
The candidate works on the task material, outside your systems. They may use documentation and their usual work tools, and they tell the reviewer which ones they used.
Walkthrough with the reviewer
The candidate explains each decision and answers questions. The reviewer changes one condition, such as a higher data volume or a failed call, and asks what would change.
Scoring against written criteria
The reviewer gives each criterion a level and a line of evidence. If the reviewer is unsure about a result, a second reviewer reads the evidence before we decide.
Decision and summary
Candidates who pass and agree to an introduction reach you with a written summary. Candidates who do not pass are not introduced.
Your interview comes next, and you decide who joins. How we work lists the checkpoints that every engagement keeps, whoever directs the work.
What the engagement model changes in an assessment
Name the model in your role brief before the assessment starts. The model changes who reads the summaries and who decides who joins. Staff augmentation versus project delivery compares the models themselves.
- Staff augmentation. You read each summary, interview each candidate and decide who joins, because the person works under your lead. Microsoft Dynamics 365 staff augmentation explains what happens after your decision.
Who reviews the work, and who answers for what
Each person in an assessment has a defined part and a defined limit.
| Person | Responsible for | Does not |
|---|---|---|
| Reviewer | Works in the same product track as the role. Runs the walkthrough, scores each criterion and writes the summary. | Review candidates for a product track they do not work in |
| Second reviewer | Reads the evidence when the first reviewer marks a result as uncertain, and agrees on the decision with the first reviewer | Lower the criteria to fill a role |
| Your MS Dynamics Guys contact | Agrees on the role brief with you, sends each summary and tells you when nobody passed | Score candidates or change a reviewer's result |
| Candidate | Completes the task, explains the work and agrees before a profile, summary or work sample reaches you | Get access to your systems, or any of your code and data except an exercise you shared, before you choose them |
| Your team | Reads the summary, runs your own interview and decides who joins | Have to accept anyone, because a passed assessment is not a decision |
The reviewer answers for an accurate summary. MS Dynamics Guys answers for applying the same criteria to every candidate. You answer for the final choice, because only your team can judge fit with your people and your system.
What you receive: a written summary for each candidate
Each candidate we introduce comes with a short written summary. It states what we tested, what we found and what we could not test. The table is an original demonstration of the format, written for this page. It is not a candidate's result.
| Part of the summary | What it records | How to use it |
|---|---|---|
| Role and product | The role brief, the product track and version, and whether the task used an online or on-premises setup | Check that the task matched your product before you rely on the result |
| Task and scenario | The task version, and how we adapted the scenario to your role brief | Compare the scenario with the work waiting in your backlog |
| Criteria and levels | Each criterion, the level reached and one line of evidence | Read the criteria your role depends on first, not the overall result |
| Strengths | What the candidate did well, such as a defect they found or a choice they explained clearly | Ask the candidate to apply the same reasoning to one of your own items |
| Gaps found | What was missing or weak, and how much it matters for your role | Ask about each gap in your interview, or plan support for it in the first weeks |
| Not tested | Requirements from your brief that the task did not cover | Cover them in your interview or in the first work package |
| Questions for your interview | A few questions from the reviewer, based on the gaps | Use them as they are, or rewrite them around your own system |
| Reviewer and date | The reviewer's role and product track, the date, and whether a second reviewer read it | Check that the date and the product version still match the work in your backlog |
With the candidate's consent, you can also see the work behind the summary.
For sample work, open the role pages linked in the task table. Each one lists the evidence its task produces and shows an original demonstration of that work. No demonstration comes from a client or a candidate.
Demonstration: how a reviewer scores one criterion
What an assessment cannot tell you
An assessment samples a person's work on a small, controlled problem. It lowers the risk of a poor match, but it cannot remove that risk. These limits apply to any provider's screening, including ours:
- Your environment. Our task does not run on your system, with your data volumes, installed apps, integrations and years of earlier changes. Only work in your environment tests that.
- Pace over weeks. A short task shows reasoning, not how much a person delivers in a sprint. Set acceptance criteria for the first weeks, and check the work against them.
- Fit with your team. How someone communicates in your meetings, tools and working hours shows over weeks, not in one walkthrough.
- Knowledge of your business. The scenario is invented, so it cannot test knowledge of your processes, your industry or the rules of your country.
- Prepared answers. A candidate who has seen a similar task may score higher than their everyday work suggests. Questions about your own system are harder to prepare for.
- Identity, references and vetting. A technical assessment is not a background check. If your organization needs identity checks, references or security vetting, list them in your role brief. We confirm in writing which of them we can provide.
For these reasons, MS Dynamics Guys treats the assessment as a filter before your interview, not as a replacement for it.
How to use the summary in your own interview
Spend your interview on what our task could not test. These five steps help:
- Read the gaps and the list of untested requirements first, and plan one question for each.
- Bring one real backlog item with sensitive data removed. Ask how the candidate would start, what they would check first and what they would ask your team.
- Ask the candidate to explain one decision from their assessment task. Then change a condition, and listen to how they adjust the answer.
- Invite the person who will review their work, such as a lead developer, an architect or a process owner. That person judges fit with your standards better than any summary.
- Write acceptance criteria for the first work package before the start date. A first item that your team accepts is stronger evidence than any assessment.
Each role page adds interview advice for that role:
- CRM developers: questions about plug-ins, errors on save and the release path.
- CRM consultants: mapping one of your own processes out loud with the person who owns it.
- Sales consultants: questions about forecast adjustments, lead routing, email tracking in Outlook and copied security roles.
- Business Central developers: questions about events, tests and Microsoft updates.
- Business Central consultants: explaining the entries of a posted document from your own company.
- Microsoft Dynamics 365 consultants: who should join your interview for a functional consultant, a technical consultant or an architect.
- Power Platform developers: a walkthrough of one of your own solutions, or part of the exercise repeated with your workflow.
- Power Apps developers: screenshots and formulas from one of your apps, with real data removed. Ask what the candidate would check first.
- Power Automate developers: a real failed run from your environment, with sensitive data removed.
Questions about our technical screening
Can you assess candidates with an exercise we provide?
Yes, with limits. Send the exercise with your role brief. First remove production data, personal data, credentials and anything you may not share with an outside candidate. We tell you whether it replaces our standard task or runs next to it, and the summary says which one was used. We use your exercise only for your role.
Do candidates see our systems or data during the assessment?
No. Candidates work outside your systems, on material that MS Dynamics Guys wrote or on an exercise you sent with sensitive data removed. They get access to your systems only after you choose them, the agreement is signed and your administrator creates named accounts for them.
What happens if a candidate does not pass, or nobody passes?
A candidate who does not pass is not introduced, and we do not send you their result. If nobody passes, we tell you which requirements were hardest to meet. You can then change the brief, for example the seniority, or split the work into two roles. We do not lower the criteria to fill a role.
Does a passed assessment cover other roles or product tracks?
No. A result applies only to the role and product track it was assessed for. A developer who passed the task for one product track completes the task for another track before we propose them for it. The summary names the track, so you can see what was tested.
Is a passed assessment the same as a Microsoft certification?
No. It is our own review for one role, not a Microsoft credential.
This site makes no certification claims about any person.
If your role needs a certification, list it in your role brief. A candidate can then share a link to their Microsoft Learn transcript. The transcript opens on Microsoft's own site and lists the certifications they have completed. Associate, expert and specialty certifications expire unless the holder renews them every year. Check that the one your role needs has not expired.
How long does an assessment result stay valid?
We set no fixed expiry date. A result describes the candidate on the assessment date, and the summary names the product version used. Ask for a fresh review if your role differs from the one assessed. Ask also if a Microsoft update has changed an area your role depends on.
Review your role requirements with us
Send the role, the product and version, and the skills that matter most. We reply with what our assessment would test and what it would leave to your interview.
Product documentation referenced on this page
- Use plug-ins to extend business processes Microsoft Learn, checked October 4, 2026
- Apply business logic in Microsoft Dataverse Microsoft Learn, checked October 4, 2026
- Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse Microsoft Learn, checked October 4, 2026
- Programming in AL Microsoft Learn, checked October 4, 2026
- Testing the application overview (Business Central) Microsoft Learn, checked October 4, 2026
- Extensibility home page for finance and operations apps Microsoft Learn, checked October 4, 2026
- X++ language reference Microsoft Learn, checked October 4, 2026
- View and share your Microsoft Learn transcript Microsoft Learn, checked October 4, 2026
- Renew your Microsoft Certification - FAQ Microsoft Learn, checked October 4, 2026