> ## Documentation Index
> Fetch the complete documentation index at: https://docs.buildvision.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Microsoft Dynamics 365
> Connect BuildVision to Dynamics 365 Sales, company-wide or as yourself.
BuildVision connects to Dynamics 365 through Microsoft's standard OAuth. You
never create an application in your own Azure tenant, and you never send
BuildVision a username or password.
You need to be an organization admin in BuildVision. The company-wide method
also needs a Microsoft administrator in your tenant.
Before you start, have your **environment URL** ready. It looks like
`https://yourcompany.crm.dynamics.com` and you'll find it in the Power Platform
admin center.
## Set up the connection
Pick one of the two methods below. Company-wide is recommended, and you can
switch later.
BuildVision authenticates as its own application against an application user
that you create in Dataverse. Records show BuildVision as the creator, and
nothing expires when someone leaves.
Your Microsoft administrator does this once, in about 10 minutes.
Go to **CRM Hub**, choose **Company-wide**, and enter your environment URL and
your Microsoft directory (tenant) ID. BuildVision shows you the application ID
to use in the next steps.
Open the consent link BuildVision gives you and approve the BuildVision
application for your tenant. This is a one-time approval, and it's the step
that usually needs a tenant administrator rather than a rep.
In the [Power Platform admin center](https://admin.powerplatform.microsoft.com):
1. Select **Manage** in the left navigation pane.
2. In the Manage pane, select **Environments**, then select your environment.
3. Select **Settings**. It only appears after an environment is selected.
4. Select **Users + permissions**, then **Application users**.
5. Select **+ New app user**, then **+ Add an app**, and search for the BuildVision app ID.
6. Pick a **Business unit**, enter any **Email address**, then assign the security role below and select **Create**.
Start from Microsoft's standard **Basic User** role and add the rows below on
top of it. Basic User already grants the Business Management and Customization
reads that Dynamics needs to save a record at all. Building a role from
scratch means discovering those one failed send at a time.
| Tab | Row | Privileges | Why |
| ------------------- | ------------- | -------------------------------------- | ----------------------------------------------------------------- |
| Core Records | Opportunity | Create, Read, Write, Append, Append To | Project records, the core of the integration |
| Core Records | Account | Create, Read, Write, Append, Append To | Contractor and bidder organizations |
| Core Records | Contact | Create, Read, Write, Append, Append To | Bidder contacts |
| Business Management | User | Read | Reading our own application user |
| Business Management | User Settings | Read | Reading our own application user settings when saving a record |
| Business Management | Organization | Read | Dataverse reads the environment's own settings when saving |
| Business Management | Business Unit | Read | Resolving which business unit a new record belongs to |
| Business Management | Currency | Read | Resolving the environment currency for an opportunity amount |
| Customization | Field | Read | Resolving column definitions when writing a record, metadata only |
| Customization | System Job | Read | Reading the background job a create can queue in your environment |
These privileges are not all on one tab, and several row labels differ from
the table name. **User** is on Business Management, not Core Records.
Column metadata appears as **Field** on Customization, which also has an
**AttributeMap** row that looks similar and does not work. Granting
everything except **Field** is the most common mistake: every read succeeds
and the first send still fails.
`Append` and `Append To` are not padding. Relating an opportunity to an
account or contact is a write against both tables, so without them an
opportunity is created and then fails to attach to anything.
Back in BuildVision, connect. BuildVision checks which of the privileges above
the application user actually holds and tells you which are missing, so you
don't have to find them one failed send at a time.
BuildVision acts as you. Records in Dynamics show your name as the creator, and
you push each project yourself.
Go to **CRM Hub**, choose **Connect my own account**, and enter your
environment URL. You don't need a directory ID for this method.
Approve the BuildVision application. The consent screen reads "BuildVision".
BuildVision returns you to CRM Hub with the connection active.
This connection is tied to your user account. It stops working when you leave
the company or reset your password, and because it acts as a person it cannot
support writes that run without someone present. Move to the company-wide
method when your administrator is available.
Your tenant may still require a Microsoft administrator to approve BuildVision
once before any user can connect. If sign-in ends with a message about needing
admin approval, that's what happened.
## What BuildVision does not ask for
The role above has no **Delete**, **Assign**, or **Share** privileges on any
table, and nothing beyond the listed rows. BuildVision has no reason to remove
or reassign records in your CRM. If your security review needs this in writing,
point them at this page.
## Disconnect
Open **CRM Hub** and disconnect. BuildVision stops writing to Dynamics
immediately. Records already created in your CRM stay where they are.