Control access to features in Viva
You can use access policies in Viva to manage which users can access specific features in Viva apps. Feature access management lets you enable or disable specific features in Viva for specific groups or users in your tenant and so tailor your deployments to meet your local regulatory and business requirements.
Important
You can have multiple access policies for a feature active in your organization. That means that a user or group could be impacted by multiple policies. In that case, the most restrictive policy assigned directly to a user or group takes precedence. For more information, see How access policies work in Viva.
An authorized admin in your tenant can create, assign, and manage access policies from PowerShell. When a user signs into Viva, the policy settings are applied, and they only see the features that haven't been disabled.
Note
You can only disable a subset of features in Viva apps by using feature access management. Restricting the use of one feature might impact the functionality of other features in the app. Be sure to check the app documentation on the specific feature to understand the implications of disabling or enabling access to a feature.
Features available for feature access management
You can use feature access management to manage access to the following features:
Note
- Some features may not support user/group policies. In addition, polices for one app can have an impact on the entire tenant or users in your tenant. For more information, refer to the feature documentation by using the link in the table.
- Only some features have the controls available for admins to provide users with the option to opt out.
| App | Feature | Control for user opt-out? | Who can manage access | ModuleID |
|---|---|---|---|---|
| Engage | Copilot in Engage | No | Engage admin | VivaEngage |
| AI Summarization | Yes | Engage admin | VivaEngage | |
| Goals | Copilot in Viva Goals | No | Goals admin | VivaGoals |
| Insights | Copilot Dashboard | No | Global admin | VivaInsights |
| Copilot Dashboard Auto Enablement | No | Global admin | VivaInsights | |
| Copilot Dashboard Delegation | No | Global admin | VivaInsights | |
| Copilot Assisted Value | No | Global admin | VivaInsights | |
| Digest Welcome Email | No | Global admin | VivaInsights | |
| Meeting cost and quality | No | Insights admin | VivaInsights | |
| Reflection | No | Insights admin | VivaInsights | |
| Pulse | Customization | No | Viva Pulse admin | VivaPulse |
| Team conversations in Pulse reports | No | Viva Pulse admin | VivaPulse | |
| Skills | Skill suggestions* | Yes | Knowledge admin | VivaSkills |
* The feature or feature control might not yet be available for all tenants. Support will be added soon.
Note
- You can only control access to features that support access policies and that are available in your tenant. For example, if you have an EDU-based tenant, you cannot use policies to gain access to features that are not available to EDU tenants. The same applies for features that are unavailable in specific geographies. Check the documentation for the specific feature that you'd like to use for more information about its availability.
- Changes to the Copilot in Viva Engage feature might take up to 48 hours to take effect. Changes for other features generally take effect within 24 hours.
Requirements
Before you can create an access policy in Viva, you need:
- A supported version of Microsoft 365 or a Viva Suite license
- Access to 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.
- User accounts created in or synchronized to Microsoft Entra ID.
- Microsoft 365 groups, Microsoft Entra security groups created in or synchronized to Microsoft Entra ID, or distribution groups. The membership type can be either dynamic or assigned.
- The role required for the specific app and feature.
Important
Viva feature access management isn’t available to customers who have Microsoft 365 GCC, GCC High, or DOD plans.
Create and manage access policies for Viva features
Get the featureID for the feature
Before you can create an access policy, you need to get the featureID for the specific feature you want to control access to.
Use the Get-VivaModuleFeature PowerShell cmdlet to get a list of all of the features available in a specific Viva app and their associated IDs.
Install Exchange Online PowerShell Version 3.2.0 or later:
Install-Module -Name ExchangeOnlineManagementConnect to Exchange Online with admin credentials:
Connect-ExchangeOnlineComplete the authentication as either a global administrator or the role required for the specific feature you're creating the policy for.
Run the Get-VivaModuleFeature cmdlet to see the features that you can manage by using an access policy.
For example, to see which features are supported in Viva Insights, run the following cmdlet:
Get-VivaModuleFeature -ModuleId VivaInsightsFind the feature that you'd like to create an access policy for and make note of its featureID.
Create an access policy
Now that you have the featureID, use the Add-VivaModuleFeaturePolicy PowerShell cmdlet to create an access policy for the feature.
You can assign a maximum of 10 policies per feature to users and groups. Each policy can be assigned to a maximum of 20 users or groups. You can assign one additional policy per feature to the entire tenant by using the -Everyone parameter, which will function as a global default state for that feature across your organization.
Run the Add-VivaModuleFeaturePolicy cmdlet to create a new access policy.
Note
If your feature supports user controls for opt out, make sure you set the IsUserControlEnabled parameter when you create the policy. If you don't, user controls for the policy uses the default state for the feature.
For example, run the following to create an access policy, called UsersAndGroups, to restrict access to the Reflection feature in Viva Insights.
Add-VivaModuleFeaturePolicy -ModuleId VivaInsights -FeatureId Reflection -Name UsersAndGroups -IsFeatureEnabled $false -GroupIds group1@contoso.com,group2@contoso.com -UserIds user1@contoso.com,user2@contoso.com
This example adds a policy for the Reflection feature in Viva Insights. The policy disables the feature for the specified users and group members. If you want to disable the feature for all users, use the -Everyone parameter instead.
Manage access policies
You can update an access policy to change whether a feature is enabled or disabled, as well as to change who the policy applies to (everyone, a user, or a group).
For example, building on our last example, to update who the policy applies to, run the following cmdlet:
Update-VivaModuleFeaturePolicy -ModuleId VivaInsights -FeatureId Reflection -PolicyId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -GroupIds group1@contoso.com,group2@contoso.com
Just like when you create the policy, if your policy supports user controls, include the IsUserControlEnabled parameter when you change the policy.
Important
Values that you specify for the -UserIds and -GroupIds parameters or the -Everyone parameter overwrite any existing users or groups. To preserve the existing users and groups, you need to specify those existing users or groups and any additional users or groups that you want to add. Not including existing users or groups in the command effectively removes those specific users or groups from the policy. You can't update a policy for a particular user or group to include the entire tenant if a policy for the entire tenant already exists for the feature - only one tenant-wide policy is supported.
To check what features are disabled for a specific user or group, run the Get-VivaModuleFeatureEnablement cmdlet. This cmdlet returns what's called the enablement status for the user or group.
For example:
Get-VivaModuleFeatureEnablement -ModuleId VivaInsights -FeatureId Reflection -Identity user@contoso.com
Delete an access policy
Use the Remove-VivaModuleFeaturePolicy cmdlet to delete an access policy.
For example, to delete the Reflection feature access policy, start by getting the specific UID for the access policy - you can get that by running Get-VivaModuleFeaturePolicy. Then, run the following cmdlet:
Remove-VivaModuleFeaturePolicy -ModuleId VivaInsights -FeatureId Reflection -PolicyId xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Troubleshooting
If you have issues creating or using access policies for Viva app features, confirm the feature you are trying to set a policy for is listed in the feature table and is available to your tenant.
If you see the error message "Requester was not authorized to complete the request" while you're running a PowerShell cmdlet, check if you have any conditional access policy set that blocks specific IP addresses. If so, either remove your IP address from that policy or create a new policy to allowlist your IP address. Learn more about Microsoft Entra Conditional Access and Troubleshooting Conditional Access using the What If tool.
How access policies work in Viva
- When a user signs in and accesses Viva, a check is immediately made to see if there’s a policy that applies to the user.
- If the user is assigned to a policy directly or is a member of a Microsoft Entra group or Microsoft 365 group with an assigned policy, then the policy setting is applied.
- If the user isn’t assigned a policy directly or isn’t a member of a Microsoft Entra group or Microsoft 365 group that is assigned a policy, then the global default policy is applied. If there is no global default policy, the default enablement state for the feature is applied.
- If the user has multiple policies assigned to them directly or as a group, then the most restrictive policy applies. (Note that not all features include the ability for a user to opt out.) Here's the order of precedence:
- Feature is disabled.
- Feature is enabled.
- Feature is enabled, and the user can opt out.
- If 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.
- Changes to access policies take effect for the user within 24 hours, unless otherwise noted for a specific feature. Changes for Copilot in Viva Engage might take up to 48 hours.
- When you add users to 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 removes the option for users to opt out by fully enabling or disabling the feature, the user’s opt in/out preference isn't preserved and will be reset to the default state. If an admin re-enables the option allowing a user to opt out of a feature, users will need to select to opt out of the feature again.
- Quick changes to the enablement state for a feature in less than 24 hours after making the change may not result in the resetting of 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 best practices
- Policies are evaluated on a per-user basis.
- Only one policy per feature can be assigned to 'everyone'. This policy serves as the global default state for that feature in your organization.
- As new feature controls are made available in Viva to manage user and group access, they're added to Viva feature access management.
- When user identities in Microsoft Entra ID are deleted, user data is 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.