# Dynamics 365

> Connect Microsoft Dynamics 365 to LightHouse: your own Entra app by certificate as a Dataverse application user, what it reads, where the credential is held, and what is indexed.

The engine reads accounts, opportunities and cases from a Dataverse environment into a knowledge base.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The records are not transmitted, and LightHouse does not open the credential.

## The way to connect

| Way                                               | What you do                                                                                                                                                                                                                                                                                                  |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Connect your own Microsoft app by certificate** | The same kind of app as SharePoint’s own-app route: an app registration in your Entra tenant with a certificate. In the Power Platform admin centre, make it an **application user** of the environment with a read-only security role over these three tables. Paste the PEM of the key and its certificate |

## Connect in LightHouse

You need the **Client administrator** (`client_admin`) role, signed in as a person, and a deployment whose engine reads this connector ([compatibility reference](/concepts/telemetry-contract/#compatibility-reference)) and keeps credentials in your own store.

1. Go to **Setup and admin → Connectors**, find **Dynamics 365** (search for it, or filter by its family), and choose **Connect**.
2. Fill in `tenant_id`, `client_id`, `environment_url` (`https://<org>.crm.dynamics.com`) and `objects`.
3. Under **What agents may do with it**, keep **Read only** unless your agents are to write through approved cards.
4. Paste the PEM of your app’s private key and its certificate. Your browser seals it to your deployment; LightHouse never sees it.
5. Your deployment keeps it and checks it at the provider. The card shows the result.

## Connect in code

```yaml
- id: dynamics-knowledge
  purpose: Read Dynamics 365 into the knowledge base.
  executor: python
  target: aal_engine.ingest.connector:run_card
  overseer: ops-lead@example.com
  budget_usd: 0
  effect: internal
  source:
    kind: dynamics
    objects: [accounts, opportunities, cases]
    label: internal
    credential_secret: <connection id>
    requires:
      reads: [dynamics:accounts, opportunities and cases]
      reason: the service agents answer from the account and case history
```

## Permissions

- **The token** is for your environment alone (`<environment>/.default`), minted from an assertion your deployment signs with the certificate. No client secret is accepted.
- **Read only is the application user’s security role.** Dataverse states no permissions in the token, so the access level is your administrator’s choice and the card says so.
- **The health check**: your deployment mints the token and calls `WhoAmI`, which answers only once the app is an application user of the environment.
- **One host**: your environment’s address, sealed with the credential.

## Where the credential is held

LightHouse never opens this credential. It is sealed in your browser, or by `lighthouse-ai connect dynamics --credential-stdin`, to your deployment’s own key, and your deployment keeps it in your own secrets store under `lighthouse/connectors/dynamics/<connection id>`. A request that sends it to LightHouse unsealed is refused with `422 sealing_required`. LightHouse keeps the connection’s fingerprint, the access level, the scopes the provider states and when it was checked: never the credential, and never what it reads.

See [Where every credential is held](/connect/#where-every-credential-is-held).

## What is indexed

- **Accounts, opportunities and cases**: the columns that describe them, with lookups by their names.
- **How often, and what is read each time**: on the card’s schedule. Each pull reads rows whose `modifiedon` is after the cursor, in order, 500 a page.
- **Deletions**: every six hours the ids are listed and a row that has gone is removed.
- **Rate limits**: Dataverse’s service protection limits; a `429` waits as long as Dataverse asks.
- **Never read**: notes, attachments, activities and tables you do not name.

## Check it worked

- The source’s run note in your deployment: `written N, unchanged N, quarantined N, removed N`.
- **Agents → Knowledge**: documents from `dynamics`.
- Content is read in place, in your deployment. LightHouse receives ids, hashes and counts only; the records are not transmitted.

## Removing it

On the card, choose **Disconnect**. Your deployment deletes the credential from your store. Deactivate the application user in the Power Platform admin centre, and remove the certificate under **App registrations** in Entra. Documents already written stay in the corpus until you delete them.

Source: https://docs.atlanticagenticlabs.com/connect/dynamics/