How to Troubleshoot Viva Glint: Full Fix Guide
Why This Is Happening
I've seen this exact frustration play out in dozens of enterprise tenants: an HR team spends weeks designing the perfect Viva Glint survey, schedules the launch, and then , nothing works as expected. Employees can't log in, survey emails bounce, dashboards show blank tiles, or reports simply refuse to export. The error messages Viva Glint gives you are almost always vague. "Something went wrong." "Contact your administrator." Not helpful.
Here's the reality of what's usually happening behind the scenes. Viva Glint sits at the intersection of three Microsoft services , Microsoft Entra ID (formerly Azure Active Directory), Microsoft 365, and the Viva suite backend running on Azure. Any misconfiguration or outage in any of those layers can cascade into a Viva Glint failure that looks completely unrelated to its actual cause.
The most common root causes I see break down into five buckets:
- Entra ID provisioning failures, employee attribute data (department, manager, cost center) not syncing correctly from your HR information system (HRIS) or on-premises Active Directory.
- Incorrect license assignment, Viva Glint requires a specific Viva suite license or Viva Workplace Analytics and Employee Feedback SKU. Missing or misassigned licenses are behind a surprising number of "access denied" errors.
- Survey email delivery problems, Glint sends survey invitations from
glint@microsoft.comor a tenant-specific sender domain. If your Exchange Online or third-party mail filter blocks these, employees never get the link. - Browser and cookie conflicts, Glint's web app at
app.glint.microsoft.comdepends on third-party cookies for its session management. Increasingly strict browser defaults and corporate proxy settings break authentication mid-session. - Admin role misconfiguration, Glint has its own role-based access control layer that's separate from Microsoft 365 admin roles. Someone can be a Global Admin in Entra ID and still have zero access inside Glint's admin dashboard.
Who sees this most? Organizations that recently migrated from the standalone Glint platform (before Microsoft acquired it in 2023) to the Microsoft-integrated version tend to hit the most issues. The migration pipeline doesn't always transfer historical role assignments cleanly. Similarly, companies running hybrid Active Directory environments, on-premises AD syncing to Entra ID via Entra Connect, frequently run into attribute mapping problems that only surface during Viva Glint data uploads.
I know this is frustrating, especially when your survey window is live and employees are clicking broken links. The good news: most Viva Glint troubleshooting problems are solvable within an hour if you work through them methodically. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour in admin consoles, try this. It resolves about 40% of Viva Glint issues I see:
Step 1: Open a fresh InPrivate or Incognito browser window. Navigate directly to https://app.glint.microsoft.com and sign in with your Microsoft 365 account. Don't use a saved link, type the URL fresh. This eliminates cached session tokens and stale cookies as a cause.
Step 2: If the page loads but shows an access error, check your license. Go to the Microsoft 365 admin center at admin.microsoft.com → Billing → Licenses. Search for "Viva" and confirm you have either Microsoft Viva Suite or Microsoft Viva Workplace Analytics and Employee Feedback assigned to your account. If neither appears, your tenant may not have the Glint license at all, that's a conversation with your Microsoft account manager.
Step 3: If the license is there but you still can't access Glint, check your Glint-specific role. Inside the Glint admin dashboard (accessible to your Glint Company Admin), go to Configuration → People, search your email, and confirm you have a role assigned. Even a Microsoft 365 Global Admin gets a blank dashboard in Glint without an explicit Glint role.
Step 4: Check the Microsoft 365 Service Health dashboard. Go to admin.microsoft.com → Health → Service Health, then filter for Microsoft Viva. If there's an active incident listed there, you're not doing anything wrong, you're waiting for Microsoft's engineering team to resolve it.
If you've gone through all four steps and it's still broken, keep reading. The issue is deeper.
The single most common cause of Viva Glint access failures is a missing or incorrectly scoped license. This happens a lot after tenant consolidations or when IT provisions users in bulk from a CSV without checking which license plans are included.
Open the Microsoft Entra admin center at entra.microsoft.com. Navigate to Users → All users and select the affected user. Click Licenses in the left panel. Look for any of these SKUs:
- Microsoft Viva Suite
- Microsoft Viva Workplace Analytics and Employee Feedback
- Microsoft 365 E3 or E5 with Viva add-on
If the license is listed but shows a warning icon, click it. You'll often see a service plan conflict, particularly if the user was assigned a conflicting standalone Workplace Analytics license from before the Viva rebrand. Remove the conflicting plan and re-save.
If no Viva license appears at all, you have two options: assign it directly to the user, or better yet, assign it via a group-based licensing policy. To do the latter: go to Groups → find or create your Viva users group → Licenses → Assignments → add the Viva SKU. Group-based licensing is far easier to audit at scale.
After assigning or fixing the license, allow up to 15 minutes for propagation. Then have the affected user sign out of all Microsoft sessions completely using https://mysignins.microsoft.com → Sign out everywhere, then sign back in to app.glint.microsoft.com fresh.
What you should see if it worked: The Glint landing page loads and shows either the employee survey interface or, for admins, the dashboard with survey programs listed.
Viva Glint is built around employee hierarchy data. It needs to know who reports to whom, what department each person is in, and which attributes apply to them for survey filtering. When that data is wrong or missing, you'll see errors like "No matching employees found," blank report segments, or survey programs that refuse to activate.
Glint pulls this data two ways: directly from Entra ID user attributes, or via a file-based SFTP import from your HRIS (Workday, SAP SuccessFactors, BambooHR, etc.). First, identify which method your tenant uses. In the Glint admin dashboard, go to Configuration → People → Employee Data. If you see Microsoft Entra Integration enabled, you're using the API sync. If you see SFTP file upload, you're using flat files.
For Entra ID API sync: The most common issue is that attributes like department, jobTitle, manager, and companyName are blank on user objects in Entra ID. Check a sample user in entra.microsoft.com → Users → select user → Properties. If those fields are empty, the source is your on-premises AD (for hybrid) or your HRIS via provisioning. Run this PowerShell snippet to audit in bulk:
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -All -Property "displayName,department,jobTitle,manager,companyName" |
Select-Object DisplayName, Department, JobTitle, CompanyName |
Where-Object { $_.Department -eq $null -or $_.JobTitle -eq $null } |
Export-Csv .\GlintAttributeAudit.csv -NoTypeInformationThis outputs every user missing a department or job title, the two attributes Glint requires for most survey hierarchies.
For SFTP file uploads: Check the upload history in Glint admin under Configuration → People → Upload History. Failed uploads show a red status with a downloadable error log. The most frequent errors are mismatched column headers (Glint expects Employee ID, not EmpID), duplicate email addresses, and employees listed as their own manager.
What you should see if it worked: The People section in Glint admin shows an accurate employee count matching your expected headcount, and the hierarchy visualization renders without gaps.
If employees say they never received their survey invitation, and you've confirmed the program launched successfully in the Glint dashboard, the problem is almost certainly in email delivery. This is one of the most painful Viva Glint issues because the symptom (no email) is obvious but the cause can be in three different systems.
First, identify what email address Glint is sending from. In the Glint admin dashboard, go to Configuration → Communications. You'll see the sender address, typically glint@microsoft.com or a custom domain if your tenant has configured a branded sender.
Next, check Exchange Online mail flow. Go to the Exchange admin center at admin.exchange.microsoft.com → Mail flow → Message trace. Run a trace for the sender address glint@microsoft.com over the survey launch window. Look for messages with status Failed or FilteredAsSpam.
If messages show as filtered, go to Mail flow → Rules and check whether any transport rule is catching Glint emails. Also check Protection → Anti-spam policies. You may need to add glint.microsoft.com and microsoft.com to your allowed sender list:
# Add Glint sender domain to the default anti-spam policy allow list
Set-HostedContentFilterPolicy -Identity Default `
-AllowedSenderDomains @{Add="glint.microsoft.com","microsoft.com"}If you use a third-party email security gateway (Proofpoint, Mimecast, Barracuda), you'll need to create a bypass rule there as well. The rule should whitelist outbound IPs from Microsoft's sending infrastructure, check the current list at Microsoft's published SPF record for microsoft.com.
One more thing to verify: Glint sends emails in HTML format with embedded survey links. Some enterprise DLP policies strip or rewrite hyperlinks, breaking the survey token embedded in the URL. Check your DLP policies for any URL-rewriting rules and exclude the Glint survey domain app.glint.microsoft.com.
What you should see if it worked: The message trace shows emails delivering with status Delivered, and test recipients receive the survey within a few minutes of you triggering a manual send from Glint admin.
Blank dashboards, spinning loaders that never resolve, and reports that fail to export are among the most reported Viva Glint troubleshooting complaints. I've seen this happen after tenants enable Conditional Access policies that inadvertently block the Glint web app's background API calls.
Start with the browser. Open your browser's developer tools (F12 in Edge or Chrome), go to the Network tab, and reload the Glint dashboard. Filter by XHR or Fetch requests. Look for any requests to api.glint.microsoft.com returning status 401, 403, or CORS error. A 401 means authentication failed on the API layer, usually a Conditional Access block. A CORS error usually means a proxy is intercepting HTTPS traffic and breaking the request headers.
To check for Conditional Access interference, go to entra.microsoft.com → Protection → Conditional Access → Sign-in logs. Filter by the affected user and look at any entries for the application Viva Glint. Entries marked Failure or Interrupted will show you which CA policy is blocking access and why, typically because the user's device is not compliant or not Entra-joined.
If Conditional Access is the cause, you have two options: either exclude the Viva Glint application (App ID: f27a846a-7e9e-4de0-a4b1-1cf99e3c0a97) from the blocking policy, or ensure affected users are accessing Glint from a compliant, enrolled device.
For report export failures specifically, check the user's Glint role permissions. In Glint admin → Configuration → Roles, verify the user has Export Reports permission enabled. This is separate from the ability to view reports, Glint gates export permissions independently.
What you should see if it worked: Dashboard tiles load with data visualizations, and the Export button in the Reports section produces a downloadable file within 30–60 seconds.
Viva Glint surfaces employee engagement nudges and manager action plans directly inside Microsoft Teams via the Viva app. When this integration breaks, managers stop seeing their team insights, and the whole point of having Glint embedded in the daily workflow falls apart.
The Teams integration relies on the Microsoft Viva Teams app being installed and the user having an active Glint session. Start by checking whether the app is installed. In the Teams admin center at admin.teams.microsoft.com, go to Teams apps → Manage apps and search for Microsoft Viva. Confirm the app status is Allowed. If it shows Blocked, someone on your admin team explicitly blocked it, click it and change the status to Allowed.
Next, check app setup policies. Go to Teams apps → Setup policies. The policy assigned to your users needs to include the Microsoft Viva app in the Installed apps or Pinned apps list. If it's not there, click the policy → Add apps → search "Microsoft Viva" → Add → Save.
Even with the app installed, Glint content inside Teams requires the user to authenticate. If managers see a blank panel or a "Sign in" prompt that loops, the issue is usually a missing Teams SSO consent. Run this command to check whether the Viva Glint enterprise application has user consent granted in your tenant:
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -Filter "displayName eq 'Viva Glint'" |
Select-Object DisplayName, Id, AppIdIf the service principal doesn't appear, the app hasn't been consented to in your tenant. Go to entra.microsoft.com → Enterprise applications → New application → search for Viva Glint → Create, then grant admin consent under Permissions → Grant admin consent for [your tenant].
What you should see if it worked: Inside Teams, clicking the Viva app in the left rail shows the Glint tab with the user's survey results or manager dashboard loading without a sign-in prompt.
Advanced Troubleshooting
Group Policy and Tenant-Level Viva Glint Troubleshooting
If you're in an enterprise environment with a large, domain-joined fleet, some Viva Glint issues originate at the Group Policy level rather than the Microsoft 365 layer. Specifically, GPOs that enforce proxy auto-configuration (PAC files) or restrict browser cookie behavior can prevent Glint's web app from functioning even when everything looks correct in the admin consoles.
Check your PAC file configuration. If your organization uses a PAC file to route traffic, confirm that *.glint.microsoft.com, *.microsoft.com, and login.microsoftonline.com are set to DIRECT (bypassing the proxy). Running all Microsoft 365 traffic through an on-premises proxy that doesn't support HTTPS inspection certificates trusted by the OS is a very common cause of authentication failures.
Event Viewer and Diagnostic Logging
On the client side, when Glint fails silently, check the Windows Event Viewer for AAD-related errors. Open Event Viewer → Applications and Services Logs → Microsoft → Windows → AAD → Operational. Look for Event ID 1098 (authentication error) or Event ID 1104 (token acquisition failure). These often reveal whether the failure is a certificate validation problem, a token expiry issue, or a network-level block.
For server-side diagnostics, use the Entra ID Sign-in logs. Navigate to entra.microsoft.com → Monitoring & health → Sign-in logs. Filter by Application Name = Viva Glint and look at the Conditional Access column. Any row showing Failure will expand to show exactly which policy blocked the sign-in and why.
Registry-Level Browser Fix for Persistent Cookie Issues
On managed Windows 11 machines, Microsoft Edge sometimes enforces strict third-party cookie blocking even when configured to allow it through the UI. This is because a registry policy pushed via Intune or Group Policy overrides the UI setting. Check this registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge
Value: BlockThirdPartyCookies
Expected: 0 (or not present)If this is set to 1, a GPO or Intune policy is enforcing the block. You'll need to modify the policy source, either the GPO in Group Policy Management Console or the Intune Device Configuration profile, rather than trying to change the registry directly (it'll revert on next policy refresh).
SFTP Upload Failures for Large Employee Files
If you're uploading employee data via SFTP and the upload completes but the data doesn't appear in Glint, check the file format carefully. Glint requires UTF-8 encoding without BOM (byte order mark). Files exported from Excel often have BOM headers that cause silent parsing failures. Use Notepad++ or VS Code to re-save as UTF-8 without BOM before uploading.
If you've worked through all of the above and Viva Glint is still not functioning, it's time to open a support ticket. Specifically escalate if: your Entra ID sign-in logs show successful authentication but Glint still denies access (this points to a backend provisioning issue on Microsoft's side), your Service Health dashboard shows an active Viva incident, or your SFTP uploads show success in Glint but employee counts don't update after 24 hours. Contact Microsoft Support and reference your tenant ID (found in Entra admin center → Overview) and the specific error timestamps from your sign-in logs, this cuts resolution time significantly.
Prevention & Best Practices
Most Viva Glint problems I see in enterprise environments are entirely preventable. They happen because Glint was set up once and then nobody touched the configuration again, until something broke six months later during a survey launch. Here's how to avoid being in that position.
Run a pre-launch checklist before every survey program. Before any survey goes live, spend 15 minutes in the Glint admin dashboard: confirm employee count matches expectations, send a test survey to yourself, verify the email delivery works, and check that all manager roles have access to their team dashboards. A checklist you run every time is worth more than a sophisticated monitoring setup that runs automatically but never gets reviewed.
Keep your employee data pipeline healthy. If you're using SFTP uploads, set up a weekly automated upload rather than doing it manually before each survey. Stale data (employees who've left still appearing, new hires missing) creates survey anomalies that are hard to explain after the fact. If you're using the Entra ID sync, make sure your HRIS provisioning to Entra is running on at least a daily schedule and that you have an alerting rule for provisioning failures in Entra ID.
Monitor Conditional Access changes. Any time your security team adds or modifies a Conditional Access policy, ask them to verify that Viva Glint (App ID: f27a846a-7e9e-4de0-a4b1-1cf99e3c0a97) is tested against the new policy before it goes live. One well-intentioned "require compliant device" policy pushed to all apps without an exclusion list will break every Viva Glint session for non-enrolled devices overnight.
Assign Glint roles through groups, not individuals. When you assign Glint admin roles to individual users, you inevitably end up with role orphans, people who've left the team but still have admin access, or new team members who can't get in because someone forgot to add them. Create Entra ID security groups for each Glint role (Company Admin, HR Business Partner, Manager) and map those groups to Glint roles in Configuration → Roles → Group Assignments.
- Subscribe to the Microsoft 365 Service Health digest emails so you know about Viva incidents before your users report them
- Add
glint.microsoft.comandapp.glint.microsoft.comto your email security gateway's allow list before your first survey launch - Test Glint access on both Entra-joined and personal (BYOD) devices if your organization has a mixed device fleet
- Document your Glint role structure and SFTP column mapping in a shared IT wiki, the engineer who set it up originally won't be there forever
Frequently Asked Questions
Why can't employees access their Viva Glint survey even though they got the email?
This is almost always a browser or session issue. The survey link contains a one-time authentication token that's tied to the employee's Microsoft account. If they're already signed into a different Microsoft account in that browser (like a personal account), clicking the link can land them on the wrong account's session, which has no Glint access. Tell employees to copy the link and open it in an InPrivate/Incognito window, then sign in with their work email when prompted. If that still fails, check whether the survey program's end date has passed, expired surveys return an unhelpful generic error page rather than a clear "survey closed" message.
Viva Glint admin dashboard is blank, no survey programs showing at all. What's wrong?
A completely blank dashboard almost always means your account has no Glint-level role assigned, even if you're a Microsoft 365 Global Admin. Being a Global Admin gives you access to Microsoft 365 admin center but doesn't automatically grant you any role inside Glint's own role system. Have an existing Glint Company Admin go to Configuration → People, find your account, and assign you the Company Admin role. If there are no existing Glint admins, for example if the original setup person left, you'll need to contact Microsoft Support to have a bootstrap admin assigned at the backend. This is surprisingly common after organizational restructuring.
Viva Glint survey emails are going to spam, how do I fix this for everyone?
This requires action in two places. First, in Exchange Online, add glint.microsoft.com to your organization's safe sender list via the anti-spam policy in the Security & Compliance center, the PowerShell command is in Step 3 above. Second, if you use a third-party gateway like Proofpoint or Mimecast, create a policy rule that whitelists the sender domain microsoft.com and the sending IP range published in Microsoft's SPF record. For Mimecast specifically, this is under Administration → Gateway → Policies → Anti-Spam → Permitted Senders. Don't ask individual employees to add senders to their personal safe lists, that doesn't scale and won't fix the problem for new employees.
Why does Viva Glint show fewer employees than we actually have?
Glint only counts employees who appear in the data source you've configured, either your Entra ID sync or your SFTP upload, and who have a valid, unique email address. The most common reasons for undercounting are: new hires added to your HRIS but not yet provisioned to Entra ID (provisioning cycles can take up to 24 hours), employees with duplicate email addresses in the source data (Glint deduplicates on email and drops the extra record), and employees whose records are missing a required attribute like Employee ID. Download the employee list from Glint admin under Configuration → People → Export, compare it against your HRIS export, and identify the delta. The missing records will tell you what's being filtered or rejected.
Managers can't see their team's results in Viva Glint, results show as "Not enough responses"
This is actually a confidentiality threshold setting, not a bug. Viva Glint suppresses results for any group smaller than the configured minimum response threshold, the default is 5 respondents. If a manager's team has fewer than 5 people, or fewer than 5 responded to the survey, Glint will not display results to protect anonymity. This behavior is by design and is considered a core privacy feature of the platform. If you want to lower the threshold (carefully, this can reduce anonymity), a Glint Company Admin can change it under Configuration → Survey Programs → [your program] → Reporting → Minimum Group Size. Going below 3 is generally not recommended and may violate your organization's survey anonymity commitments to employees.
Viva Glint is working fine in the browser but not loading in Microsoft Teams, what do I check?
When Glint works in the browser but fails inside Teams, the issue is almost always with the Teams app installation or SSO consent, not with Glint itself. First, check whether the Microsoft Viva app is allowed in your Teams admin center under Manage apps. Second, verify that the app setup policy for the affected users includes Microsoft Viva as an installed app, just allowing the app doesn't automatically install it. Third, try having the affected user manually add the Viva app: in Teams, click the Apps icon in the left rail, search "Microsoft Viva," and click Add. If the Add button is grayed out, a Teams app permission policy is blocking it and needs to be updated by a Teams admin.