Connect Dataverse by signing in
You can connect a Dataverse or Dynamics 365 environment by signing in with your own Microsoft account — the same account, the same password, the same phone prompt you use every day. There is nothing to register and no secret to create, and it takes about a minute.
What you are making
A connection is a saved way in to one of your systems. You set it up once, give it a name, and then any workflow can say “read from that” or “write to that” by name. The credential stays with us, encrypted; a workflow never contains it, and neither does anything you export or share.
For Dataverse there are two ways to prove who you are, and this page is about the first:
| Way in | What it is | Best for |
|---|---|---|
| Sign in with Microsoft | The connection acts as you. It sees exactly the tables, rows and columns your own account can see — no more. | Trying it out, everyday work, anything where “what I can see” is the right answer. |
| Advanced: an app registration | The connection acts as an application your Microsoft administrator created, with its own permissions and its own password. | Something that has to run unattended for years with nobody signing in. |
You can have both, on the same account, at the same time. Nothing about the app registration path changed when signing in was added, and an existing connection is untouched.
Signing in, step by step
1Open Connections and choose Dataverse
Go to Connections and pick Dataverse / Dynamics 365 from the list of system types. The form on the left changes to the Dataverse one.
2Name the environment, or leave it to us
If you do not know the address, leave the box empty. Sign in, and we show you the environments your Microsoft account can reach — by the names you know them by, “Contoso Production” rather than a host — and you pick one. Nothing is looked up in a portal and nothing is typed.
If you do have the address, pasting it is quicker. The box marked
Environment URL wants what is in your browser's bar when you have the
environment open — something like https://yourorg.crm.dynamics.com. The
part after the slash does not matter; copy the whole thing if it is easier.
The address is still required for the Advanced app registration path further down the page, which does not sign anybody in and so has nothing to ask.
3Press “Sign in with Microsoft”
Nothing is created yet. If you close the Microsoft window, change your mind, or the sign-in fails, there is no half-made connection left behind — the connection is written only once you have signed in and come back.
4Sign in as you normally would
A real Microsoft sign-in window opens: your work address, your password, and whatever second step your organization asks for — an authenticator app, a phone prompt, a security key. All of it works, because it is Microsoft's own screen and not an imitation of one. If your organization has rules about which devices or networks may sign in, those apply here too.
Use your work account. Dataverse is a work-account system, so a personal Microsoft account will be accepted at the first box and then fail.
5Approve the permission request
Microsoft then shows a consent screen — the “this application would like to…” page. It is asking for two things:
- Access Dynamics 365 as you. That is the whole of it: we act as you, and see what you see. There is no separate list of tables to approve, and approving it gives us nothing your own account does not already have.
- Maintain access to data you have given it access to. This is the part that lets a workflow run tomorrow morning without you being at your desk. Without it, the connection would stop working the moment you closed the browser.
6Pick your environment, and you are back on Connections
If you left the address empty, this is where you are shown what your account can reach and choose one. Give the connection a name — the environment's own short name is filled in for you — and press Connect this environment. An environment Microsoft reports as disabled or still being prepared is listed too, grayed out, so you can see it is there and why you cannot pick it yet. If you pasted an address, there is nothing to choose and you go straight through.
The new connection appears in the list, highlighted, with your environment's name and its address on it. Press Test and it will reach your environment and come back. Making and testing a connection is free.
“You need admin approval”
Most organizations let an ordinary employee approve a request like this for themselves, because it grants nothing they do not already have. Some do not: an organization can switch off self-approval, often specifically for applications whose publisher is not verified. In that case the sign-in stops with a message about needing an administrator, and there is nothing you can do from your side.
The fix is a single one-time approval for the whole organization, made by an administrator, after which everybody can sign in normally. It is not something we can do for you and not something you can do for yourself. Ask us and we will send your administrator the exact link, which takes them about a minute; there is no screen for it on the site yet.
Once approved, the permission is theirs to inspect: it appears in their Microsoft directory under enterprise applications, where they can see it, see who has used it, and revoke it, without asking us and without us being able to stop them.
“Runs as”: whose eyes the workflow uses
Every Dataverse connection in the list says who it acts as, because it decides which rows a workflow can read and which it can change:
| Runs as your address | Made by signing in. The workflow sees what that person sees. If their access in Dataverse is narrowed later, the workflow narrows with it — automatically, and without anyone telling us. |
| Runs as an application | Made with an app registration. The workflow sees what the administrator gave that application, which has nothing to do with any person's access. |
This is worth a moment's thought before you build on a personal connection: a workflow somebody else relies on, running as you, stops working the day you leave. That is not a fault — it is the same rule applied consistently — but it is a reason to use an app registration for anything the business depends on.
Why a personal connection eventually asks you to sign in again
A sign-in does not last forever. Microsoft keeps a connection like this alive as long as it is being used, and lets it lapse once it has been idle for a stretch — roughly three months of nothing at all. A connection a workflow uses every day never lapses; one you made for an experiment in March and forgot about does.
You get warned before it matters. A connection that has not been used for a couple of months starts saying so on its row, with how long it has been. Past that, the row says to sign in again, and there is a Sign in again button on it — it takes you through the same Microsoft screen and puts the same connection back to work. Nothing else about it changes: same name, same environment, and every workflow that names it keeps working.
If a workflow does hit a lapsed connection, it says exactly that. It does not say your credentials are wrong and it does not fail with an unexplained error.
A personal connection can only ever be re-signed-in as the same environment it was made for. Signing in again cannot quietly re-point it somewhere else.
If you are part of a business account
An employee's connections belong to the business, not to the employee. So when somebody with an employee account signs in here, the connection they make is on the business: their colleagues can use it in their workflows, and it survives that person changing roles.
It still runs as the person who signed in, which is worth saying out loud — colleagues can use the connection, and it will see what that one person can see. Accounts and account types explains what a business account and an employee account are.
The other way: an app registration
Under Advanced on the same form is the original path, unchanged. It asks for three things your Microsoft administrator produces — a directory identifier, an application identifier, and a password for that application — and the connection then acts as that application rather than as a person.
Choose it when the answer to “who should this run as?” is “nobody in particular”: a nightly job, a shared integration, anything that must not stop when a person leaves or takes a month off. It never asks anyone to sign in again. In exchange, somebody with administrator rights has to set it up, and the application's password has to be replaced when it expires — you paste the new one onto the same connection.
There is a guided walkthrough for the administrator at Entra setup, which produces the three values in order.