Send leads to Dynamics 365

Dynamics 365 stores everything in Dataverse, and a lead from the chat becomes a row there. Which table is your choice -- Lead, Contact, Account, Opportunity, or one your customiser built -- and the columns offered are the ones that table actually has.

There is no sign-in button. An app registration in Microsoft Entra holds the credentials, and this route trades them for a short-lived token on every call.

What you need

Four values, and one step that is not a value at all.

• The environment URL, the one Dynamics shows in Settings, like https://contoso.crm4.dynamics.com.
• The directory (tenant) id and the application (client) id of an app registration in Entra.
• A client secret for that registration. Entra shows its value once, when you create it; the id beside it is not the secret.

The application user, which is the step people miss

An app registration by itself can get a token for your environment and do nothing with it. Dynamics answers every call from an identity it does not know with a 403, and a 403 that arrives two seconds after a token was issued reads exactly like a bad secret.

So: in the Power Platform admin centre, open your environment, then Settings, Users + permissions, Application users, and add the registration as an application user with a security role. The role decides what it may create. An application user does not consume a user licence.

Production, sandbox, developer

Each is its own environment on its own host, and a token issued for one is refused by another. That is why the environment URL is a field rather than something we look up: a tenant can hold several, and only you know which one this connection is for.

Connect and route

1. In Destinations, connect Dynamics 365 with the four values. We verify by reading your organisation's own name back, so a green tick means the token works and the application user exists.
2. Pick the table. Lead, Contact, Account and Opportunity come first, then your custom tables, then everything else the environment exposes.
3. Create a route -- which leads it takes, and which table they become.
4. Map the columns. They come from the table definition, so what you see is what your customiser created, under the display names they gave.

What gets sent

Only columns that are valid for create. An id, a calculated column or a rollup never appears in the mapper, because it would fail every lead.

Values are shaped per column type. A whole number or a currency column takes the digits out of what the visitor typed. A yes/no column reads yes, no, true, false, 1 and 0. A date becomes a full timestamp, which is what Dataverse stores.

A Lead needs a surname. Dynamics refuses one without it and the refusal names lastname, not the label somebody mapped. It is filled in from what the lead carries when the mapping leaves it out, so a route is never one missing column away from losing every lead.

What it does not do

Choice columns and lookups are left out of the mapper. A choice wants one of its own option values and a lookup wants another row's id, and a string typed into a chat is neither. Offering them and dropping them at send time would be worse than not offering them.

It creates. It does not update an existing row, and it does not run your duplicate detection rules -- those apply to this insert exactly as they would to any other.

Business Central is a different product with a different API, and is not what this connects to.