Microsoft Viva Feature access management (original) (raw)

To control access to specific Microsoft 365 and Microsoft Viva features, you can create and update policies in the Microsoft 365 admin center or in PowerShell.

You use policies to enable or disable specific features or types of data processing for users and groups in your tenant.

Note

The access controls described in this document aren't available in GCC-High or DoD. For GCC (Government Community Cloud), see the documentation for your specific app for availability.

Creating and managing policies

Admins with correct permissions in the Microsoft 365 admin center or in PowerShell can create and manage access policies. For more information, see the Who can manage access column in the following feature table.

You can manage Copilot policies through Copilot settings in the Microsoft 365 admin center. These policies remain in sync with policies managed through the admin page.

Important

For Viva Engage, these settings apply only to Engage Copilot v1 and don't apply to future releases.

Requirements

Policy creation requires the following elements:

• A supported version of Microsoft 365 or a Viva Suite license.
• A User account created in or synchronized to Microsoft Entra ID.
• A Microsoft 365 group, Microsoft Entra security group created in or synchronized to Microsoft Entra ID, or a distribution group.
• PowerShell use of Exchange Online PowerShell Version 3.2.0 or later. If you need to use non-mail-enabled groups, you must have access to Exchange PowerShell version 3.5.1 or later. If you need to set up policies with the user opted-out by default (soft disable), you must have access to Exchange PowerShell version 3.8.0 or later.

Which policies are possible?

Admins can create the following policies, subject to feature support:

• Enable the feature for everyone in the policy scope without considering user preference.
• Disable the feature for everyone in the policy scope without considering user preference.
• Enable the feature for everyone in the policy scope while providing users the ability to opt out.
• Enable the feature by opting out everyone in policy scope by default, while providing users the ability to opt in (soft disable).

Some features don't support opt-out user controls or soft disable policies for admins to activate. For more information, see the following section or visit the feature's documentation page.

Viva features management

You can use feature access management to manage a collection of Viva Suite features.

Note

The Global admin controls all Copilot features in Viva Engage, Viva Goals, and Viva Insights. Individual app admins also can control the Copilot features users can access.

Some features don't support user/group policies. Policies for one app can also affect the entire tenant or on users in your tenant. For more information, see the feature documentation by using the link in the following table.

Only some features have the controls available for admins to provide users with the option to opt out. Visit the feature's documentation page for more details.

__*__Admins can set soft-disable policies for these features by setting the default user preference to opted-out. In this case, users have the control to opt in to the feature. For more information, see the feature documentation page.

The Global admin controls all Viva Engage Copilot v1 features, Viva Goals, and Viva Insights. Individual app admins can control Copilot features to which they have access.

You can control access to features that support access policies in your tenant. For example, if you have an EDU-based tenant, you can't use policies to gain access to features that aren't otherwise available to EDU tenants.

You can have multiple access policies for an active feature in your organization, so multiple policies can affect user experiences. In that case, the most restrictive policy assigned to the user or group takes precedence. For more information, see the following section Which policy takes precedence.

Changes to access policies take effect for the user within 24 hours, unless noted for a specific feature. Changes for Engage Copilot v1 might take up to 48 hours.

Features support org-wide and user/group policies, unless otherwise noted in an app's feature documentation.

Which policy takes precedence?

A user has one effective policy for each feature. The most restrictive policy applies and is enforced. There are two layers of enforcement:

1. Policy Scope Levels (Most to Least Restrictive):
   • User or Group Policies
   • Tenant Policy
   • Defaults
2. Enablement Policies (Most to Least Restrictive):
   • HardDisable
   • SoftDisable
   • SoftEnable
   • HardEnable

Enforcement Rule

The most restrictive Policy Scope Level takes precedence first. Then within a single Policy Scope Level, the most restrictive Enablement Policy takes precedence.

Examples

A user with a feature policy can also be a member of a group that has the same policy. In this case, rules of precedence determine a user's effective policy, as follows:

• If a user is directly assigned a policy as an individual or as a member of a group, that policy takes precedence. If a user has multiple instances of those policies, the most restrictive policy applies.
• If a user isn't assigned a policy as an individual or member of a group, the org-wide policy applies. It can be the default setting for the feature or a tenant-wide/org-wide policy created by the admin.

Note

Changes to policies can take up to 24 hours to go into effect for most features. Changes to policies for Engage Copilot v1 takes up to 48 hours to go into effect.

Policy precedence includes the following elements:

• When users are in nested groups and you apply access policies to the parent group, the users in the nested groups receive the policies. The nested groups and the users in those nested groups must be created in or synchronized to Microsoft Entra ID.
• When you add users or remove them from a Microsoft Entra ID or Microsoft 365 Group, it can take 24 hours before changes to their feature access take effect.
• When an admin fully enables or disables a feature, the user's opt in/out preference resets to the default state. If an admin re-enables the option allowing a user to opt out of a feature, users must select to opt out of the feature again.

Note

Avoid making changes to the enablement state for a feature less than 24 hours after making an initial change. Quick successive changes might not reset user opt in/out preferences.

For a history of policy creation, updates, and deletions, see the Viva Feature Access Management (VFAM) change logs for your organization in Microsoft Purview.

Additional information and access policy tips

Keep the following elements in mind when working with access policies:

• Policies are evaluated on a per-user basis.
• One policy per feature can be assigned to everyone. This policy serves as the global default state for that feature in the organization.
• When you delete user identities in Microsoft Entra ID, user data is also deleted from Viva feature access management. If user identities are re-enabled during the soft-deleted period, the admin needs to reassign policies to the user.
• When groups in Microsoft Entra ID and Microsoft 365 are deleted, they're deleted from the stored policies. If groups are re-enabled during the soft-deleted period, the admin needs to reassign policies to the groups.

More

Learn how to manage access to features in the Microsoft 365 admin center

Learn how to manage access to features using PowerShell