Why Microsoft Partners Subcontract D365 Work (and How to Do It Right)

Is subcontracting normal, and why is it usually invisible?

Most clients assume the partner they hired delivers every line of their Dynamics 365 implementation in-house. In reality, subcontracting is a standard, healthy part of the Microsoft partner ecosystem: partners flex capacity, pull in specialists and lean on trusted delivery partners to hit timelines. Doing it right comes down to clear agreements, explicit IP terms and a real technical screen. References test the firm, not the people who will be on your project, so set a short paid task in your own environment, ask Dataverse security, ALM and PCF questions that cannot be bluffed, and contract for named individuals, substitution consent, source in your repository from day one and defined handover artefacts.

The reason it stays invisible is that the prime partner remains accountable. Subcontracting is not handing off the relationship; it is extending the team behind it. The question for a partner is never really "should we ever subcontract" - almost everyone does - but "are we doing it in a way that protects our margin, our quality, and our client relationship." That is where the discipline matters.

Why do partners subcontract D365 work?

Bench gaps and capacity. Pipeline is lumpy. A partner can win three implementations in the same quarter and not have the consultants to staff all of them, then face a quiet stretch where a fully-loaded bench would bleed money. Subcontracting converts a fixed cost into a variable one - you bring in capacity when the work is there and release it when it is not, without turning away revenue or carrying idle salaries.

Specialized skills. Dynamics 365 is broad. A partner strong in Sales and Customer Service may have little depth in Field Service scheduling, PCF development, complex Power Platform integrations, or a specific industry's regulatory requirements. Rather than decline the work or fumble through a module they do not know well, partners bring in specialists who do it every day. The client gets genuine expertise; the partner protects its reputation by not pretending to skills it lacks.

Cost optimization. Blended delivery - keeping senior architecture and client-facing roles in-house while subcontracting build and configuration work - lets partners deliver competitively without compromising the parts of the engagement that most affect quality and the relationship. It is less about chasing the cheapest hands and more about putting the right cost structure behind each layer of the work.

How should you structure the subcontracting agreement?

Get the commercial frame right before anyone touches a keyboard. A few decisions carry most of the weight.

First, pick the engagement model deliberately: time-and-materials when scope is genuinely fluid, fixed-price when scope is well defined and you want predictability. Mismatching the model to the reality of the work is the single most common source of friction.

Second, define scope and acceptance criteria in writing. What is being delivered, what "done" means for each deliverable, and who signs off. Ambiguity here is what turns a smooth subcontract into a dispute.

Third, agree on communication and escalation. Who talks to whom, how often, and what happens when something slips. The strongest arrangements treat the subcontractor as an extension of the prime's team - shared standups, shared tooling, a shared backlog - rather than a black box that returns work at the deadline.

Fourth, be explicit about the white-label boundary. If the subcontractor is delivering under the prime's brand, spell out client-facing conduct: whose email domain, whose name on the documentation, what (if anything) the subcontractor may say to the end client directly.

What quality control actually protects the prime partner?

The prime partner's name is on the work, so quality cannot be left to trust. The arrangements that hold up build review into the process rather than inspecting at the end.

That means defined coding and configuration standards shared up front, code review and peer review as part of the workflow, and source control and a deployment pipeline the prime can see into. Regular demos at the end of each sprint or milestone catch drift early, when it is cheap to correct, instead of at a big-bang handover when it is not. A short, well-run discovery or pilot phase at the start is the cheapest insurance available: it tells you whether the subcontractor's quality and working style match your expectations before you commit the whole engagement.

Review in flight only works if the people you let in were worth letting in. The rest of this section is the screen we would apply to any Dynamics 365 or Power Platform subcontractor, including us: it takes days rather than months, and every step tests the individuals who will actually touch your client's environment.

Why do references not tell you whether a subcontractor is any good?

A reference call tests the firm. It tells you a client was happy with a project, delivered at some point in the past, by whichever consultants were on the bench that quarter. It says nothing reliable about the two or three people being proposed for your engagement, and in subcontracting those people are the whole product. Reference clients are also chosen by the supplier, and a satisfied end client may never have looked at the solution layers, the plugin code or the flows.

Use references for what they are good at - commercial reliability, communication, whether the firm stayed through a difficult phase - and use a technical screen for everything else. The screen has three parts: a paid task, an interview with the named people, and contract terms that keep those people on the project.

What should a short paid test task look like?

Set a small, real piece of work, pay for it, and run it in your own environment rather than theirs: a sandbox or developer environment in your tenant, your Azure DevOps or GitHub repository, your publisher. A task in their own environment shows you a polished result; a task in yours shows you how they work. Something like two or three new columns and a form change, a plugin with a real rule, a cloud flow calling an external endpoint, and a solution checked into your repository is enough. Then judge it on what was left behind, not only on whether the feature works:

• Solution layering: the work sits in an unmanaged solution under your publisher and prefix, contains only the components it changed rather than whole tables with every subcomponent, and nothing was customised in the Default Solution.
• Managed and unmanaged discipline: the solution is exported and imported as managed into the next environment, unmanaged never goes beyond dev, and the solution version was incremented rather than left alone.
• Plugin error handling: exceptions are not swallowed, business errors reach the user as a clear InvalidPluginExecutionException message, the tracing service is used, update steps have filtering attributes, images request only the columns needed, and the class holds no state between executions.
• Flow error handling: actions are grouped in scopes with run-after configured for failure and timeout, retries are deliberate, and the flow uses connection references and environment variables instead of personal connections and hard-coded URLs.
• Naming: schema names that describe the data, flow actions renamed from their defaults, one consistent prefix, and web resources and components that a stranger could find in six months.
• Tidiness: test records removed, temporary flows and components deleted, no personal connections left owning anything, and no unexplained security role changes.

The feature working is the minimum. The difference between a senior and a junior subcontractor is almost entirely in that list, and it is visible in an afternoon of review.

Which interview questions cannot be bluffed on Dataverse security, ALM and PCF?

Interview the named individuals, not the account manager, and ask questions whose answers come from having done the work. Listen for specifics, trade-offs and the things that went wrong, rather than definitions.

• Dataverse security: "A user can see an account in a view but gets an access error opening one of its contacts. Walk me through where you would look." A good answer moves through security role privilege depth, business unit and ownership, team membership, sharing, the relationship cascade behaviour and column security, in a sensible order.
• Dataverse security: "When would you use an owner team, an access team, a Microsoft Entra ID group team or hierarchy security, and what does heavy record sharing do over time?" Someone who has run a large security model will talk about the growth of shared-access records and why they avoid sharing as the main mechanism.
• ALM: "Production needs a hotfix while the next release is half built in dev. How do you ship it?" Listen for source control branching, a separate environment or patch built from the released version, and a pipeline import, never an edit in production.
• ALM: "You remove a column from a managed solution and import the new version. What happens under upgrade compared with update?" Upgrade removes components that are no longer in the solution; update leaves them in place. People who have done ALM in anger know this, because it has either saved them or bitten them.
• PCF: "Walk me through the lifecycle of a field control and what happens when the column is read-only or secured." Expect init, updateView, getOutputs, notifyOutputChanged and destroy, and handling of the disabled and masked states rather than assuming the user can always edit.
• PCF: "When would you build a virtual control on the platform React and Fluent libraries instead of bundling your own, and how do you make sure an updated control is actually picked up?" Expect a clear view on bundle size and platform libraries, and the answer that the manifest version has to be incremented.

A consultant who has done the work answers these in minutes and usually adds a war story. One who has not will answer in generalities, and a follow-up question exposes it quickly.

Which contract terms keep the people you vetted on the project?

The screen is wasted if a different person turns up in week three, so write the result of it into the contract rather than relying on goodwill. These terms are standard to ask for and a serious subcontractor will accept them:

• Named individuals: the statement of work lists the people you interviewed and the roles they fill.
• Substitution consent: nobody is replaced or added without your written consent, and you may interview any proposed replacement.
• Replacement terms: if a named person leaves or is removed, a replacement of equivalent seniority is proposed within an agreed period, the handover overlap is at the subcontractor's cost, and you may refuse the replacement.
• Source in your repository from day one: solutions are unpacked into your repository and every change arrives through your pipeline, so there is never a version of the work that only exists on the supplier's side.
• Defined handover artefacts: agree the list up front, for example the unpacked solution source, pipeline definitions, the list of environment variables and connection references, the data model and security role design, integration runbooks and a known issues list, and make final acceptance depend on it.
• Access on exit: named accounts, removed at the end of the engagement, with no shared credentials along the way.

If you are on the other side of this and looking for capacity, our Dynamics 365 subcontracting service covers the white-label model, and the staff augmentation and subcontracting page lists the questions we expect to be asked before anyone starts, together with how a small fixed-price work package can act as the paid test.

How do you protect IP, confidentiality, and the client relationship?

Three protections are non-negotiable and belong in the contract, not in good intentions.

Intellectual property assignment. Make clear that work product created by the subcontractor is assigned to the prime (or flows through to the client) so there is no ambiguity about who owns the deliverables. This should be unambiguous and in writing.

Confidentiality and data handling. The subcontractor will touch client data and systems. NDAs, defined access scopes, and clear data-handling rules protect the end client and the prime alike - and are increasingly a baseline expectation, not a nicety.

Non-solicitation and relationship protection. The prime owns the client relationship. A non-solicitation clause and clear rules about direct client contact keep it that way, so the subcontractor strengthens the relationship rather than threatening it. The right delivery partner sees protecting your relationship as part of the job, not an obstacle to work around.

That last point is really the whole test. A good subcontracting relationship is built on the subcontractor wanting the prime to look good and to win the next deal - because their work depends on it too. When incentives line up like that, subcontracting stops being a risk to manage and becomes leverage: more capacity, more skills, and more competitive delivery without the fixed cost.