Microsoft is rolling out a Viva Glint admin control in June 2026, for worldwide and GCC tenants, that lets service administrators set a tenant-level data retention period governing historical engagement, always-on, lifecycle, and 360 survey data across Microsoft Viva feedback instances. This is not a cosmetic compliance toggle. It is Microsoft moving one of the messier parts of employee-experience software—how long organizations keep sensitive workplace sentiment data—from support-driven exception handling into administrator policy. For HR, legal, security, and Microsoft 365 admins, the change turns Viva Glint from a repository that could quietly accumulate years of employee feedback into one that must be governed like the rest of the enterprise data estate.
Viva Glint has always occupied an awkward corner of the Microsoft 365 universe. It is not email, not chat, not a document store, and not quite HRIS. Yet the data it holds can be more sensitive than any of those: employee morale, manager feedback, free-text comments, lifecycle survey responses, 360-degree reviews, and the organizational attributes that make those answers useful.
That sensitivity is what makes the new retention feature matter. Microsoft says Glint service administrators will be able to configure a data retention policy based on organizational requirements. Once configured, past survey cycles are retained or deleted according to that period.
The important word is past. This is not just about future surveys created after a policy takes effect. Microsoft’s own documentation indicates that existing settings carry forward and that data exceeding a configured retention period may be deleted. In plain terms, administrators should treat this as a live governance control, not a harmless preference screen.
The rollout lands in General Availability for the web version of Microsoft Viva, across standard commercial multi-tenant Microsoft 365 and GCC. That breadth matters because the buyers most likely to care about retention—regulated companies, public-sector organizations, and large enterprises with formal records schedules—are exactly the customers that have struggled with SaaS feedback platforms behaving like permanent vaults.
The new control does not erase that default. It adds a self-service alternative. Administrators can keep the “until subscription ends” model, or they can define a custom retention period in months.
Microsoft’s documentation describes a supported custom range from 6 to 1000 months. That upper bound is so large that it effectively preserves the old behavior for organizations that merely want a formal number in the policy field. The lower bound, however, is where the real governance teeth sit: six months is short enough to force hard conversations about how much historical employee feedback an organization truly needs.
For some companies, a long retention period is defensible. Engagement programs often rely on year-over-year comparison, leadership transition analysis, and proof that action plans were or were not followed. But indefinite retention is increasingly hard to justify when survey data can contain comments about managers, accommodations, culture, misconduct, burnout, discrimination, or workforce changes.
The new control is therefore less about storage hygiene than risk appetite. Keeping ten years of employee feedback may be analytically useful. It may also be a discovery problem, a privacy problem, and a trust problem.
That is a meaningful product maturation step. In modern Microsoft 365 administration, retention cannot be a bespoke request that lives in a ticketing queue. It has to be visible, repeatable, auditable, and understandable to the people who will be accountable when data disappears—or when it does not.
The move also aligns Viva Glint with the broader Microsoft 365 governance philosophy. Microsoft has spent years teaching customers to think in terms of retention labels, lifecycle rules, audit trails, eDiscovery, and data minimization. Glint cannot sit outside that model forever simply because it arrived through Microsoft’s acquisition of Glint rather than being born inside Exchange, SharePoint, or Teams.
Still, administrators should not mistake this for full Purview-style records management. This is a Glint-specific retention control for Glint survey data. It is not a universal Microsoft 365 retention label, and it does not magically solve every compliance obligation surrounding employee feedback.
For engagement, recurring, ad-hoc, and lifecycle surveys, retention is evaluated from the survey cycle end date, once the cycle is completed. For always-on surveys, the response date is the anchor. For 360 surveys, Microsoft ties retention to the feedback cycle’s effective due date, using the latest subject due date or the cycle due date if no subjects exist.
Those distinctions sound procedural, but they matter because survey programs do not behave like files. A document has a creation date and maybe a modification date. A Glint program can have recurring cycles, late responses, reporting conversations, action plans, goals, focus areas, and imported historical data.
That complexity is why retention policy in this space can surprise administrators. A survey created years ago may still have associated reporting artifacts that business leaders consider active. A lifecycle survey may generate ongoing trend value long after an employee has left. A 360 program may be sensitive not only because of its responses, but because of who gave feedback about whom.
Microsoft’s warning is blunt: when the retention period is met, applicable Glint survey data is permanently deleted, and the action is irreversible. That is the kind of sentence administrators should print out and tape next to the change-management process.
The new problem is healthier but harder: someone has to choose a number. Six months, 24 months, 36 months, 84 months, and “until subscription ends” are not merely technical settings. They express an organization’s judgment about evidence, analytics, privacy, employee trust, and regulatory exposure.
HR may want a long runway for trend analysis. Legal may want less discoverable historical material. Compliance may want policy consistency across regions. Works councils or employee representatives may have expectations about how survey comments are stored and used. Security teams may simply ask why another cloud system needs years of sentiment data tied to organizational structure.
This is where the feature becomes politically useful. A configurable retention policy forces the conversation into the open. It gives administrators a reason to ask whether old engagement data is still serving employees, or merely serving institutional memory.
That is exactly the kind of behavior that can look like a bug to an unprepared project team. A company migrating legacy engagement data into Viva Glint could import years of survey history, only to discover that its newly configured retention policy immediately makes some of that data eligible for deletion.
The right lesson is not to avoid retention. The lesson is to sequence migration and governance deliberately. Before importing historical survey data, organizations should decide whether that data is needed, whether it is lawful and appropriate to retain, and whether the configured Glint retention period matches the migration plan.
For Microsoft 365 administrators, this is another reminder that SaaS migration projects are now governance projects. The technical act of moving data is often the easy part. The harder question is whether the destination platform is configured to keep that data once it arrives.
That distinction matters. A survey-data retention period governs how long categories of Glint survey data remain in the system. Deleted-user controls govern what happens when an individual user is removed or when a data subject request requires action.
The two policies can intersect in uncomfortable ways. If a deleted manager’s identifying details are removed but historical survey responses remain, reporting hierarchies and trend data may change. If survey responses are deleted with the user, response rates and analytics can shift. If a broad survey retention policy later deletes entire cycles, the impact is larger still.
Admins should therefore avoid treating the new retention control as an isolated setting. It belongs in the same governance review as DSR procedures, HRIS imports, employee ID reuse, manager hierarchy correction, raw data export, and audit logging.
That does not mean every GCC customer will use short retention. Public-sector organizations can have long records obligations. But it does mean Microsoft recognizes that customers in regulated environments need explicit control over how long this category of employee data persists.
The same logic applies outside government. Multinational companies face regional privacy regimes and internal labor rules that may not tolerate indefinite retention of employee sentiment data. Even where the law does not prescribe a specific number of months, privacy teams increasingly expect systems to justify retention periods.
Viva Glint’s new policy control gives those teams something concrete to point to. It does not make the decision for them. It makes the decision enforceable.
That is predictable. Once employee experience software becomes part of Microsoft 365, it inherits Microsoft 365 expectations. Admins want lifecycle controls. Security wants auditability. Compliance wants retention. Legal wants defensible deletion. HR wants dashboards that continue to work.
Viva Glint sits at the intersection of all those demands. It is an HR-facing product, but its data controls increasingly need to be understood by IT. The new retention setting is a clear example: HR may own the survey program, but Microsoft 365 or Viva service administrators may own the configuration that determines whether old data remains available.
That division of responsibility can be dangerous if organizations do not formalize it. A Glint admin changing retention without HR approval could destroy historical benchmarks. HR insisting on indefinite retention without legal review could increase privacy exposure. IT refusing to touch the setting because “it’s an HR tool” could leave the tenant misaligned with corporate policy.
The feature is simple. The governance model around it is not.
The risk is that organizations will set a retention value and assume they are done. But retention policy only works if everyone understands what it covers, what it excludes, when the clock starts, and what downstream artifacts vanish with the underlying data.
Microsoft says the policy applies broadly to Glint survey data, including programs, 360 data, associated reporting conversations, actions, and more, while not applying to configuration settings. That distinction should be tested against each organization’s reporting needs. If a leadership team expects to revisit a three-year-old engagement action plan, retention policy may affect what is still there.
There is also the human side. Employee surveys depend on trust. Workers are more likely to be candid when they believe their feedback is handled responsibly. A clear retention policy can support that trust, but only if the organization communicates it honestly.
Deleting old data is not merely a compliance exercise. It is a statement that employee feedback is collected for a purpose, used within a defined window, and not kept indefinitely just because storage is cheap.
The second step is policy mapping. If the organization already has retention schedules for HR records, employee relations material, survey responses, or analytics datasets, Glint should be reconciled with those schedules. If no such schedule exists, the new Microsoft control is a forcing function to create one.
The third step is stakeholder review. HR, legal, compliance, privacy, security, and Microsoft 365 administration all have legitimate interests here. No single group should quietly decide the retention period unless the organization has already delegated that authority.
Finally, admins should document the chosen value, the reason for it, the approval path, and the expected impact. That documentation will matter when someone later asks why a survey cycle is gone—or why it is still there.
Viva Glint data is not generic telemetry. It is a record of how employees describe their workplace, their managers, their culture, and sometimes their reasons for leaving. That makes retention both valuable and dangerous.
Near-term, administrators should focus on the concrete mechanics:
Microsoft Puts an Expiration Date on Workplace Sentiment
Viva Glint has always occupied an awkward corner of the Microsoft 365 universe. It is not email, not chat, not a document store, and not quite HRIS. Yet the data it holds can be more sensitive than any of those: employee morale, manager feedback, free-text comments, lifecycle survey responses, 360-degree reviews, and the organizational attributes that make those answers useful.That sensitivity is what makes the new retention feature matter. Microsoft says Glint service administrators will be able to configure a data retention policy based on organizational requirements. Once configured, past survey cycles are retained or deleted according to that period.
The important word is past. This is not just about future surveys created after a policy takes effect. Microsoft’s own documentation indicates that existing settings carry forward and that data exceeding a configured retention period may be deleted. In plain terms, administrators should treat this as a live governance control, not a harmless preference screen.
The rollout lands in General Availability for the web version of Microsoft Viva, across standard commercial multi-tenant Microsoft 365 and GCC. That breadth matters because the buyers most likely to care about retention—regulated companies, public-sector organizations, and large enterprises with formal records schedules—are exactly the customers that have struggled with SaaS feedback platforms behaving like permanent vaults.
The Default Is Still Forever, but Forever Is No Longer the Only Answer
By default, Viva Glint customer data is retained indefinitely while the tenant maintains an active Viva Glint subscription. That is the classic enterprise SaaS compromise: data remains available because customers may need trend lines, benchmarks, historical dashboards, manager comparisons, and longitudinal analytics.The new control does not erase that default. It adds a self-service alternative. Administrators can keep the “until subscription ends” model, or they can define a custom retention period in months.
Microsoft’s documentation describes a supported custom range from 6 to 1000 months. That upper bound is so large that it effectively preserves the old behavior for organizations that merely want a formal number in the policy field. The lower bound, however, is where the real governance teeth sit: six months is short enough to force hard conversations about how much historical employee feedback an organization truly needs.
For some companies, a long retention period is defensible. Engagement programs often rely on year-over-year comparison, leadership transition analysis, and proof that action plans were or were not followed. But indefinite retention is increasingly hard to justify when survey data can contain comments about managers, accommodations, culture, misconduct, burnout, discrimination, or workforce changes.
The new control is therefore less about storage hygiene than risk appetite. Keeping ten years of employee feedback may be analytically useful. It may also be a discovery problem, a privacy problem, and a trust problem.
Retention Policy Becomes a Product Boundary, Not a Support Ticket
One reason this update deserves attention is that it shifts retention from a back-office service configuration into the product experience. Microsoft Learn material previously pointed customers toward support for certain Glint retention configuration needs. The roadmap item and updated documentation point to a more direct administrator workflow in Glint general settings.That is a meaningful product maturation step. In modern Microsoft 365 administration, retention cannot be a bespoke request that lives in a ticketing queue. It has to be visible, repeatable, auditable, and understandable to the people who will be accountable when data disappears—or when it does not.
The move also aligns Viva Glint with the broader Microsoft 365 governance philosophy. Microsoft has spent years teaching customers to think in terms of retention labels, lifecycle rules, audit trails, eDiscovery, and data minimization. Glint cannot sit outside that model forever simply because it arrived through Microsoft’s acquisition of Glint rather than being born inside Exchange, SharePoint, or Teams.
Still, administrators should not mistake this for full Purview-style records management. This is a Glint-specific retention control for Glint survey data. It is not a universal Microsoft 365 retention label, and it does not magically solve every compliance obligation surrounding employee feedback.
Survey Data Does Not Age Like Email
The most interesting part of the feature is how Microsoft defines the clock. Different Glint data types age from different moments, and that distinction is crucial for anyone trying to map the feature to internal policy.For engagement, recurring, ad-hoc, and lifecycle surveys, retention is evaluated from the survey cycle end date, once the cycle is completed. For always-on surveys, the response date is the anchor. For 360 surveys, Microsoft ties retention to the feedback cycle’s effective due date, using the latest subject due date or the cycle due date if no subjects exist.
Those distinctions sound procedural, but they matter because survey programs do not behave like files. A document has a creation date and maybe a modification date. A Glint program can have recurring cycles, late responses, reporting conversations, action plans, goals, focus areas, and imported historical data.
That complexity is why retention policy in this space can surprise administrators. A survey created years ago may still have associated reporting artifacts that business leaders consider active. A lifecycle survey may generate ongoing trend value long after an employee has left. A 360 program may be sensitive not only because of its responses, but because of who gave feedback about whom.
Microsoft’s warning is blunt: when the retention period is met, applicable Glint survey data is permanently deleted, and the action is irreversible. That is the kind of sentence administrators should print out and tape next to the change-management process.
The Feature Solves One Problem by Creating a Better One
The old problem was obvious: employee feedback data could accumulate indefinitely unless an organization took explicit action to delete it. That is convenient for dashboards and terrible for data minimization.The new problem is healthier but harder: someone has to choose a number. Six months, 24 months, 36 months, 84 months, and “until subscription ends” are not merely technical settings. They express an organization’s judgment about evidence, analytics, privacy, employee trust, and regulatory exposure.
HR may want a long runway for trend analysis. Legal may want less discoverable historical material. Compliance may want policy consistency across regions. Works councils or employee representatives may have expectations about how survey comments are stored and used. Security teams may simply ask why another cloud system needs years of sentiment data tied to organizational structure.
This is where the feature becomes politically useful. A configurable retention policy forces the conversation into the open. It gives administrators a reason to ask whether old engagement data is still serving employees, or merely serving institutional memory.
Historical Imports Now Carry a Governance Trap
One easily missed implication is Microsoft’s treatment of historical imports. Documentation indicates that retention applies to imported historical data as well. If imported data is older than the retention period in place, it may be deleted shortly after the import completes.That is exactly the kind of behavior that can look like a bug to an unprepared project team. A company migrating legacy engagement data into Viva Glint could import years of survey history, only to discover that its newly configured retention policy immediately makes some of that data eligible for deletion.
The right lesson is not to avoid retention. The lesson is to sequence migration and governance deliberately. Before importing historical survey data, organizations should decide whether that data is needed, whether it is lawful and appropriate to retain, and whether the configured Glint retention period matches the migration plan.
For Microsoft 365 administrators, this is another reminder that SaaS migration projects are now governance projects. The technical act of moving data is often the easy part. The harder question is whether the destination platform is configured to keep that data once it arrives.
Deleted Users Are a Separate but Related Minefield
The roadmap item concerns retention for Glint survey data, but it sits alongside another sensitive Viva Glint policy area: deletion of user data. Microsoft has separate controls and documentation for handling deleted users, data subject requests, and whether survey responses should be removed along with identifying user information.That distinction matters. A survey-data retention period governs how long categories of Glint survey data remain in the system. Deleted-user controls govern what happens when an individual user is removed or when a data subject request requires action.
The two policies can intersect in uncomfortable ways. If a deleted manager’s identifying details are removed but historical survey responses remain, reporting hierarchies and trend data may change. If survey responses are deleted with the user, response rates and analytics can shift. If a broad survey retention policy later deletes entire cycles, the impact is larger still.
Admins should therefore avoid treating the new retention control as an isolated setting. It belongs in the same governance review as DSR procedures, HRIS imports, employee ID reuse, manager hierarchy correction, raw data export, and audit logging.
GCC Availability Signals the Compliance Center of Gravity
The inclusion of GCC in the roadmap is not a footnote. Government Community Cloud customers tend to scrutinize data handling, retention, and administrative control more aggressively than ordinary commercial tenants. When a Viva feature ships to GCC alongside worldwide standard tenants, Microsoft is signaling that the feature is part of the compliance substrate, not merely a quality-of-life improvement.That does not mean every GCC customer will use short retention. Public-sector organizations can have long records obligations. But it does mean Microsoft recognizes that customers in regulated environments need explicit control over how long this category of employee data persists.
The same logic applies outside government. Multinational companies face regional privacy regimes and internal labor rules that may not tolerate indefinite retention of employee sentiment data. Even where the law does not prescribe a specific number of months, privacy teams increasingly expect systems to justify retention periods.
Viva Glint’s new policy control gives those teams something concrete to point to. It does not make the decision for them. It makes the decision enforceable.
The Admin Console Is Becoming the HR Data Control Plane
Microsoft Viva was originally pitched as an employee experience platform: communications, learning, insights, goals, and feedback under one Microsoft 365 umbrella. But as Viva matures, its center of gravity is shifting toward administration and governance.That is predictable. Once employee experience software becomes part of Microsoft 365, it inherits Microsoft 365 expectations. Admins want lifecycle controls. Security wants auditability. Compliance wants retention. Legal wants defensible deletion. HR wants dashboards that continue to work.
Viva Glint sits at the intersection of all those demands. It is an HR-facing product, but its data controls increasingly need to be understood by IT. The new retention setting is a clear example: HR may own the survey program, but Microsoft 365 or Viva service administrators may own the configuration that determines whether old data remains available.
That division of responsibility can be dangerous if organizations do not formalize it. A Glint admin changing retention without HR approval could destroy historical benchmarks. HR insisting on indefinite retention without legal review could increase privacy exposure. IT refusing to touch the setting because “it’s an HR tool” could leave the tenant misaligned with corporate policy.
The feature is simple. The governance model around it is not.
The Real Risk Is Accidental Confidence
Microsoft’s roadmap language is concise: administrators can configure retention, and past survey cycles will be retained or deleted based on that period. That sounds clean. Real-world data governance rarely is.The risk is that organizations will set a retention value and assume they are done. But retention policy only works if everyone understands what it covers, what it excludes, when the clock starts, and what downstream artifacts vanish with the underlying data.
Microsoft says the policy applies broadly to Glint survey data, including programs, 360 data, associated reporting conversations, actions, and more, while not applying to configuration settings. That distinction should be tested against each organization’s reporting needs. If a leadership team expects to revisit a three-year-old engagement action plan, retention policy may affect what is still there.
There is also the human side. Employee surveys depend on trust. Workers are more likely to be candid when they believe their feedback is handled responsibly. A clear retention policy can support that trust, but only if the organization communicates it honestly.
Deleting old data is not merely a compliance exercise. It is a statement that employee feedback is collected for a purpose, used within a defined window, and not kept indefinitely just because storage is cheap.
The Work Starts Before the Toggle Moves
Administrators should treat the rollout as a change-management event, not just a new setting appearing in Viva Glint. The first step is inventory: identify the survey programs, historical imports, 360 cycles, always-on surveys, reporting artifacts, and action plans currently in the tenant.The second step is policy mapping. If the organization already has retention schedules for HR records, employee relations material, survey responses, or analytics datasets, Glint should be reconciled with those schedules. If no such schedule exists, the new Microsoft control is a forcing function to create one.
The third step is stakeholder review. HR, legal, compliance, privacy, security, and Microsoft 365 administration all have legitimate interests here. No single group should quietly decide the retention period unless the organization has already delegated that authority.
Finally, admins should document the chosen value, the reason for it, the approval path, and the expected impact. That documentation will matter when someone later asks why a survey cycle is gone—or why it is still there.
Microsoft’s Small Toggle Carries a Large Warning Label
The practical message for WindowsForum readers is straightforward: this is a small roadmap item with big operational consequences. It will not trend like a Windows 11 Start menu change or a Copilot licensing fight, but it touches the same enterprise nerve as every serious Microsoft 365 governance feature.Viva Glint data is not generic telemetry. It is a record of how employees describe their workplace, their managers, their culture, and sometimes their reasons for leaving. That makes retention both valuable and dangerous.
Near-term, administrators should focus on the concrete mechanics:
- Organizations should confirm whether their Viva Glint instance remains on indefinite retention or has an existing retention value that will carry into the self-service experience.
- Administrators should review old survey cycles before setting a shorter retention period, because eligible data can be permanently deleted.
- Migration teams should check retention settings before importing historical Glint data, because older imports may be removed soon after ingestion.
- HR and IT should agree on who is authorized to change the retention period and how that decision is documented.
- Privacy and legal teams should evaluate Glint retention alongside deleted-user handling, data subject requests, HRIS imports, and raw data export practices.
- Employee communications should avoid vague promises and explain retention in plain language when survey trust depends on it.
References
- Primary source: Microsoft 365 Roadmap
Published: 2026-06-26T22:01:51.0909953Z
Loading…
www.microsoft.com - Official source: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: m365admin.handsontek.net
Loading…
m365admin.handsontek.net - Official source: adoption.microsoft.com
Loading…
adoption.microsoft.com
