For the people who have to make it work
Three things from you, and a long list of things not from you.
Most of this site is written for whoever decides. This page is for whoever gets handed the decision afterwards. The honest summary is that the work on your side is small and the approvals around it are not, which is the opposite of how these projects are usually sold to you.
What we need
- One work account, signed in early. Against your own directory, in week one, before anything else is built.
- One consent decision on a third-party application, by whoever is allowed to make it.
- One credential for the system being connected, or a delegated sign-in where the system supports it.
What we never need
- No agent on your network. Nothing is installed on a server of yours.
- No inbound firewall change. The connection is outbound from us to your system, or from your people to us.
- No directory migration and no new user list. Your identity provider stays the only list of people.
- No VPN, no site-to-site tunnel, no jump host.
- No change to the assistant your people already use.
The long pole
Do the sign-in test first, before anybody builds anything.
This is the single piece of advice on the page. One work account, signed in against your directory, in the first week. Not because it is hard, but because it is the only step whose duration is genuinely unknown and entirely outside our control.
-
01
Does your directory allow third-party application sign-in at all?
In many organisations it does not without an admin-consent process, and at large ones that process has a queue, an owner and a review. Everything else here takes about a day. This can take a month, and it takes exactly as long whether you discover it in week one or week six.
-
02
What actually crosses when somebody signs in
A verified email address, and nothing else. No password ever reaches us. No group memberships, no directory roles, no manager, no photo. That is deliberate: permissions here are decided by a grant somebody at your company writes, not inferred from directory groups we would then have to keep in step with yours.
-
03
The error you will see if it is misconfigured, and what it really means
Assistants report sign-in failures badly. We have watched a missing DNS record be reported to a user as "could not register with the sign-in service", with a confident suggestion to add an OAuth client ID. If sign-in fails, the useful question is almost never the one the error asks. Send us the message and we will tell you which of the four real causes it is.
-
04
Joiners and leavers stay your process
Somebody who leaves loses their work account, and losing the account ends the access here, because there is nothing to sign in with. You do not maintain a second list. Removing a grant is a separate and faster lever when you want to narrow somebody who is still employed.
The credential
What you hand over depends on the system, and two of the three store nothing.
The question your security team will ask is what secret leaves your control. The answer is per system rather than one policy, and it is worth knowing before the review rather than during it. The full per-system list is on connected systems.
Delegated: nothing stored
The person's own sign-in is exchanged for access at the moment they ask, and no credential is held here at all. The source system enforces its own item permissions. This is what SharePoint uses today, and every Microsoft system would use it.
Per-person token: one each
Each person supplies their own token for that system, held separately and revocable on its own without affecting anybody else. More credentials to manage than one shared secret, and the trade buys real per-person visibility.
Shared secret: one, in a vault
One credential in a key vault, used for every caller, because the system offers nothing better. This is the case where our grants are the only access control, and we say so on the screen where you decide whether it is acceptable.
If you want it switched off, that is a database edit and it applies to the next call.
Not a support ticket, not a deployment, not a credential rotation that breaks it for everybody else. Removing a grant takes effect on the caller's next request, because permission is resolved per request rather than issued in advance. Your administrator does it themselves, in the console.
Running it afterwards
What you own once it is live.
Small, and worth knowing in advance, because "who operates this" is the question that turns a successful pilot into a stalled one.
Yours
- Who holds a grant, and on which project. Written and removed by your own administrator.
- Which capabilities are switched on for a project at all, which is a ceiling above every individual grant.
- Reading and exporting the record. Every call, allowed or refused, is yours to read.
- The credential for your own system, rotated on your schedule.
Ours
- The connector, the host and the patching. Nothing runs on your infrastructure.
- The adapters, and telling you plainly which systems have one.
- Failing closed. If our control plane is unreachable, requests are refused rather than allowed through.
What to watch, if you want one thing on a dashboard. Refusals, not successes. A person repeatedly hitting the same boundary is either misconfigured or probing, and both are worth a look. Every refusal carries one of twenty named codes rather than a sentence, precisely so you can build that alert and have it still work next year.
Start with the sign-in test.
One account, your directory, week one. If it turns out your tenant needs an admin-consent process, that is the timeline, and it is much better to know it before anybody has built anything.