Delivery model
How MS Dynamics Guys delivers Microsoft Dynamics 365 work
In short
MS Dynamics Guys runs every Microsoft Dynamics 365 engagement on one delivery model, whether it is a project, a support service or specialists in your team. This page sets out what we need before work starts, who owns which decisions, how environments and testing work, how work is accepted, and what you keep at the end. Each service page links here instead of repeating it.
What we ask for before work starts
Discovery is only as good as its inputs. We record any input that is missing as a risk instead of filling the gap with assumptions.
| Input | Why it matters | Usually provided by |
|---|---|---|
| The decisions the work must support | Keeps discovery focused on what you need to decide | Your sponsor |
| Process descriptions, reports and current workarounds | Shows how work really happens, including the exceptions | Process owners |
| Read access to current systems and a Microsoft Dynamics 365 sandbox | Lets us check facts instead of assuming them | Your IT owner |
| The list of connected systems, with owners and documentation | Integrations drive a large share of effort and risk | IT and system owners |
| Data samples and volumes | Volumes shape the design and the migration window | Data owners |
| Constraints: dates, budget range, compliance and security rules | Narrows the options before anyone designs | Your sponsor |
Who decides what
Clear ownership prevents most disputes before they start. The split below applies to every engagement unless the contract says otherwise.
You decide
Scope, priorities and acceptance
What is built and in what order, whether delivered work is accepted, when a release goes to production, and who owns the code after handover.
We deliver
Design, build and evidence
Designs, configuration, code, reviews, automated tests, defect fixes and the documentation that lets someone else continue.
Agreed together
Rules of the engagement
The definition of done, the release calendar, change control and the rhythm of status updates and demonstrations.
Environments and the release path
Changes move through environments in one direction. Nothing is built directly in production.
- Development: where changes are built. For Dataverse apps this holds unmanaged solutions; for Business Central it is a sandbox environment.
- Test: reviewed changes are deployed exactly as they will reach production: managed solutions for Dataverse, app packages for Business Central.
- User acceptance: your users test with realistic data. On smaller engagements this can be the test environment.
- Production: changes arrive only through an approved release, with a record of what changed.
Microsoft recommends deploying managed solutions to every environment other than development, and we follow that rule for Dataverse work. Where your tools allow, the moves are automated with Pipelines in Power Platform, Azure DevOps or GitHub Actions.
Emergency fixes follow the same path at higher speed. If a fix has to be made directly in production, it is recorded and brought back into source control before the next release.
How quality is checked
Design review
Designs are reviewed before build starts, when a mistake costs a conversation instead of a rewrite.
Code review
A second engineer reviews every change before it reaches a shared environment.
Automated tests
Business logic carries tests that run on every build where the platform supports them.
System and integration tests
Complete processes are tested across systems, including failures such as a rejected transfer.
Regression checks before release
The tests that protect existing processes run again before each release.
Defect tracking
Every defect has an owner, a severity and a retest record.
How work is accepted
Acceptance criteria are agreed before build starts and written in business terms: what a user does and what must happen next.
Your users test against those criteria in the acceptance environment. Defects are classed by severity, fixed and retested. Work counts as done when your tester signs it off, not when a developer finishes it.
Sign-off records any open items you chose to accept, with an owner and a date for each.
What you keep at the end
- Source code and its full history in your repository
- Deployable packages for every release
- Designs and decisions, with the reasons recorded
- Configuration and integration documentation
- Test scenarios and the automated tests
- Operating notes: monitoring, recovery from failed jobs, contacts
Ownership terms for the code are set in the contract before work starts. The documentation is written so that your team, or another partner, can continue without us.
Ways of working on the same delivery model
| Model | Who directs daily work | Who is accountable for the result | Suits |
|---|---|---|---|
| Specialists in your team (staff augmentation) | Your team lead | Your team, with MS Dynamics Guys accountable for the specialist's skills and conduct | A team that already delivers and needs capacity |
| Scoped project | MS Dynamics Guys, within the agreed scope | MS Dynamics Guys, for the agreed deliverables | Defined builds, integrations and implementations |
| Support service for a live system | MS Dynamics Guys, against priorities you set | MS Dynamics Guys, for the agreed service and backlog | Live systems that keep changing |
Specialists who join your team follow your direction and your tools. When a specialist leaves an engagement, knowledge transfer is documented and handed over. See hiring Microsoft Dynamics 365 specialists for how specialists are introduced.
Technical screening before a specialist joins
When an engagement adds people to your team, the checks start before you meet anyone. Each candidate completes a technical evaluation for the role. For a developer, that can be a code review exercise in C# for Dataverse, or in AL, the Business Central programming language. You then interview the candidate and decide who joins.
How we assess Microsoft Dynamics 365 specialists describes the task for each role, who reviews it and what a test cannot show.
Communication and change control
Each engagement has a named contact on each side and an agreed rhythm of status updates and demonstrations. Decisions, risks and open questions live in a shared log that both sides can read.
Changes to scope are written down with their effect on cost and dates before anyone acts on them. You approve, defer or reject each one.
Questions about how we work
Do you follow our delivery method or your own?
Yours, if you have one that works. Otherwise we propose ours. Either way, the checkpoints on this page must exist: agreed inputs, reviewed changes, tested releases and recorded sign-off.
Can we use our own repository, work tracker and pipelines?
Yes, and we prefer it. Work kept in your own systems stays usable by your team and by any future partner.
Who has access to production?
You decide. We ask for the least access the work needs, release through the agreed path, and log any emergency change so it can be reviewed.
How are changes handled during a scoped project?
Each change request states its effect on scope, cost and dates. You approve, defer or reject it before work starts on it.
What happens if we end an engagement early?
You keep everything delivered so far: the code in your repository, the packages and the documentation written to date. We hand over the open work so another team can pick it up.
Start a Microsoft Dynamics 365 engagement on clear terms
Share what you need to decide, the systems involved and your timing. We reply with the inputs we would need and a proposed first step.
Product documentation referenced on this page
- Solution concepts for application lifecycle management Microsoft Learn, checked October 2, 2026
- Pipelines in Power Platform Microsoft Learn, checked October 2, 2026