.

Author: chcomley

Diff for: docs/organizations/security/about-permissions.md

@@ -43,6 +43,7 @@ When it comes to managing permissions in Azure DevOps, there are two key groups
 - They can perform all operations for the entire collection.
 - Their responsibilities include managing settings, policies, and processes for the organization.
 - Additionally, they can create and manage all projects and extensions within the organization.
+
 **Project Administrators:**
 - Project Administrators operate at the project level.
 - They manage security groups and permissions primarily from the web portal’s Project settings.
@@ -87,7 +88,6 @@ Permissions follow a hierarchy, allowing inheritance from a parent or by overrid
 
 For example, let’s break down the permission inheritance and specificity rules and remember, explicit permissions always take precedence over inherited ones:
 
-**Inheritance:**
 - When a user’s permissions are set at a higher-level node (area-1), those permissions get inherited by all subnodes (area-1/sub-area-1) unless explicitly overridden.
 - If a permission is **not** explicitly allowed or denied for a subnode, it inherits the permission from its parent.
 - However, if a permission is explicitly set for a subnode (area-1/sub-area-1), the parent’s permission is **not** inherited, regardless of whether it's allowed or denied.
@@ -249,7 +249,7 @@ no members of the group are able to access the project, collection, or deploymen
 
 ::: moniker range="azure-devops"
 
-### Project-scoped Users group 
+### Project-scoped users group 
 
 By default, users added to an organization can view all organization and project information and settings. These settings include the list of users, the list of projects, billing details, usage data, and more, which you can access through **Organization settings**. 
 

Diff for: docs/organizations/security/about-security-identity.md

@@ -132,7 +132,7 @@ Throughout these docs, users can refer to all identities that have been added to
 
 ::: moniker-end
 
-The most effective means for managing accounts is by [adding them to security groups](about-permissions.md#security-groups-membership). 
+The most effective means for managing accounts is by [adding them to security groups](about-permissions.md#security-groups-and-membership). 
 
 > [!NOTE]  
 > The organization owner and members of the Project Collection Administrators group are granted full access to most all features and functions. 

Diff for: docs/organizations/security/includes/hidden-security-groups.md

@@ -9,20 +9,20 @@ ms.date: 10/20/2023
 ::: moniker range="azure-devops"
 
 > [!NOTE]  
-> Security groups belong to the organization level, even if they only access a specific project. Some groups may be hidden in the web portal depending on user permissions. You can find all group names in an organization with the **azure devops** CLI tool or our REST APIs. For more information, see [Add and manage security groups](../add-manage-security-groups.md).
+> Security groups belong to the organization level, even if they only access a specific project. Some groups might be hidden in the web portal depending on user permissions. You can find all group names in an organization with the **azure devops** CLI tool or our REST APIs. For more information, see [Add and manage security groups](../add-manage-security-groups.md).
 
 ::: moniker-end
 
 ::: moniker range=">= azure-devops-2020 < azure-devops"
 
 > [!NOTE]  
-> Security groups belong to the collection level, even if they only access a specific project. Some groups may be hidden in the web portal depending on user permissions. You can find all group names in an organization with the **azure devops** CLI tool or our REST APIs. For more information, see [Add and manage security groups](../add-manage-security-groups.md).
+> Security groups belong to the collection level, even if they only access a specific project. Some groups might be hidden in the web portal depending on user permissions. You can find all group names in an organization with the **azure devops** CLI tool or our REST APIs. For more information, see [Add and manage security groups](../add-manage-security-groups.md).
 
 ::: moniker-end
 
 ::: moniker range="< azure-devops-2020"
 
 > [!NOTE]  
-> Security groups belong to the collection level, even if they only access a specific project. Some groups may be hidden in the web portal depending on user permissions. However, you can discover the names of all groups in an organization using the REST APIs. For more information, see [Add and manage security groups](/rest/api/azure/devops/security/?view=azure-devops-rest-6.0&preserve-view=true).
+> Security groups belong to the collection level, even if they only access a specific project. Some groups might be hidden in the web portal depending on user permissions. However, you can discover the names of all groups in an organization using the REST APIs. For more information, see [Add and manage security groups](/rest/api/azure/devops/security/?view=azure-devops-rest-6.0&preserve-view=true).
 
 ::: moniker-end