Microsoft is where the difference between user consent and admin consent stops being a detail. AADSTS90094 and AADSTS90093 mean different things, and only one of them is something the person in front of you can fix. Getting that wrong turns a two-hour install into a three-week escalation.
Available today
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
What a forward deployed engineer does by hand today.
The vendor registers an application in Entra, decides which Graph permissions the capabilities need, and sends a consent link. Whether that link works depends on the tenant's consent policy, which the vendor cannot see and the customer often cannot describe.
The person whose calendar decides your go-live date.
A Global Administrator or Privileged Role Administrator when admin consent is required, which it is for any Graph permission on the admin-only list. Otherwise the installing user can consent for themselves, and the deployment works for exactly one person.
Whose identity the product acts as, and where that grant lives.
Tenant-scoped OAuth against login.microsoftonline.com, tokens against Microsoft Graph. The tenant is recorded as a vendor-scoped pseudonym rather than as raw tenant data, so the same customer is recognisable across destinations without Meetext holding a globally stable identifier.
The repeatable half, turned into software.
Distinguishing admin consent from user consent before the customer hits it, naming the required Graph permissions and which of them an administrator must approve, running the tenant-scoped exchange, refreshing tokens before they expire, and normalising AADSTS codes into signals that mean something.
The half that is theirs and should stay theirs.
Consent, and the tenant policy that decides who can give it. Conditional Access is theirs too, and when it blocks token issuance Meetext reports that rather than guessing which policy did it.
How capabilities map onto what the platform will let you do.
Graph permission names map to capability requirements. Permissions only an administrator can consent to are marked as such in the deployment package, so the security review shows them before the install rather than after it fails.
What has to execute before anyone is told it works.
Authentication against Graph, scope comparison against the package, capability listing, and a real execution. Admin consent required is reported as waiting on the customer's administrator, which is a state, not a failure.
Rotation, expiry, revocation, and who notices first.
Refresh tokens are exchanged before expiry rather than on failure. A removed scope produces a re-authorization request rather than a quiet degradation, and a revoked grant disconnects the environment and offers a reconnection link.
What happens to this customer when you ship version four.
Same freeze as everywhere. A new product version that needs a new Graph permission cannot silently apply to an existing customer, because the consent they gave was for a package with a different digest.
What actually goes wrong, named rather than generalised.
AADSTS90094: admin consent required, which may be the tenant restricting user consent or may be a permission that always needs an admin. AADSTS90093: user consent blocked by policy. AADSTS65001: consent never granted. AADSTS53003: Conditional Access blocked issuance, and the error does not say which policy.
How you learn it broke without the customer telling you.
Graph is watched as a named dependency. When Graph is degraded the deployment is degraded because of Microsoft, and the incident says so, so nobody spends a day debugging their own code during somebody else's outage.
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
Lifecycle coverage
This label is generated from a proof registry in the deployment code, not written on this page. A destination cannot read Available until every lifecycle path above has actually run against the real provider, and a test refuses the claim without dated evidence.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.
