What's Changed Since the Previous Guide
If your team set this up before, the old process asked you to create your own Microsoft app registration, generate a client secret, send us six values, and rotate that secret before it expired. All of that is gone.
In the new model:
No app registration for you to create.
No client secret to generate, send securely, or ever rotate - we own our credential and rotate it ourselves.
No redirect URI for you to configure.
You send us two values and approve one application.
What's Expected of You, in Short
Send us your tenant ID and email domains.
Wait for our confirmation while we configure our side.
Grant admin consent to the WorkBuzz Dialogue application, using a link we send you.
Test a sign-in with us
You send us just two things:
Directory (tenant) ID
Every email domain your people sign in with
We never ask for a client secret, for administrator credentials, or for any access to your Entra environment.
How the Integration Works
The new model uses one application, owned by WorkBuzz.
WorkBuzz owns the application — a multi-tenant Microsoft application called "WorkBuzz Dialogue". We hold its credentials and rotate them ourselves.
WorkBuzz owns the identity provider in our AWS Cognito user pool. It is pinned to your tenant, so only users from your own Microsoft directory can authenticate through it.
Your part is a one-time approval. You approve the WorkBuzz Dialogue application into your tenant (admin consent), which lets your people sign in through it. There is nothing for you to build or maintain.
Unlike the previous process, you will see a "WorkBuzz Dialogue" application on the Microsoft consent screen. That is our application, and approving it is the whole point of this step. In the old model the app was your own; in the new one it is ours, shared safely across customers and locked to your tenant on our side.
What Gets Exchanged
Detail | Direction | Where it comes from |
Directory (tenant) ID | You send to us | Entra admin centre → Overview |
User email domains | You send to us | The domains your people sign in with |
Admin-consent link | We provide | We send it after we've configured our side (Step 2) |
That is the entire exchange - no secret, no redirect URI, no rotation.
Prerequisites
Permissions
The administrator granting consent needs one of:
Global Administrator
Privileged Role Administrator
Cloud Application Administrator
All three can grant tenant-wide admin consent. Application Administrator alone is not sufficient - it cannot grant the consent in Step 3.
Technical
An active Microsoft 365 or Entra ID subscription - any tier, including Free, P1 and P2
Access to the Microsoft Entra admin centre
Your users have valid email addresses in your Microsoft tenant
Step 1: Send Us Your Tenant ID and Email Domains
Finding your tenant ID
Sign in to the Microsoft Entra admin centre
Go to Identity → Overview
Copy the Tenant ID, also called Directory ID - a GUID in the form 12345678-1234-1234-1234-123456789abc
Confirming your user email domains
Tell us every domain your people use to sign in - for example @yourcompany.com plus any acquired-brand or regional domains.
This one matters more than it looks. Dialogue decides whether to show the Continue with Microsoft button based on the domain of the email address a user types on the login page. If a domain is missing from our configuration, people on that domain will only see the email and password form.
Step 2: We Configure the Identity Provider
Once we have your tenant ID and domains, we will:
Create an OpenID Connect identity provider in our Cognito user pool using the WorkBuzz Dialogue application, pinned to your tenant with issuer URL https://login.microsoftonline.com/{your-tenant-id}/v2.0 and scopes openid email profile
Map the email and name attributes from Microsoft through to Dialogue
Register your email domains so the Continue with Microsoft button appears for your users
Send you a ready-to-click admin-consent link (with your tenant already filled in) and confirm we're ready for Step 3
Step 3: Grant Admin Consent to WorkBuzz Dialogue
What admin consent is
A one-time approval that registers the WorkBuzz Dialogue application in your tenant and lets it read the minimal profile information needed to sign a user in. Without it, users in tenants that restrict consent hit an "Approval required" screen and cannot sign in.
How to grant it
Use the link we send you in Step 2 (your tenant is already filled in). Its form is:
Open the link while signed in as an administrator with one of the roles listed under Prerequisites
Review the requested permissions (below) and click Accept
After you accept, Microsoft records the consent. You may briefly land on a technical page or a Dialogue URL - that's expected; the approval is what matters.
Permissions Requested
Permission | Purpose | Data access |
openid | Sign users in | Basic authentication |
Read the user's email address | Work email, used to match the Dialogue account | |
profile | Read basic profile | Name, for display purposes |
These permissions:
✔ Allow Dialogue to verify user identity
✔ Enable single sign-on
✘ Do not grant access to files, calendars, or any other Microsoft 365 data
✘ Do not allow sending email on behalf of users
✘ Do not provide access to other Azure resources
About the Wording on the Consent Screen
The consent screen describes profile as "View users' basic profile". This reads more broadly than it is - it refers to the standard OpenID Connect profile scope, which returns only the signed-in user's own name and email. It does not grant access to your wider directory.
If Admin Consent Is Blocked
Some tenants restrict consent to applications from verified publishers, or route it through an admin-approval workflow. Admin consent granted directly by an administrator (the step above) normally succeeds even under a verified-publisher restriction. If your tenant blocks it entirely, contact us - we'll help you complete it.
Verifying Consent Later
Verify: Entra → Identity → Applications → Enterprise applications → find "WorkBuzz Dialogue" → Permissions shows the granted scopes
Step 4: Test
Before you test
Use an account with a valid email address in your Microsoft tenant
The account must already exist in Dialogue. A Dialogue administrator invites users, and the invitation email contains the sign-in link. Signing in with Microsoft does not create a Dialogue account on its own
Use a member of your own tenant, not a guest. Guest and external (B2B) accounts can authenticate, but Microsoft returns their username in an external form that won't match the address they typed. Microsoft SSO is intended for members of your own tenant
Testing steps
Enter your work email address and click Continue
Confirm a Continue with Microsoft button appears
Click it - you're redirected to login.microsoftonline.com
Authenticate, completing MFA if your organisation requires it
Confirm you're returned to Dialogue and signed in, with your name and email shown correctly
Sign out and back in - your Microsoft session should be remembered
What We No Longer Need From You
Compared with the previous process, these are all gone:
✘ No app registration to create
✘ No client secret to generate or send securely
✘ No secret expiry to track, and no rotation - we own and rotate our credential
✘ No redirect URI to configure
You send two values and approve one application. That's the whole job.
Checklist
☐ Confirmed the administrator has Global Administrator, Privileged Role Administrator, or Cloud Application Administrator
☐ Tenant ID sent to us
☐ All user email domains sent to us
☐ Waited for our confirmation and admin-consent link
☐ Admin consent granted to WorkBuzz Dialogue for all three permissions
☐ Test sign-in completed successfully