Buyer guide

Onboard an external Microsoft Dynamics 365 specialist

By MS Dynamics Guys · Updated October 11, 2026

Short answer

Onboard an external Microsoft Dynamics 365 specialist by naming an owner for each step before day one: access, environments, repository rules and a first task with acceptance criteria. This MS Dynamics Guys checklist gives every item an owner and evidence of completion, through access removal at exit. It covers onboarding under a services agreement, not employment, tax or immigration questions.

Plan onboarding Compare engagement models

Who this checklist is for

This guide is for the team that will work with an external Microsoft Dynamics 365 specialist. You have chosen the person. Another company supplies them under a services agreement, and your lead will direct their work. Some teams call such a person a contractor. On this page, the word means only that: a specialist supplied by another company.

Onboarding stalls when nobody owns a step. The account request waits in a queue, the first task has no acceptance criteria, or access stays open after the last day. The checklist below gives each step an owner and a piece of evidence that shows the step is done.

The product steps on this page cover these apps:

Customer relationship management (CRM) apps that run on Microsoft Dataverse, such as Microsoft Dynamics 365 Sales and Microsoft Dynamics 365 Customer Service.
Microsoft Dynamics 365 Business Central online.
Power Apps and Power Automate, in environments that have a Dataverse database.

The owners, the checklist and the exit steps also fit Microsoft Dynamics 365 Finance and Supply Chain Management. This guide does not describe the access steps for those apps.

The page on hiring finance and operations developers describes the development environment that role needs.

Name the owners before the first day

Each owner decides one part of the onboarding and prepares it before the start. In a small team, one person can hold several of these roles.

Onboarding owners: what each one decides and what each one prepares before day one
Owner	Decides	Prepares before day one
Sponsor	Why the role exists, the budget and when the engagement should end	Signs the services agreement and confirms the role brief
Delivery lead	The order of the backlog, daily priorities and when work counts as done	Writes the first backlog item with acceptance criteria and drafts the working agreement
Technical reviewer	Whether a change meets your standards before it merges	Sets the branch rules and agrees how quickly reviews happen
Release approver	Whether and when a reviewed change goes to production	Confirms the release path and who may deploy to production
Tenant administrator	Which accounts, roles and environments the specialist receives	Creates the named account, assigns the roles and prepares the development environment with the environment administrators
Security contact	Which data the specialist may see, the sign-in rules and what gets logged	Records the security review, including each accepted risk and the person who accepted it
Process owner	How the business process must work, and whether a result fits it	Answers process questions and tests results in their own area
Supplier contact	Matters on the supplier's side: the contract, absences and any change of person	Sends the details your administrator needs for the account and confirms the agreed hours with your delivery lead

Keep three roles away from the specialist: the technical reviewer, the release approver and the tenant administrator. A person who approves their own changes, releases their own work or grants their own access removes your second check. This rule says nothing about the person. Separation of duties applies to everyone who can change your system.

Microsoft's guidance on organizing a Microsoft Dynamics 365 project team covers short assignments too. Each team member needs well-defined responsibilities and boundaries, even someone assigned part-time or for one short task.

The checklist: item, owner and evidence of done

Work through the rows in order. A row is done when its evidence exists, not when someone reports it as done.

Onboarding checklist for an external Microsoft Dynamics 365 specialist: when, item, owner and evidence of done
When	Item	Owner	Evidence of done
Before the start	A signed services agreement and named contacts on both sides	Sponsor and supplier contact	The signed agreement is on file, and no account exists before the signature date
Before the start	A named account with multifactor authentication (MFA) and only the roles the work needs	Tenant administrator	The specialist signed in once, from their usual work location, to a non-production environment, and the delivery lead approved the list of roles
Before the start	Only the data the role needs	Tenant administrator	A development environment without business records, or a written approval that names the data
Before the start	A security review: data exposure, devices, sign-in rules and logging	Security contact	A dated review note that names each accepted risk and its owner
Before the start	A written working agreement: hours, channels, review times, holidays, time records and escalation	Delivery lead and supplier contact	Both sides confirmed the same version
Before the start	The first backlog item, with acceptance criteria	Delivery lead	The item sits in your work tracker, assigned to the specialist
Day one	Repository access with required branch policies	Technical reviewer	A test pull request (a change proposed for review) cannot be completed without an approval
Day one	Production release rights	Release approver	Only your release step deploys to production, and the specialist cannot approve a release
Day one	A walkthrough of the system, the backlog, the release path and the definition of done: the checks each item must pass	Delivery lead	Questions from the walkthrough are logged, each with an owner
First week	The first item, finished and reviewed	Delivery lead	Accepted against the definition of done after a second person reviewed it
First week	An access check against real work	Tenant administrator and technical reviewer	Roles that the first item did not use are removed, or kept with a written reason
During the engagement	Each new access request	Tenant administrator	A request with a reason, an approver and an end date
Last day	The exit steps below, in their order: handover, new owners for automations and records, closed accounts, rotated secrets and the supplier statement	Delivery lead and tenant administrator	The handover note, disabled accounts, a named owner for each automation and record, a rotation record and the signed supplier statement

Copy the table into your own planning document. Rename the owners to match your organization, and add the rows your own policies require, such as a background check. Skip the rows that do not apply to the role, for example the repository row for a consultant who changes only configuration.

MS Dynamics Guys wrote this checklist for this guide, from the Microsoft documentation listed at the end of the page. It describes no client engagement. The date at the top of the page shows when the checklist last changed.

Accounts and development environments by product

Decide the account type and the development environment before you ask the supplier for the specialist's details. Each product has its own rules.

CRM apps on Dataverse

Guest or own account. A guest is invited through Microsoft Entra B2B (business-to-business) collaboration and signs in with their own company's credentials. The alternative is an account that your administrator creates in your tenant. Check the limits for guests below before you choose.
License, role and group. The account needs two things from your tenant: a license and a security role for the work. Without both, it opens no app, and a license from the guest's home tenant does not count. Add the account to the security group of each environment the role needs, and to no other. A Power Platform Administrator or a Global Administrator can sign in without being in that group, so give the specialist neither role.
Development copy. Ask your environment administrator for a sandbox copied at the level Customizations and schemas only. It holds your customizations and schema, without business records such as accounts, contacts and cases. Because the copy is a sandbox, your administrator can give it its own security group. After the copy, the sandbox is in administration mode, and background operations such as workflows are off. Only System Administrators can sign in until your administrator turns administration mode off.
Limits for guests. Guests cannot use Microsoft Dynamics 365 Customer Voice; Microsoft says to create a user in your tenant for that work. In the Microsoft Dynamics 365 App for Outlook, a guest cannot use their own company's email address for email work in your environment. If the role needs either, plan an account in your tenant.

Power Apps and Power Automate

Maker roles. A maker who creates or changes tables needs the System Customizer role as well as Environment Maker. Environment Maker alone gives no access to the environment's data.
Guests who build apps. Microsoft's steps for guest makers set guest access in your Microsoft Entra external collaboration settings to the most inclusive level. That level gives guests the same access to your directory data as members. Your administrator also allows guests to make apps and gives each guest maker the Environment Maker role. When those apps work with Dataverse data or belong to a solution, your tenant must also license the guest with Dataverse use rights. If your security contact does not accept the wider guest access, create an account in your tenant for the maker.
Development environment. Give the specialist an environment for development, not your default environment. Microsoft Dynamics 365 apps cannot be installed in developer environments. Work on those apps therefore needs a sandbox that was created with Microsoft Dynamics 365 apps enabled.
Solutions from the first day. Build apps and flows inside a solution, so that they move to test and production through your release path.
Flow ownership. Decide before the first flow which account will own production flows. When a flow's owner leaves your organization, the flow is turned off after 14 days unless someone acts.

Business Central online

Named user. Your administrator creates the user in the Microsoft 365 admin center, where the Business Central license is assigned. The new user starts with the permission sets that your license configuration assigns, not with an empty list. Remove the sets the work does not need, and record the rest. The access check in the first week compares that list with the real work.
Sign-in per environment. Assign a Microsoft Entra group to each environment, and add your own users to each group before you assign it. Only group members and your administrators can then sign in. Put the specialist only in the groups of the sandboxes the work needs, so that production stays closed to them. Administrators are not limited by these groups, so keep administrator roles away from the specialist.
Delegated access is for partner administration. A Microsoft partner that administers your tenant reaches Business Central through granular delegated admin privileges (GDAP), which your Global Administrator accepts. Microsoft recommends a Business Central administrator role for that access. A specialist who works under your lead therefore gets a named user, so the separation of duties above still holds. Delegated users appear under a pseudonym with the partner's company name. They can create job queue entries and test one run in the foreground, but they cannot run scheduled jobs. By default, each environment admits every partner that has access to your tenant. Your Global Administrator can block partner access, or allow only named partners, for each environment.
Development sandbox. Develop in a sandbox environment. Automated tests cannot run in online production, and online sandboxes allow only limited test runs, so large test suites run in a container-based environment. A sandbox copied from production contains your production data. In such a copy, job queue tasks stop, webhooks are disabled, and extensions cannot call outside services until you allow it for each extension.
Scheduled jobs. A job queue entry runs as the user who set it to Ready. Keep a list of the entries that the specialist sets to Ready, because they depend on that account.

Repository rules to set before the first change

Code and solution files belong in your repository from the first commit. These rules make sure that a second person sees every change before it merges.

Contributor rights without bypass. The specialist can create branches and pull requests. Do not grant the permissions that bypass branch policies, either when pushing or when completing pull requests.
Required reviewers. In Azure Repos, the Git service of Azure DevOps, a required branch policy blocks direct pushes to the branch. Changes then arrive only through pull requests. Set a minimum number of reviewers, and leave Allow requestors to approve their own changes off.
No approval by the last pusher. For stricter separation of duties, also select Prohibit the most recent pusher from approving their own changes.
Build validation. Add a required build validation policy with an automatic trigger. Each pull request then starts a build, and a failed build blocks completion.
Your solution publisher. Before the first change, set up your own publisher and a solution for the work. In the first change, check that every new table and column carries your prefix. Dataverse adds the prefix to these names, and the names cannot change later.
Your publisher in Business Central. Write your own publisher name into each extension's app.json file before the first build, and check it in the first pull request. A later change makes every extension that depends on it recompile.
Readable source in Business Central. A per-tenant extension is built for your tenant only. In the first pull request, check the resource exposure policy of each one you own. It should allow debugging and include the source in symbol files. Microsoft recommends both for extensions whose code you own.
Secrets outside the code. Keys and passwords stay out of the repository. Your administrator stores them and records who can read them, so that the exit step shows what to rotate.
Secret values in Power Platform. Use environment variables of the secret type. They read their values from Azure Key Vault.
Dataverse integrations. Unattended integrations sign in as an application user. Your administrator creates it for a Microsoft Entra app registration and gives it its own security roles.
Business Central integrations. Unattended integrations use service-to-service authentication with a Microsoft Entra application, not the account of a person.

Microsoft documents the branch settings above for Azure Repos. If your code lives in another Git service, set the matching rules there before the first day.

A consultant who changes only configuration may not need repository access. A second person still approves each configuration change before it reaches production.

In apps on Dataverse, the consultant configures inside your solution in a development environment, so the change reaches test and production through your release path.

Write down the working agreement and the security review

Agree these points in writing before the first day. Rates, notice and replacement belong in the services agreement and are agreed per engagement. This table covers how the daily work runs.

Working agreement and security review: each topic, what to record and who confirms it
Topic	What to record	Who confirms it
Working hours	The hours the specialist works, the hours shared with your team, and how each side announces holidays	Delivery lead and supplier contact
Channels	Where questions go, where decisions are recorded, and which channel is for urgent problems	Delivery lead
Review turnaround	How soon a reviewer looks at a change, and who stands in when the reviewer is away	Technical reviewer
Time records	Where the specialist records time, who approves it and for which period	Delivery lead
Escalation	Whom to contact when work is blocked, when a security event happens and when the arrangement itself has a problem	Sponsor and supplier contact
Data exposure	Which environments and data the specialist may see, on which devices, and whether any data may leave your tenant	Security contact
Sign-in strength	MFA for the account. For guests, a Conditional Access policy can require an authentication strength. Decide whether you accept MFA completed in the guest's home tenant.	Security contact and tenant administrator
Sign-in location	The countries and networks the specialist signs in from. Check whether a Conditional Access policy would block them, such as a rule against sign-ins from countries where you have no operations.	Security contact and tenant administrator
Logging	What your team logs about the specialist's account, such as sign-ins and role changes, and who reads the log	Security contact

Microsoft's steps for the authentication strength policy start in report-only mode, with your emergency access accounts excluded. Turn the policy on after you have checked its effect. Authentication strength currently works only for guests who sign in with Microsoft Entra ID accounts. Other guests sign in another way, for example with a one-time passcode sent by email. For them, use the Require multifactor authentication grant control instead.

Choose a first task that tests the whole path

The first task tests your setup: the account, the review rules and the release path. It also gives the first evidence from your own environment, which an assessment cannot test. It does not measure speed. A good first task has five features:

It is a real item from your backlog, small enough for your reviewer to read in one sitting.
Its acceptance criteria are written before the specialist starts.
It travels your full path once. For code, that means a branch, a pull request, a review, a build and your release step into a test environment. For configuration, it means building the change in a development environment and showing it in a test environment. Your change process then approves it.
It needs no production data and no access beyond the day-one account.
It ends with something your lead can accept or send back, such as a reviewed change and its test results.

If the first task needed more access, find the reason before the second task. Either the list of roles was wrong, or the task was bigger than planned.

These role pages show an example first work package for their role:

CRM developers: a plug-in change with unit tests, added to your solution.
CRM consultants: complaint handling in Microsoft Dynamics 365 Customer Service.
Sales consultants: a second sales process and a regional forecast in Microsoft Dynamics 365 Sales.
Business Central developers: an extension inventory and one fix before a major update.
Business Central consultants: a month-end inventory reconciliation.
Power Platform developers: a cost center approval that changes a table, a flow, the app and a security role, shipped in one managed solution.
Power Apps developers: faster search and loading in a growing canvas app.
Power Automate developers: one approval flow made stable, under an owner your team names.

Example first task for a Business Central developer

Illustrative example: not a client case and not a delivery-time promise

We invented this scenario to show the size and shape of a first task. It describes no client, and it sets no timeline.

The task is deliberately close in size to the exercise in the Business Central developer assessment. What is new is the path: your repository, your branch rules, your pipeline and your sandbox. If the task stalls, check the setup before you judge the work.

A wholesaler runs Business Central online. Its webshop sends orders with a webshop customer reference. Today, staff copy that reference into customer notes by hand.

The task

Add a field for the webshop customer reference to the customer table through a table extension. Show it on the customer card through a page extension.
Validate the field: the extension rejects a reference that another customer already uses, with a clear message.
Write a test codeunit in AL, the programming language of Business Central. One test saves a unique reference, and a second test proves that a duplicate is rejected.

Artifacts

A pull request linked to the backlog item.
Test results from a sandbox or a container-based environment.
A short deployment note: the extension version, the steps and any setup.
Open questions, for example whether older references in the notes should move to the new field.

Acceptance criteria

A second person reviewed and approved the pull request.
Both new tests pass, and the existing tests still pass.
Your release step deployed the extension to the test environment. Nobody installed it by hand.
The specialist needed no access beyond the day-one account.
Your lead accepted the item against the definition of done.

Exit: hand over, move, remove and confirm

Work from the top row down. The handover needs the specialist's access, so it comes first. Secrets are rotated after the accounts are closed.

Keep a running list from the first day: every account, automation, scheduled job and secret that the specialist creates or uses. On the last day, that list turns the exit into a check instead of a search.

Exit steps for an external specialist: what to do and the evidence that each step is done
Step	What to do	Evidence
Handover	The specialist writes a handover note on open work, design decisions, known risks and how to build and deploy. Then they walk a named person on your side through it.	The note is in your workspace, and that person confirmed the walkthrough
Branches and open work	Merge or close the specialist's branches and pull requests. Give each open backlog item to a named person.	No branch, pull request or backlog item is left with the specialist
Cloud flow owners	Change the owner of each solution-aware flow that the specialist owns, to a named person or to a service principal application user. A flow outside a solution cannot change owner in place, so add it to a solution first. The previous owner stays on as a co-owner, so remove the specialist afterward. Scheduled and automated flows run under the new owner's license, so check that license. A service principal holds no license, so plan how its flows are licensed.	Each flow has a new owner, and the specialist is in no owner list
Flow connections	Replace each connection that signs in as the specialist with a connection that your side owns. In a solution, one edit to a connection reference moves every flow that uses it. Share the new connections with any service principal that owns a flow. Steps that still use the specialist's connections might fail once the account is closed.	No flow uses a connection of the specialist
Records in Dataverse	Take the account out of each environment's security group. In an environment without a group, the tenant account step below disables the user. Dataverse keeps the disabled user record, together with the records it owns. Reassign those records to a named person. Microsoft requires this before a user can be deleted permanently.	The user shows as disabled and owns no records
Job queue entries	In Business Central, find the entries that the specialist set to Ready. A licensed user on your side sets each one to Ready again, so that it runs as that user.	A named user on your side set each entry to Ready again
Business Central user	Open the User Card in each environment where the specialist worked, sandboxes included, and set Status to Disabled. The user can no longer sign in, and the history that refers to the user stays. A user who has signed in cannot be deleted. For a delegated administrator, disable that user or block partner access to the environment.	The status is Disabled in every environment the specialist used, and the partner access setting is checked
Tenant account, licenses and admin roles	Block sign-in for the specialist's account in Microsoft Entra ID, or delete the account. Remove its licenses and every admin role it holds. An administrator keeps access outside an environment's security group and without a license, so the role must go too. The access table on the staff augmentation page lists these rules for each product.	Sign-in is blocked or the account is deleted, and it holds no license and no admin role
Other accounts	Remove the specialist from the repository, the work tracker, team chat and any test accounts they used.	Each account is removed or disabled
Secrets and keys	Rotate every secret, key and password that the specialist could read, including integration keys and shared test passwords.	A rotation record with dates and owners
Supplier statement	Ask the supplier for a written statement that the specialist keeps no copy of your data and no credential.	The signed statement is on file

How the checklist changes with the engagement model

The same checklist works for each model. What changes is who directs the work and which rows your side runs.

Which parts of the onboarding checklist apply in each engagement model, and what changes
Engagement model	Which parts apply	What changes
Staff augmentation: specialists in your team	Every row	Your lead directs the daily work, so your side owns every row except those of the supplier contact.

If you have not chosen the model yet, start with staff augmentation versus project delivery.

How does onboarding work when the specialist comes from MS Dynamics Guys?

The checklist on this page applies unchanged. MS Dynamics Guys holds the supplier contact rows, and your side holds every other row. Before the start date, we agree the rows with your lead.

Before the start. You interview the candidate and decide who joins. After both companies sign the agreement, we send the details your administrator needs for the named account.
During the engagement. The specialist works in your tenant, in your repository and from your backlog, under your lead. Nothing reaches production except through your release step.
On the last day. The specialist writes the handover note and walks your named person through it. We then state in writing that the specialist holds none of your data and none of your credentials.

Allocation, working hours, notice, any minimum term, replacement and the rate basis are agreed in writing for each engagement. This guide states no values for them.

Staff augmentation with MS Dynamics Guys covers what this checklist leaves out: line management, time records, capacity reports and changes of person. How we assess specialists describes the review that each candidate passes before your interview.

Questions about onboarding an external specialist

What should we prepare before an external Microsoft Dynamics 365 specialist starts?

Start with the owners: at least a delivery lead, a technical reviewer, a release approver, a tenant administrator and a security contact. Then prepare five things. You need a signed agreement and a named account with only the roles the work needs. You also need a decision on the data the specialist may see, branch rules in your repository and one backlog item with acceptance criteria. The checklist on this page gives each item an owner and its evidence.

Should the specialist get a guest account?

In Dataverse environments, a guest account is possible. The guest signs in with the credentials of their own company, and your tenant assigns the license and the security role. Choose an account in your tenant instead if the role uses Microsoft Dynamics 365 Customer Voice. The same applies to email work in the Microsoft Dynamics 365 App for Outlook.

A guest who builds apps in Power Apps needs a wider setup. Microsoft's steps for guest makers give every guest in your tenant the same access to directory data as members. If your security contact does not accept that, create an account in your tenant for the maker.

In Business Central online, plan an account that your administrator creates in your tenant. Microsoft's steps for Business Central users start in the Microsoft 365 admin center, where the account gets its Business Central license.

Your sign-in rules apply to every such account, and your administrator closes it at exit.

Can the specialist work without our production data?

Start without it, and add data only when a task needs it.

In Dataverse, a sandbox copied at the level Customizations and schemas only gives the specialist your customizations without business records such as accounts and contacts.

In Business Central, a sandbox copied from production holds your production data. If the role does not need that data, ask your administrator for a sandbox that is not a copy of production.

Some tasks do need real records, such as a trial data migration or a defect that appears only with certain data. Record who approved the access, which data the specialist may see and when the access ends.

What must happen on the last day?

The handover comes first, while the specialist still has access. Then your administrator moves automations, records and scheduled jobs to owners you control. Next, your administrator closes the accounts in each environment and in Microsoft Entra ID and removes any admin role. After that, your administrator rotates the secrets the specialist could read. Finally, the supplier confirms in writing that the specialist has kept none of your data and no credentials. The exit table on this page lists each step with its evidence.

Is this guide employment or legal advice?

No. It describes how an external specialist gets access, works and leaves under a services agreement between two companies. Questions about worker status, pay, right to work and tax go to the supplier and to your legal counsel. If your organization has rules for external workers, such as vetting, ask your counsel how they apply and add them to the security review.

Plan onboarding for an external specialist

Tell us the product, the role and who will direct the work. We reply with questions and with the rows of this checklist that your side would own.