---
title: "Microsoft Dynamics 365 Contractor Onboarding Checklist"
canonical_url: https://msdynamicsguys.com/resources/dynamics-365-contractor-onboarding-checklist/
description: "A checklist for onboarding an external Microsoft Dynamics 365 specialist: named owners, environment access, repository rules, first task, acceptance and exit."
publisher: "MS Dynamics Guys"
last_modified: 2026-10-11
---

# Onboard an external Microsoft Dynamics 365 specialist

> **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.

_Updated October 11, 2026_

**At a glance**

- **Before day one:** Named owners, a named account, a decision on data, branch rules and a first backlog item
- **First week:** One real item, reviewed by a second person and accepted by your lead
- **Last day:** Handover first, then new owners for automations and records, closed accounts and rotated secrets
- **Not covered:** Worker status, pay, right to work and tax

[Plan onboarding](https://msdynamicsguys.com/contact/#intent=hiring&service=R11) · [Compare engagement models](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-project-delivery/)

## 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](https://msdynamicsguys.com/hire/dynamics-365-finance-operations-developers/) describes the development environment that role needs.

> **A services agreement, not employment advice**
>
> This guide covers onboarding under a services agreement between two companies. Worker status, pay, right to work and tax stay with the supplier and your legal counsel. The guide does not answer those questions, and it is not legal advice.
>
> Your organization may have its own rules for external workers, such as vetting or limits on certain data. Add them to the security review in the checklist below.

## 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](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/project-governance-project-organization) 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](https://msdynamicsguys.com/how-we-work/technical-screening/). It does not measure speed. A good first task has five features:

1. It is a real item from your backlog, small enough for your reviewer to read in one sitting.
2. Its acceptance criteria are written before the specialist starts.
3. 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.
4. It needs no production data and no access beyond the day-one account.
5. 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](https://msdynamicsguys.com/hire/dynamics-365-crm-developers/): a plug-in change with unit tests, added to your solution.
- [CRM consultants](https://msdynamicsguys.com/hire/dynamics-365-crm-consultants/): complaint handling in Microsoft Dynamics 365 Customer Service.
- [Sales consultants](https://msdynamicsguys.com/hire/dynamics-365-sales-consultants/): a second sales process and a regional forecast in Microsoft Dynamics 365 Sales.
- [Business Central developers](https://msdynamicsguys.com/hire/business-central-developers/): an extension inventory and one fix before a major update.
- [Business Central consultants](https://msdynamicsguys.com/hire/business-central-consultants/): a month-end inventory reconciliation.
- [Power Platform developers](https://msdynamicsguys.com/hire/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](https://msdynamicsguys.com/hire/power-apps-developers/): faster search and loading in a growing canvas app.
- [Power Automate developers](https://msdynamicsguys.com/hire/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](https://msdynamicsguys.com/hire/business-central-developers/#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](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/#access) 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](https://msdynamicsguys.com/services/dynamics-365-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](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-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](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/) covers what this checklist leaves out: line management, time records, capacity reports and changes of person. [How we assess specialists](https://msdynamicsguys.com/how-we-work/technical-screening/) 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.

## Engagement models, roles and related guides

- [Staff augmentation](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/): The offer behind this checklist: who directs the work, what MS Dynamics Guys handles as the supplier, time records and changes of person.
- [Staff augmentation vs project delivery](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-project-delivery/): Choose between staff augmentation, a dedicated team and an outsourced work package before you plan onboarding.
- [Technical screening](https://msdynamicsguys.com/how-we-work/technical-screening/): The assessment each candidate passes, and what only your interview and the first task can show.
- [Hire experts](https://msdynamicsguys.com/hire/): If you have not chosen the role yet: the developer and consultant roles for each product, and what each role brief needs.
- [How we work](https://msdynamicsguys.com/how-we-work/): The environments, reviews and handover deliverables that MS Dynamics Guys keeps in every engagement model.
- [Microsoft Dynamics 365 support](https://msdynamicsguys.com/services/dynamics-365-support/): When the work after the engagement suits an ongoing support service better than a person in your team.
- [Cost to hire developers](https://msdynamicsguys.com/resources/cost-to-hire-dynamics-365-developers/): What drives the cost of hiring Microsoft Dynamics 365 developers, including management and onboarding.
- [Hiring scorecard](https://msdynamicsguys.com/resources/dynamics-365-hiring-scorecard/): The step before this checklist: compare proposed specialists and their suppliers on the same evidence.

## 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.

[Plan onboarding](https://msdynamicsguys.com/contact/#intent=hiring&service=R11) · [Compare engagement models](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-project-delivery/)

## Product documentation referenced on this page

- [Organize your Microsoft Dynamics 365 project team](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/project-governance-project-organization) (checked 2026-10-04)
- [Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse](https://learn.microsoft.com/en-us/power-platform/admin/manage-apps) (checked 2026-10-04)
- [Invite users with Microsoft Entra B2B collaboration](https://learn.microsoft.com/en-us/power-platform/admin/invite-users-azure-active-directory-b2b-collaboration) (checked 2026-10-04)
- [Configure external collaboration settings (Microsoft Entra External ID)](https://learn.microsoft.com/en-us/entra/external-id/external-collaboration-settings-configure) (checked 2026-10-04)
- [Create users (Power Platform admin)](https://learn.microsoft.com/en-us/power-platform/admin/create-users) (checked 2026-10-04)
- [Control user access to environments with security groups and licenses](https://learn.microsoft.com/en-us/power-platform/admin/control-user-access) (checked 2026-10-04)
- [Copy an environment (Power Platform)](https://learn.microsoft.com/en-us/power-platform/admin/copy-environment) (checked 2026-10-04)
- [Role-based security roles for Dataverse](https://learn.microsoft.com/en-us/power-platform/admin/database-security) (checked 2026-10-04)
- [Environment strategy for Power Platform adoption](https://learn.microsoft.com/en-us/power-platform/guidance/adoption/environment-strategy) (checked 2026-10-02)
- [Power Apps Developer Plan](https://learn.microsoft.com/en-us/power-platform/developer/plan) (checked 2026-10-04)
- [Application lifecycle management (ALM) with Microsoft Power Platform](https://learn.microsoft.com/en-us/power-platform/alm/overview-alm) (checked 2026-10-04)
- [Power Automate licensing FAQ](https://learn.microsoft.com/en-us/power-platform/admin/power-automate-licensing/faqs) (checked 2026-10-04)
- [Create users according to licenses (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-how-users-permissions) (checked 2026-10-04)
- [Manage access to environments (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/tenant-admin-center-manage-access) (checked 2026-10-04)
- [Administration of Business Central online](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/tenant-administration) (checked 2026-10-04)
- [Delegated admin access to Business Central online](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/delegated-admin) (checked 2026-10-04)
- [Schedule jobs to run automatically (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/admin-job-queues-schedule-tasks) (checked 2026-10-04)
- [Testing the application overview (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-testing-application) (checked 2026-10-04)
- [Copy an environment (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/tenant-admin-center-environments-copy) (checked 2026-10-04)
- [Production and sandbox environments (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/environment-types) (checked 2026-10-04)
- [Job queue (Business Central developer content)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-job-queue) (checked 2026-10-04)
- [Set and manage branch policies (Azure Repos)](https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies) (checked 2026-10-04)
- [Solution concepts with Power Platform](https://learn.microsoft.com/en-us/power-platform/alm/solution-concepts-alm) (checked 2026-10-04)
- [App.json and other JSON files (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-json-files) (checked 2026-10-04)
- [Resource exposure policy setting (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-security-settings-and-ip-protection) (checked 2026-10-02)
- [Environment variables overview](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables) (checked 2026-10-02)
- [Manage application users in the Power Platform admin center](https://learn.microsoft.com/en-us/power-platform/admin/manage-application-users) (checked 2026-10-04)
- [Service-to-service authentication for Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/automation-apis-using-s2s-authentication) (checked 2026-10-02)
- [Authentication strength for external users (Conditional Access)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-guests-mfa-strength) (checked 2026-10-04)
- [Conditional Access: network assignments (Microsoft Entra ID)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-assignment-network) (checked 2026-10-04)
- [Programming in AL](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-programming-in-al) (checked 2026-10-02)
- [Change the owner of a cloud flow](https://learn.microsoft.com/en-us/power-automate/change-cloud-flow-owner) (checked 2026-10-04)
- [Share a cloud flow](https://learn.microsoft.com/en-us/power-automate/create-team-flows) (checked 2026-10-04)
- [Use a connection reference in a solution](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-connection-reference) (checked 2026-10-04)
- [Delete users from an environment (Power Platform)](https://learn.microsoft.com/en-us/power-platform/admin/delete-users) (checked 2026-10-04)