Add latest changes from gitlab-org/gitlab@13-11-stable-eev13.11.0-rc43

32 files changed, 304 insertions, 241 deletions

diff --git a/doc/user/group/bulk_editing/index.md b/doc/user/group/bulk_editing/index.md
index 651bb7c055e..aa356bee8e3 100644
--- a/doc/user/group/bulk_editing/index.md
+++ b/doc/user/group/bulk_editing/index.md
@@ -31,7 +31,7 @@ When bulk editing issues in a group, you can edit the following attributes:
 - [Epic](../epics/index.md)
 - [Milestone](../../project/milestones/index.md)
 - [Labels](../../project/labels.md)
-- [Health status](../../project/issues/index.md#health-status)
+- [Health status](../../project/issues/managing_issues.md#health-status)
 - [Iteration](../iterations/index.md)
 
 To update multiple project issues at the same time:
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index d9167388e66..87b259df9d8 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -86,7 +86,7 @@ your cluster, which can cause deployment jobs to fail.
 
 To clear the cache:
 
-1. Navigate to your group’s **Kubernetes** page,
+1. Navigate to your group's **Kubernetes** page,
    and select your cluster.
 1. Expand the **Advanced settings** section.
 1. Click **Clear cluster cache**.
@@ -107,7 +107,7 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
 When adding more than one Kubernetes cluster to your project, you need to differentiate
 them with an environment scope. The environment scope associates clusters with
 [environments](../../../ci/environments/index.md) similar to how the
-[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables)
+[environment-specific CI/CD variables](../../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable)
 work.
 
 While evaluating which environment matches the environment scope of a
diff --git a/doc/user/group/custom_project_templates.md b/doc/user/group/custom_project_templates.md
index 813d2b8e265..016bda329b2 100644
--- a/doc/user/group/custom_project_templates.md
+++ b/doc/user/group/custom_project_templates.md
@@ -62,7 +62,7 @@ GitLab administrators can
 
 Within this section, you can configure the group where all the custom project
 templates are sourced. Every project _template_ directly under the group namespace is
-available to every signed-in user, if all enabled [project features](../project/settings/index.md#sharing-and-permissions) are set to **Everyone With Access**.
+available to every signed-in user, if all enabled [project features](../project/settings/index.md#sharing-and-permissions) except for GitLab Pages are set to **Everyone With Access**.
 
 However, private projects will be available only if the user is a member of the project.
 
diff --git a/doc/user/group/devops_adoption/img/group_devops_adoption_v13_11.png b/doc/user/group/devops_adoption/img/group_devops_adoption_v13_11.png
new file mode 100644
index 00000000000..a6ece47ba9a
--- /dev/null
+++ b/doc/user/group/devops_adoption/img/group_devops_adoption_v13_11.png
diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md
new file mode 100644
index 00000000000..920421ef9bb
--- /dev/null
+++ b/doc/user/group/devops_adoption/index.md
@@ -0,0 +1,60 @@
+---
+stage: Manage
+group: Optimize
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Group DevOps Adoption **(ULTIMATE)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321083) in GitLab 13.11.
+> - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
+> - Disabled on GitLab.com.
+> - Not recommended for production use.
+> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-group-devops-adoption).
+
+WARNING:
+This feature might not be available to you. Check the **version history** note above for details.
+
+[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321083) in GitLab 13.11 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
+
+To access Group DevOps Adoption, navigate to your group sidebar and select **Analytics > DevOps Adoption**
+
+Group DevOps Adoption shows you how individual groups and sub-groups within your organization use the following features:
+
+- Issues
+- Merge Requests
+- Approvals
+- Runners
+- Pipelines
+- Deployments
+- Scans
+
+When managing groups in the UI, you can manage your sub-groups with the **Add/Remove sub-groups**
+button, in the top right hand section of your Groups pages.
+
+DevOps Adoption allows you to:
+
+- Verify whether you are getting the return on investment that you expected from GitLab.
+- Identify specific sub-groups that are lagging in their adoption of GitLab so you can help them along in their DevOps journey.
+- Find the sub-groups that have adopted certain features and can provide guidance to other sub-groups on how to use those features.
+
+![DevOps Report](img/group_devops_adoption_v13_11.png)
+
+## Enable or disable Group DevOps Adoption **(ULTIMATE)**
+
+Group DevOps Adoption is under development and not ready for production use. It is
+deployed behind a feature flag that is **disabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can enable it.
+
+To enable it:
+
+```ruby
+Feature.enable(:group_devops_adoption)
+```
+
+To disable it:
+
+```ruby
+Feature.disable(:group_devops_adoption)
+```
diff --git a/doc/user/group/epics/img/epic_board_v13_10.png b/doc/user/group/epics/img/epic_board_v13_10.png
index 5148e6dd4ec..5a14d9288d3 100644
--- a/doc/user/group/epics/img/epic_board_v13_10.png
+++ b/doc/user/group/epics/img/epic_board_v13_10.png
diff --git a/doc/user/group/epics/img/epics_search.png b/doc/user/group/epics/img/epics_search.png
deleted file mode 100644
index 96335527468..00000000000
--- a/doc/user/group/epics/img/epics_search.png
+++ /dev/null
diff --git a/doc/user/group/epics/img/epics_search_v13_11.png b/doc/user/group/epics/img/epics_search_v13_11.png
new file mode 100644
index 00000000000..c11aca96a99
--- /dev/null
+++ b/doc/user/group/epics/img/epics_search_v13_11.png
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index 1cb024ceb01..12377b3926d 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -81,7 +81,7 @@ to:
 > - The health status of a closed issue [is hidden](https://gitlab.com/gitlab-org/gitlab/-/issues/220867) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.3 or later.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/213567) in GitLab 13.7.
 
-Report or respond to the health of issues and epics by setting a red, amber, or green [health status](../../project/issues/index.md#health-status), which then appears on your Epic tree.
+Report or respond to the health of issues and epics by setting a red, amber, or green [health status](../../project/issues/managing_issues.md#health-status), which then appears on your Epic tree.
 
 ## Multi-level child epics **(ULTIMATE)**
 
diff --git a/doc/user/group/epics/manage_epics.md b/doc/user/group/epics/manage_epics.md
index 3c5e140965a..1999e5ba214 100644
--- a/doc/user/group/epics/manage_epics.md
+++ b/doc/user/group/epics/manage_epics.md
@@ -110,15 +110,17 @@ link in the issue sidebar.
 
 > - Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.5.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/37081) to the [Premium](https://about.gitlab.com/pricing/) tier in GitLab 12.8.
+> - Searching by the user's reaction emoji [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325630) in GitLab 13.11.
 
 You can search for an epic from the list of epics using filtered search bar (similar to
-that of Issues and Merge Requests) based on following parameters:
+that of issues and merge requests) based on following parameters:
 
 - Title or description
 - Author name / username
 - Labels
+- Reaction emoji
 
-![epics search](img/epics_search.png)
+![epics search](img/epics_search_v13_11.png)
 
 To search, go to the list of epics and select the field **Search or filter results**.
 It displays a dropdown menu, from which you can add an author. You can also enter plain
@@ -321,3 +323,36 @@ To remove a child epic from a parent epic:
 
 1. Select the <kbd>x</kbd> button in the parent epic's list of epics.
 1. Select **Remove** in the **Remove epic** warning message.
+
+## Cached epic count
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299540) in GitLab 13.11.
+> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
+> - It's enabled on GitLab.com.
+> - It's recommended for production use.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-cached-epic-count).
+
+WARNING:
+This feature might not be available to you. Check the **version history** note above for details.
+
+In a group, the sidebar displays the total count of open epics and this value is cached if higher
+than 1000. The cached value is rounded to thousands (or millions) and updated every 24 hours.
+
+### Enable or disable cached epic count **(PREMIUM SELF)**
+
+Cached epic count in the left sidebar is under development but ready for production use. It is
+deployed behind a feature flag that is **enabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can disable it.
+
+To disable it:
+
+```ruby
+Feature.disable(:cached_sidebar_open_epics_count)
+```
+
+To enable it:
+
+```ruby
+Feature.enable(:cached_sidebar_open_epics_count)
+```
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 302f12273cb..e84e35607e3 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -57,6 +57,7 @@ The following resources are migrated to the target instance:
   - due date
   - created at
   - updated at
+  - iid ([Introduced in 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/326157))
 - Iterations ([Introduced in 13.10](https://gitlab.com/gitlab-org/gitlab/-/issues/292428))
   - iid
   - title
@@ -66,6 +67,10 @@ The following resources are migrated to the target instance:
   - due date
   - created at
   - updated at
+- Badges ([Introduced in 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/292431))
+  - name
+  - link URL
+  - image URL
 
 Any other items are **not** migrated.
 
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 36d292f670d..d070277beed 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -7,21 +7,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Groups **(FREE)**
 
-In GitLab, you can put related projects together in a group.
+In GitLab, you use groups to manage one or more related projects at the same time.
 
-For example, you might create a group for your company members and a subgroup for each individual team.
-You can name the group `company-team`, and the subgroups `backend-team`, `frontend-team`, and `production-team`.
+You can use groups to manage permissions for your projects. If someone has access to
+the group, they get access to all the projects in the group.
 
-Then you can:
+You can also view all of the issues and merge requests for the projects in the group,
+and view analytics that show the group's activity.
 
-- Grant members access to multiple projects at once.
-- Add to-do items for all of the group members at once.
-- View the [issues](../project/issues/index.md#issues-list) and
-  [merge requests](../project/merge_requests/reviewing_and_managing_merge_requests.md#view-merge-requests-for-all-projects-in-a-group)
-  for all projects in the group, together in a single list view.
-- [Bulk edit](../group/bulk_editing/index.md) issues, epics, and merge requests.
+You can use groups to communicate with all of the members of the group at once.
 
-You can also create [subgroups](subgroups/index.md).
+For larger organizations, you can also create [subgroups](subgroups/index.md).
 
 ## View groups
 
@@ -140,7 +136,7 @@ To remove a member from a group:
 1. From the left menu, select **Members**.
 1. Next to the member you want to remove, select **Delete**.
 1. Optional. On the **Remove member** confirmation box, select the
-  **Also unassign this user from related issues and merge requests** checkbox.
+  **Also unassign this user from linked issues and merge requests** checkbox.
 1. Select **Remove member**.
 
 ## Filter and sort members in a group
@@ -261,6 +257,9 @@ To view the activity feed in Atom format, select the
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18328) in GitLab 12.7.
 
+NOTE:
+In GitLab 13.11, you can [replace this form with a modal window](#share-a-group-modal-window).
+
 Similar to how you [share a project with a group](../project/members/share_project_with_groups.md),
 you can share a group with another group. Members get direct access
 to the shared group. This is not valid for inherited members.
@@ -277,6 +276,27 @@ To share a given group, for example, `Frontend` with another group, for example,
 
 All the members of the `Engineering` group are added to the `Frontend` group.
 
+### Share a group modal window
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247208) in GitLab 13.11.
+> - [Deployed behind a feature flag](../feature_flags.md), disabled by default.
+> - Enabled on GitLab.com.
+> - Recommended for production use.
+> - Replaces the existing form with buttons to open a modal window.
+> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](../project/members/index.md#enable-or-disable-modal-window). **(FREE SELF)**
+
+WARNING:
+This feature might not be available to you. Check the **version history** note above for details.
+
+In GitLab 13.11, you can optionally replace the sharing form with a modal window.
+To share a group after enabling this feature:
+
+1. Go to your group's page.
+1. In the left sidebar, go to **Members**, and then select **Invite a group**.
+1. Select a group, and select a **Max access level**.
+1. (Optional) Select an **Access expiration date**.
+1. Select **Invite**.
+
 ## Manage group memberships via LDAP **(PREMIUM SELF)**
 
 Group syncing allows LDAP groups to be mapped to GitLab groups. This provides more control over per-group user management. To configure group syncing, edit the `group_base` **DN** (`'OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org'`). This **OU** contains all groups that will be associated with GitLab groups.
@@ -322,25 +342,6 @@ LDAP user permissions can be manually overridden by an administrator. To overrid
 
 Now you can edit the user's permissions from the **Members** page.
 
-## Group wikis **(PREMIUM)**
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13195) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.5.
-
-Group wikis work the same way as [project wikis](../project/wiki/index.md).
-
-Group wikis can be edited by members with [Developer permissions](../../user/permissions.md#group-members-permissions)
-and above.
-
-You can move group wiki repositories by using the [Group repository storage moves API](../../api/group_repository_storage_moves.md).
-
-There are a few limitations compared to project wikis:
-
-- Git LFS is not supported.
-- Group wikis are not included in global search.
-- Changes to group wikis don't show up in the group's activity feed.
-
-For updates, follow [the epic that tracks feature parity with project wikis](https://gitlab.com/groups/gitlab-org/-/epics/2782).
-
 ## Transfer a group
 
 You can transfer groups in the following ways:
@@ -387,16 +388,10 @@ because the project cannot be moved.
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43290) in GitLab 13.6.
 
-By default, when you create a new project in GitLab, the initial branch is called `master`.
-For groups, a group owner can customize the initial branch name to something
-else. This way, every new project created under that group from then on starts from the custom branch name rather than `master`.
-
-To use a custom name for the initial branch:
-
-1. Go to the group's **Settings > Repository** page.
-1. Expand the **Default initial branch name** section.
-1. Change the default initial branch to a custom name of your choice.
-1. Select **Save changes**.
+When you create a new project in GitLab, a default branch is created with the
+first push. The group owner can
+[customize the initial branch](../project/repository/branches/default.md#group-level-custom-initial-branch-name)
+for the group's projects to meet your group's needs.
 
 ## Remove a group
 
@@ -434,7 +429,7 @@ To prevent a project from being shared with other groups:
 
 1. Go to the group's **Settings > General** page.
 1. Expand the **Permissions, LFS, 2FA** section.
-1. Select **Prevent sharing a project within <group_name> with other groups**.
+1. Select **Prevent sharing a project within `<group_name>` with other groups**.
 1. Select **Save changes**.
 
 ## Prevent members from being added to a group **(PREMIUM)**
@@ -460,33 +455,36 @@ API requests to add a new user to a project are not possible.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1985) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.0.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/215410) to [GitLab Premium](https://about.gitlab.com/pricing/) in 13.1.
 
-NOTE:
-IP access restrictions are not functioning as expected on GitLab.com. If enabled,
-users cannot perform Git operations through SSH, or access projects in the UI.
-For more information, [see this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271673).
-
 To ensure only people from your organization can access particular
-resources, you can restrict access to groups by IP address. This setting applies to all subgroups,
-projects, issues, and so on. 
-
-IP access restrictions can be configured at the group level only.
+resources, you can restrict access to groups by IP address. This group-level setting
+applies to:
 
-This restriction applies to:
-
-- The GitLab UI.
+- The GitLab UI, including subgroups, projects, and issues.
 - [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), the API.
-- [In GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/32113), Git actions via SSH.
 
-Administrators and group owners are able to access the group regardless of the IP restriction.
+You should consider these security implications before configuring IP address restrictions:
+
+- **SSH requests**: While you can restrict HTTP traffic on GitLab.com with IP address restrictions,
+  they cause SSH requests, including Git operations over SSH, to fail. For more information,
+  read [issue 271673](https://gitlab.com/gitlab-org/gitlab/-/issues/271673).
+- **Administrators and group owners**: Users with these permission levels can always
+  access the group settings, regardless of IP restriction, but they cannot access projects
+  belonging to the group when accessing from a disallowed IP address.
+- **GitLab API and runner activities**: Only the [Groups](../../api/groups.md)
+  and [Projects](../../api/projects.md) APIs are protected by IP address restrictions.
+  When you register a runner, it is not bound by the IP restrictions. When the runner
+  requests a new job or an update to a job's state, it is also not bound by
+  the IP restrictions. But when the running CI/CD job sends Git requests from a
+  restricted IP address, the IP restriction prevents code from being cloned.
 
 To restrict group access by IP address:
 
-1. Go to the group’s **Settings > General** page.
+1. Go to the group's **Settings > General** page.
 1. Expand the **Permissions, LFS, 2FA** section.
 1. In the **Allow access to the following IP addresses** field, enter IP address ranges in CIDR notation.
 1. Select **Save changes**.
 
-![Domain restriction by IP address](img/restrict-by-ip.gif)
+   ![Domain restriction by IP address](img/restrict-by-ip.gif)
 
 ## Restrict group access by domain **(PREMIUM)**
 
@@ -638,6 +636,7 @@ The group's new subgroups have push rules set for them based on either:
 
 ## Related topics
 
+- [Group wikis](../project/wiki/index.md)
 - [Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size). **(FREE SELF)**
 - [Repositories analytics](repositories_analytics/index.md): View overall activity of all projects with code coverage. **(PREMIUM)**
 - [Contribution analytics](contribution_analytics/index.md): View the contributions (pushes, merge requests,
@@ -662,3 +661,15 @@ The group's new subgroups have push rules set for them based on either:
 - [Lock the sharing with group feature](#prevent-a-project-from-being-shared-with-groups).
 - [Enforce two-factor authentication (2FA)](../../security/two_factor_authentication.md#enforcing-2fa-for-all-users-in-a-group): Enforce 2FA
   for all group members.
+
+## Troubleshooting
+
+### Verify if access is blocked by IP restriction
+
+If a user sees a 404 when they would normally expect access, and the problem is limited to a specific group, search the `auth.log` rails log for one or more of the following:
+
+- `json.message`: `'Attempting to access IP restricted group'`
+- `json.allowed`: `false`
+
+In viewing the log entries, compare the `remote.ip` with the list of
+[allowed IPs](#restrict-group-access-by-ip-address) for the group.
diff --git a/doc/user/group/insights/img/insights_example_stacked_bar_chart.png b/doc/user/group/insights/img/insights_example_stacked_bar_chart.png
deleted file mode 100644
index 0e338b99e4c..00000000000
--- a/doc/user/group/insights/img/insights_example_stacked_bar_chart.png
+++ /dev/null
diff --git a/doc/user/group/insights/img/insights_example_stacked_bar_chart_v13_11.png b/doc/user/group/insights/img/insights_example_stacked_bar_chart_v13_11.png
new file mode 100644
index 00000000000..1ef49191a13
--- /dev/null
+++ b/doc/user/group/insights/img/insights_example_stacked_bar_chart_v13_11.png
diff --git a/doc/user/group/insights/img/insights_sidebar_link_v12_8.png b/doc/user/group/insights/img/insights_sidebar_link_v12_8.png
deleted file mode 100644
index 9a6d6bae766..00000000000
--- a/doc/user/group/insights/img/insights_sidebar_link_v12_8.png
+++ /dev/null
diff --git a/doc/user/group/insights/index.md b/doc/user/group/insights/index.md
index b559e6806e9..4975b27a66d 100644
--- a/doc/user/group/insights/index.md
+++ b/doc/user/group/insights/index.md
@@ -13,14 +13,12 @@ Configure the Insights that matter for your groups to explore data such as
 triage hygiene, issues created/closed per a given period, average time for merge
 requests to be merged and much more.
 
-![Insights example stacked bar chart](img/insights_example_stacked_bar_chart.png)
+![Insights example stacked bar chart](img/insights_example_stacked_bar_chart_v13_11.png)
 
 ## View your group's Insights
 
 You can access your group's Insights by clicking the **Analytics > Insights**
-link in the left sidebar:
-
-![Insights sidebar link](img/insights_sidebar_link_v12_8.png)
+link in the left sidebar.
 
 ## Configure your Insights
 
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index 8e125a0cc6e..38d209f04ca 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -8,11 +8,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Iterations **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214713) in GitLab 13.1.
-> - It was deployed behind a feature flag, disabled by default.
-> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) on GitLab 13.2.
-> - It's enabled on GitLab.com.
-> - It's able to be enabled or disabled per-group.
-> - It's recommended for production use.
+> - Deployed behind a feature flag, disabled by default.
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) in GitLab 13.2.
+> - Enabled on GitLab.com.
+> - Able to be enabled or disabled per-group.
+> - Recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-iterations). **(PREMIUM ONLY)**
 > - Moved to GitLab Premium in 13.9.
 
diff --git a/doc/user/group/repositories_analytics/index.md b/doc/user/group/repositories_analytics/index.md
index 42522723047..ef47ceadd88 100644
--- a/doc/user/group/repositories_analytics/index.md
+++ b/doc/user/group/repositories_analytics/index.md
@@ -69,7 +69,7 @@ For each day that a coverage report was generated by a job in a project's pipeli
 If the project's code coverage was calculated more than once in a day, we will take the last value from that day.
 
 NOTE:
-[In GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/270102), group code coverage data is taken from the configured [default branch](../../project/repository/branches/index.md#default-branch). In earlier versions, it is taken from the `master` branch.
+[In GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/270102), group code coverage data is taken from the configured [default branch](../../project/repository/branches/default.md). In earlier versions, it is taken from the `master` branch.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/group/roadmap/img/roadmap_filters_v13_11.png b/doc/user/group/roadmap/img/roadmap_filters_v13_11.png
new file mode 100644
index 00000000000..d2a76b4edce
--- /dev/null
+++ b/doc/user/group/roadmap/img/roadmap_filters_v13_11.png
diff --git a/doc/user/group/roadmap/img/roadmap_filters_v13_8.png b/doc/user/group/roadmap/img/roadmap_filters_v13_8.png
deleted file mode 100644
index d826909b022..00000000000
--- a/doc/user/group/roadmap/img/roadmap_filters_v13_8.png
+++ /dev/null
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index 9b3ae75b39c..88d43715c58 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -42,6 +42,7 @@ toggle the list of the milestone bars.
 > - Filtering roadmaps by milestone is recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-filtering-roadmaps-by-milestone). **(PREMIUM SELF)**
 > - Filtering by epic confidentiality [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218624) in GitLab 13.9.
+> - Filtering by epic [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218623) in GitLab 13.11.
 
 WARNING:
 Filtering roadmaps by milestone might not be available to you. Check the **version history** note above for details.
@@ -69,8 +70,10 @@ You can also filter epics in the Roadmap view by the epics':
 - Label
 - Milestone
 - Confidentiality
+- Epic
+- Your Reaction
 
-![roadmap date range in weeks](img/roadmap_filters_v13_8.png)
+![roadmap date range in weeks](img/roadmap_filters_v13_11.png)
 
 Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-epics).
 
diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index 9f2cafd456b..a9b1901bc8c 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -84,6 +84,16 @@ To access the Credentials inventory of a group, navigate to **{shield}** **Secur
 
 This feature is similar to the [Credentials inventory for self-managed instances](../../admin_area/credentials_inventory.md).
 
+### Revoke a group-managed account's personal access token
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214811) in GitLab 13.5.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/267184) in GitLab 13.10.
+
+Group owners can revoke the personal access tokens of accounts in their group. To do so, select
+the Personal Access Tokens tab, and select Revoke.
+
+When a personal access token is revoked, the group-managed account user is notified by email.
+
 ## Limiting lifetime of personal access tokens of users in Group-managed accounts **(ULTIMATE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118893) in GitLab 12.10.
diff --git a/doc/user/group/saml_sso/img/scim_name_identifier_mapping.png b/doc/user/group/saml_sso/img/scim_name_identifier_mapping.png
deleted file mode 100644
index f9c63970f16..00000000000
--- a/doc/user/group/saml_sso/img/scim_name_identifier_mapping.png
+++ /dev/null
diff --git a/doc/user/group/saml_sso/img/scim_provisioning_status.png b/doc/user/group/saml_sso/img/scim_provisioning_status.png
deleted file mode 100644
index 41466ec9276..00000000000
--- a/doc/user/group/saml_sso/img/scim_provisioning_status.png
+++ /dev/null
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 004efe7b244..f2f28046443 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -10,24 +10,28 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > Introduced in GitLab 11.0.
 
 This page describes SAML for Groups. For instance-wide SAML on self-managed GitLab instances, see [SAML OmniAuth Provider](../../../integration/saml.md).
+[View the differences between SaaS and Self-Managed Authentication and Authorization Options](../../../administration/auth/README.md#saas-vs-self-managed-comparison).
 
 SAML on GitLab.com allows users to sign in through their SAML identity provider. If the user is not already a member, the sign-in process automatically adds the user to the appropriate group.
 
-If you follow our guidance to automate user provisioning using [SCIM](scim_setup.md) or [group-managed accounts](group_managed_accounts.md), you do not need to create such accounts manually.
-
-User synchronization of SAML SSO groups is supported through [SCIM](scim_setup.md). SCIM supports adding and removing users from the GitLab group.
+User synchronization of SAML SSO groups is supported through [SCIM](scim_setup.md). SCIM supports adding and removing users from the GitLab group automatically.
 For example, if you remove a user from the SCIM app, SCIM removes that same user from the GitLab group.
 
 SAML SSO is only configurable at the top-level group.
 
-## Configuring your Identity Provider
+If required, you can find [a glossary of common terms](../../../integration/saml.md#glossary-of-common-terms).
 
-1. Navigate to the group and select **Settings > SAML SSO**.
-1. Configure your SAML server using the **Assertion consumer service URL**, **Identifier**, and **GitLab single sign-on URL**. Alternatively GitLab provides [metadata XML configuration](#metadata-configuration). See [specific identity provider documentation](#providers) for more details.
+## Configuring your identity provider
+
+1. Navigate to the GitLab group and select **Settings > SAML SSO**.
+1. Configure your SAML identity provider using the **Assertion consumer service URL**, **Identifier**, and **GitLab single sign-on URL**.
+   Alternatively GitLab provides [metadata XML configuration](#metadata-configuration).
+   See [specific identity provider documentation](#providers) for more details.
 1. Configure the SAML response to include a NameID that uniquely identifies each user.
 1. Configure [required assertions](#assertions) at minimum containing
    the user's email address.
-1. While the default is enabled for most SAML providers, please ensure the app is set to have [Service Provider](#glossary) initiated calls in order to link existing GitLab accounts.
+1. While the default is enabled for most SAML providers, please ensure the app is set to have service provider
+   initiated calls in order to link existing GitLab accounts.
 1. Once the identity provider is set up, move on to [configuring GitLab](#configuring-gitlab).
 
 ![Issuer and callback for configuring SAML identity provider with GitLab.com](img/group_saml_configuration_information.png)
@@ -57,30 +61,25 @@ We recommend setting the NameID format to `Persistent` unless using a field (suc
 ### Assertions
 
 For users to be created with the right information with the improved [user access and management](#user-access-and-management),
-the following user details need to be passed to GitLab as SAML assertions.
+the user details need to be passed to GitLab as SAML assertions.
 
-| Field           | Supported keys |
-|-----------------|----------------|
-| Email (required)| `email`, `mail` |
-| Username        | `username`, `nickname` |
-| Full Name       | `name` |
-| First Name      | `first_name`, `firstname`, `firstName` |
-| Last Name       | `last_name`, `lastname`, `lastName` |
+At a minimum, the user's email address *must* be specified as an assertion named `email` or `mail`.
+See [the assertions list](../../../integration/saml.md#assertions) for other available claims.
 
 ### Metadata configuration
 
-GitLab provides metadata XML that can be used to configure your Identity Provider.
+GitLab provides metadata XML that can be used to configure your identity provider.
 
 1. Navigate to the group and select **Settings > SAML SSO**.
 1. Copy the provided **GitLab metadata URL**.
-1. Follow your Identity Provider's documentation and paste the metadata URL when it's requested.
+1. Follow your identity provider's documentation and paste the metadata URL when it's requested.
 
 ## Configuring GitLab
 
 After you set up your identity provider to work with GitLab, you must configure GitLab to use it for authentication:
 
 1. Navigate to the group's **Settings > SAML SSO**.
-1. Find the SSO URL from your Identity Provider and enter it the **Identity provider single sign-on URL** field.
+1. Find the SSO URL from your identity provider and enter it the **Identity provider single sign-on URL** field.
 1. Find and enter the fingerprint for the SAML token signing certificate in the **Certificate** field.
 1. Select the access level to be applied to newly added users in the **Default membership role** field. The default access level is 'Guest'.
 1. Select the **Enable SAML authentication for this group** toggle switch.
@@ -89,7 +88,7 @@ After you set up your identity provider to work with GitLab, you must configure
 ![Group SAML Settings for GitLab.com](img/group_saml_settings_v13_3.png)
 
 NOTE:
-Please note that the certificate [fingerprint algorithm](#additional-providers-and-setup-options) must be in SHA1. When configuring the identity provider, use a secure signature algorithm.
+Please note that the certificate [fingerprint algorithm](../../../integration/saml.md#notes-on-configuring-your-identity-provider) must be in SHA1. When configuring the identity provider, use a secure signature algorithm.
 
 ### SSO enforcement
 
@@ -97,32 +96,42 @@ Please note that the certificate [fingerprint algorithm](#additional-providers-a
 - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI.
 - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience.
 - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO.
+- [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9152) in GitLab 13.11 with enforcing open SSO session to use Git if this setting is switched on.
 
-With this option enabled, users must go through your group's GitLab single sign-on URL. They may also be added via SCIM, if configured. Users can't be added manually, and may only access project/group resources via the UI by signing in through the SSO URL.
+With this option enabled, users (except owners) must go through your group's GitLab single sign-on URL if they wish to access group resources through the UI. Users can't be manually added as members.
+
+SSO enforcement does not affect sign in or access to any resources outside of the group. Users can view which groups and projects they are a member of without SSO sign in.
 
 However, users are not prompted to sign in through SSO on each visit. GitLab checks whether a user
 has authenticated through SSO. If it's been more than 1 day since the last sign-in, GitLab
 prompts the user to sign in again through SSO.
 
-We intend to add a similar SSO requirement for [Git and API activity](https://gitlab.com/gitlab-org/gitlab/-/issues/9152).
+We intend to add a similar SSO requirement for [API activity](https://gitlab.com/gitlab-org/gitlab/-/issues/9152).
 
-When SSO enforcement is enabled for a group, users can't share a project in the group outside the top-level group, even if the project is forked.
+SSO has the following effects when enabled:
 
-## Providers
+- For groups, users can't share a project in the group outside the top-level group,
+  even if the project is forked.
+- For a Git activity, users must be signed-in through SSO before they can push to or
+  pull from a GitLab repository.
+<!-- Add bullet for API activity when https://gitlab.com/gitlab-org/gitlab/-/issues/9152 is complete -->
 
-NOTE:
-GitLab is unable to provide full support for integrating identity providers that are not listed here.
+## Providers
 
-| Provider | Documentation |
-|----------|---------------|
-| Azure | [Configuring single sign-on to applications](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/view-applications-portal) |
-| Okta | [Setting up a SAML application in Okta](https://developer.okta.com/docs/guides/build-sso-integration/saml2/overview/) |
-| OneLogin | [Use the OneLogin SAML Test Connector](https://onelogin.service-now.com/support?id=kb_article&sys_id=93f95543db109700d5505eea4b96198f) |
+The SAML standard means that a wide range of identity providers will work with GitLab. Your identity provider may have relevant documentation. It may be generic SAML documentation, or specifically targeted for GitLab.
 
 When [configuring your identity provider](#configuring-your-identity-provider), please consider the notes below for specific providers to help avoid common issues and as a guide for terminology used.
 
+For providers not listed below, you can refer to the [instance SAML notes on configuring an identity provider](../../../integration/saml.md#notes-on-configuring-your-identity-provider)
+for additional guidance on information your identity provider may require.
+
+Please note that GitLab provides the following for guidance only.
+If you have any questions on configuring the SAML app, please contact your provider's support.
+
 ### Azure setup notes
 
+Please follow the Azure documentation on [configuring single sign-on to applications](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/view-applications-portal) with the notes below for consideration.
+
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For a demo of the Azure SAML setup including SCIM, see [SCIM Provisioning on Azure Using SAML SSO for Groups Demo](https://youtu.be/24-ZxmTeEBU). Please note that the video is outdated in regard to
 objectID mapping and the [SCIM documentation should be followed](scim_setup.md#azure-configuration-steps).
@@ -142,6 +151,8 @@ We recommend:
 
 ### Okta setup notes
 
+Please follow the Okta documentation on [setting up a SAML application in Okta](https://developer.okta.com/docs/guides/build-sso-integration/saml2/overview/) with the notes below for consideration.
+
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For a demo of the Okta SAML setup including SCIM, see [Demo: Okta Group SAML & SCIM setup](https://youtu.be/0ES9HsZq0AQ).
 
@@ -165,7 +176,7 @@ OneLogin supports their own [GitLab (SaaS)](https://onelogin.service-now.com/sup
 application.
 
 If you decide to use the OneLogin generic [SAML Test Connector (Advanced)](https://onelogin.service-now.com/support?id=kb_article&sys_id=b2c19353dbde7b8024c780c74b9619fb&kb_category=93e869b0db185340d5505eea4b961934),
-we recommend the following settings:
+we recommend the ["Use the OneLogin SAML Test Connector" documentation](https://onelogin.service-now.com/support?id=kb_article&sys_id=93f95543db109700d5505eea4b96198f) with the following settings:
 
 | GitLab Setting | OneLogin Field |
 |--------------|----------------|
@@ -178,40 +189,6 @@ we recommend the following settings:
 
 Recommended `NameID` value: `OneLogin ID`.
 
-### Additional providers and setup options
-
-The SAML standard means that a wide range of identity providers will work with GitLab. Unfortunately we have not verified connections with all SAML providers.
-For more information, see our [discussion on providers](#providers).
-
-Your identity provider may have relevant documentation. It may be generic SAML documentation, or specifically targeted for GitLab. Examples:
-
-- [ADFS (Active Directory Federation Services)](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust)
-- [Auth0](https://auth0.com/docs/protocols/saml-protocol/configure-auth0-as-saml-identity-provider)
-- [Google Workspace](https://support.google.com/a/answer/6087519?hl=en)
-- [JumpCloud](https://support.jumpcloud.com/support/s/article/single-sign-on-sso-with-gitlab-2019-08-21-10-36-47)
-- [PingOne by Ping Identity](https://docs.pingidentity.com/bundle/pingone/page/xsh1564020480660-1.html)
-
-Your Identity Provider may require additional configuration, such as the following:
-
-| Field | Value | Notes |
-|-------|-------|-------|
-| SAML Profile | Web browser SSO profile | GitLab uses SAML to sign users in via their browser. We don't make requests direct to the Identity Provider. |
-| SAML Request Binding | HTTP Redirect | GitLab (the service provider) redirects users to your Identity Provider with a base64 encoded `SAMLRequest` HTTP parameter. |
-| SAML Response Binding | HTTP POST | Your Identity Provider responds to users with an HTTP form including the `SAMLResponse`, which a user's browser submits back to GitLab. |
-| Sign SAML Response | Yes | We require this to prevent tampering. |
-| X.509 Certificate in response | Yes | This is used to sign the response and checked against the provided fingerprint. |
-| Fingerprint Algorithm | SHA-1  | We need a SHA-1 hash of the certificate used to sign the SAML Response. |
-| Signature Algorithm | SHA-1/SHA-256/SHA-384/SHA-512 | Also known as the Digest Method, this can be specified in the SAML response. It determines how a response is signed. |
-| Encrypt SAML Assertion | No | TLS is used between your Identity Provider, the user's browser, and GitLab. |
-| Sign SAML Assertion | Optional | We don't require Assertions to be signed. We validate their integrity by requiring the whole response to be signed. |
-| Check SAML Request Signature | No | GitLab does not sign SAML requests, but does check the signature on the SAML response. |
-| Default RelayState | Optional | The URL users should end up on after signing in via a button on your Identity Provider. |
-| NameID Format | `Persistent` | See [details above](#nameid-format). |
-| Additional URLs | | You may need to use the `Identifier` or `Assertion consumer service URL` in other fields on some providers. |
-| Single Sign Out URL | | Not supported |
-
-If the information you need isn't listed above you may wish to check our [troubleshooting docs below](#i-need-additional-information-to-configure-my-identity-provider).
-
 ## User access and management
 
 > [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/268142) in GitLab 13.7.
@@ -231,9 +208,9 @@ When a user tries to sign in with Group SSO, GitLab attempts to find or create a
 To link SAML to your existing GitLab.com account:
 
 1. Sign in to your GitLab.com account.
-1. Locate and visit the **GitLab single sign-on URL** for the group you're signing in to. A group owner can find this on the group's **Settings > SAML SSO** page. If the sign-in URL is configured, users can connect to the GitLab app from the Identity Provider.
+1. Locate and visit the **GitLab single sign-on URL** for the group you're signing in to. A group owner can find this on the group's **Settings > SAML SSO** page. If the sign-in URL is configured, users can connect to the GitLab app from the identity provider.
 1. Select **Authorize**.
-1. Enter your credentials on the Identity Provider if prompted.
+1. Enter your credentials on the identity provider if prompted.
 1. You are then redirected back to GitLab.com and should now have access to the group. In the future, you can use SAML to sign in to GitLab.com.
 
 On subsequent visits, you should be able to go [sign in to GitLab.com with SAML](#signing-in-to-gitlabcom-with-saml) or by visiting links directly. If the **enforce SSO** option is turned on, you are then redirected to sign in through the identity provider.
@@ -369,18 +346,6 @@ Users who are not members of any mapped SAML groups are removed from the GitLab
 You can prevent accidental member removal. For example, if you have a SAML group link for `Owner` level access
 in a top-level group, you should also set up a group link for all other members.
 
-## Glossary
-
-| Term | Description |
-|------|-------------|
-| Identity Provider | The service which manages your user identities such as ADFS, Okta, OneLogin, or Ping Identity. |
-| Service Provider | SAML considers GitLab to be a service provider. |
-| Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
-| SSO | Single Sign On. |
-| Assertion consumer service URL | The callback on GitLab where users are redirected after successfully authenticating with the identity provider. |
-| Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
-| Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
-
 ## Passwords for users created via SAML SSO for Groups
 
 The [Generated passwords for users created through integrated authentication](../../../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via SAML SSO for Groups.
@@ -412,7 +377,7 @@ In troubleshooting the Group SAML setup, any authenticated user can use the API
 
 Similarly, group members of a role with the appropriate permissions can make use of the [members API](../../../api/members.md) to view group SAML identity information for members of the group.
 
-This can then be compared to the [NameID](#nameid) being sent by the Identity Provider by decoding the message with a [SAML debugging tool](#saml-debugging-tools). We require that these match in order to identify users.
+This can then be compared to the [NameID](#nameid) being sent by the identity provider by decoding the message with a [SAML debugging tool](#saml-debugging-tools). We require that these match in order to identify users.
 
 ### Users receive a 404
 
@@ -432,7 +397,7 @@ Here are possible causes and solutions:
 
 | Cause                                                                                          | Solution                                                                                                                                                                    |
 |------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| You've tried to link multiple SAML identities to the same user, for a given Identity Provider. | Change the identity that you sign in with. To do so, [unlink the previous SAML identity](#unlinking-accounts) from this GitLab account before attempting to sign in again. |
+| You've tried to link multiple SAML identities to the same user, for a given identity provider. | Change the identity that you sign in with. To do so, [unlink the previous SAML identity](#unlinking-accounts) from this GitLab account before attempting to sign in again. |
 
 ### Message: "SAML authentication failed: Email has already been taken"
 
@@ -442,7 +407,7 @@ Here are possible causes and solutions:
 
 ### Message: "SAML authentication failed: Extern UID has already been taken, User has already been taken"
 
-Getting both of these errors at the same time suggests the NameID capitalization provided by the Identity Provider didn't exactly match the previous value for that user.
+Getting both of these errors at the same time suggests the NameID capitalization provided by the identity provider didn't exactly match the previous value for that user.
 
 This can be prevented by configuring the [NameID](#nameid) to return a consistent value. Fixing this for an individual user involves [unlinking SAML in the GitLab account](#unlinking-accounts), although this will cause group membership and to-dos to be lost.
 
@@ -452,8 +417,8 @@ Ensure that the user who is trying to link their GitLab account has been added a
 
 Alternatively, the SAML response may be missing the `InResponseTo` attribute in the
 `samlp:Response` tag, which is [expected by the SAML gem](https://github.com/onelogin/ruby-saml/blob/9f710c5028b069bfab4b9e2b66891e0549765af5/lib/onelogin/ruby-saml/response.rb#L307-L316).
-The [Identity Provider](#glossary) administrator should ensure that the login is
-initiated by the Service Provider (typically GitLab) and not the Identity Provider.
+The identity provider administrator should ensure that the login is
+initiated by the service provider and not the identity provider.
 
 ### Stuck in a login "loop"
 
@@ -469,13 +434,15 @@ Alternatively, when users need to [link SAML to their existing GitLab.com accoun
 
 ### I need to change my SAML app
 
-Users will need to [unlink the current SAML identity](#unlinking-accounts) and [link their identity](#user-access-and-management) to the new SAML app.
+If the NameID is identical in both SAML apps, then no change is required.
+
+Otherwise, to change the SAML app used for sign in, users need to [unlink the current SAML identity](#unlinking-accounts) and then [link their identity](#user-access-and-management) to the new SAML app.
 
 ### I need additional information to configure my identity provider
 
 Many SAML terms can vary between providers. It is possible that the information you are looking for is listed under another name.
 
-For more information, start with your Identity Provider's documentation. Look for their options and examples to see how they configure SAML. This can provide hints on what you'll need to configure GitLab to work with these providers.
+For more information, start with your identity provider's documentation. Look for their options and examples to see how they configure SAML. This can provide hints on what you'll need to configure GitLab to work with these providers.
 
 It can also help to look at our [more detailed docs for self-managed GitLab](../../../integration/saml.md).
 SAML configuration for GitLab.com is mostly the same as for self-managed instances.
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 35374812b37..7bf54aea60e 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -20,7 +20,6 @@ The GitLab [SCIM API](../../../api/scim.md) implements part of [the RFC7644 prot
 The following actions are available:
 
 - Create users
-- Update users (Azure only)
 - Deactivate users
 
 The following identity providers are supported:
@@ -51,19 +50,13 @@ Once [Group Single Sign-On](index.md) has been configured, we can:
 
 The SAML application that was created during [Single sign-on](index.md) setup for [Azure](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/view-applications-portal) now needs to be set up for SCIM.
 
-1. Check the configuration for your GitLab SAML app and ensure that **Name identifier value** (NameID) points to `user.objectid` or another unique identifier. This matches the `extern_uid` used on GitLab.
-
-   ![Name identifier value mapping](img/scim_name_identifier_mapping.png)
-
 1. Set up automatic provisioning and administrative credentials by following the
-   [Provisioning users and groups to applications that support SCIM](https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#provisioning-users-and-groups-to-applications-that-support-scim) section in Azure's SCIM setup documentation.
+   [Azure's SCIM setup documentation](https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#provisioning-users-and-groups-to-applications-that-support-scim).
 
 During this configuration, note the following:
 
 - The `Tenant URL` and `secret token` are the ones retrieved in the
   [previous step](#gitlab-configuration).
-- Should there be any problems with the availability of GitLab or similar
-  errors, the notification email set gets those.
 - It is recommended to set a notification email and check the **Send an email notification when a failure occurs** checkbox.
 - For mappings, we will only leave `Synchronize Azure Active Directory Users to AppName` enabled.
 
@@ -71,42 +64,30 @@ You can then test the connection by clicking on **Test Connection**. If the conn
 
 #### Configure attribute mapping
 
-1. Click on `Synchronize Azure Active Directory Users to AppName` to configure the attribute mapping.
-1. Click **Delete** next to the `mail` mapping.
-1. Map `userPrincipalName` to `emails[type eq "work"].value` and change its **Matching precedence** to `2`.
-1. Map `mailNickname` to `userName`.
-1. Determine how GitLab uniquely identifies users.
-
-    - Use `objectId` unless users already have SAML linked for your group.
-    - If you already have users with SAML linked then use the `Name ID` value from the [SAML configuration](#azure). Using a different value may cause duplicate users and prevent users from accessing the GitLab group.
-
-1. Create a new mapping:
-   1. Click **Add New Mapping**.
-   1. Set:
-      - **Source attribute** to the unique identifier determined above, typically `objectId`.
-      - **Target attribute** to `externalId`.
-      - **Match objects using this attribute** to `Yes`.
-      - **Matching precedence** to `1`.
+Follow [Azure documentation to configure the attribute mapping](https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes).
 
-1. Click the `userPrincipalName` mapping and change **Match objects using this attribute** to `No`.
+The following table below provides an attribute mapping known to work with GitLab. If
+your SAML configuration differs from [the recommended SAML settings](index.md#azure-setup-notes),
+modify the corresponding `customappsso` settings accordingly. If a mapping is not listed in the
+table, use the Azure defaults.
 
-1. Save your changes. For reference, you can view [an example configuration in the troubleshooting reference](../../../administration/troubleshooting/group_saml_scim.md#azure-active-directory).
+| Azure Active Directory Attribute | customappsso Attribute | Matching precedence |
+| -------------------------------- | ---------------------- | -------------------- |
+| `objectId`                       | `externalId`           | 1 |
+| `userPrincipalName`              | `emails[type eq "work"].value` |  |
+| `mailNickname`                   | `userName`             |  |
 
-   NOTE:
-   If you used a unique identifier **other than** `objectId`, be sure to map it to `externalId`.
+For guidance, you can view [an example configuration in the troubleshooting reference](../../../administration/troubleshooting/group_saml_scim.md#azure-active-directory).
 
 1. Below the mapping list click on **Show advanced options > Edit attribute list for AppName**.
-
 1. Ensure the `id` is the primary and required field, and `externalId` is also required.
 
    NOTE:
    `username` should neither be primary nor required as we don't support
    that field on GitLab SCIM yet.
 
-1. Save all the screens and, in the **Provisioning** step, set
-   the `Provisioning Status` to `On`.
-
-   ![Provisioning status toggle switch](img/scim_provisioning_status.png)
+1. Save all changes.
+1. In the **Provisioning** step, set the `Provisioning Status` to `On`.
 
    NOTE:
    You can control what is actually synced by selecting the `Scope`. For example,
@@ -168,6 +149,10 @@ As the app is developed by OneLogin, please reach out to OneLogin if you encount
 
 ## User access and linking setup
 
+During the synchronization process, all of your users get GitLab accounts, welcoming them
+to their respective groups, with an invitation email. When implementing SCIM provisioning,
+you may want to warn your security-conscious employees about this email.
+
 The following diagram is a general outline on what happens when you add users to your SCIM app:
 
 ```mermaid
@@ -202,10 +187,6 @@ Upon the next sync, the user is deprovisioned, which means that the user is remo
 NOTE:
 Deprovisioning does not delete the user account.
 
-During the synchronization process, all of your users get GitLab accounts, welcoming them
-to their respective groups, with an invitation email. When implementing SCIM provisioning,
-you may want to warn your security-conscious employees about this email.
-
 ```mermaid
 graph TD
   A[Remove User from SCIM app] -->|IdP sends request to GitLab| B(GitLab: Is the user part of the group?)
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 16430b49549..df0d297a82a 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -117,7 +117,7 @@ Follow the same process to create any subsequent groups.
 ## Membership
 
 When you add a member to a group, that member is also added to all subgroups.
-Permission level is inherited from the group’s parent. This model allows access to
+Permission level is inherited from the group's parent. This model allows access to
 subgroups if you have membership in one of its parents.
 
 Jobs for pipelines in subgroups can use [runners](../../../ci/runners/README.md) registered to the parent group(s).
diff --git a/doc/user/group/value_stream_analytics/img/extended_value_stream_form_v13_10.png b/doc/user/group/value_stream_analytics/img/extended_value_stream_form_v13_10.png
index 26508787177..e2752ad1157 100644
--- a/doc/user/group/value_stream_analytics/img/extended_value_stream_form_v13_10.png
+++ b/doc/user/group/value_stream_analytics/img/extended_value_stream_form_v13_10.png
diff --git a/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png b/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png
index 77f4a26b880..9345c4023de 100644
--- a/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png
+++ b/doc/user/group/value_stream_analytics/img/vsa_custom_stage_v13_10.png
diff --git a/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png b/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png
index 1adb114b025..a29689a2c18 100644
--- a/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png
+++ b/doc/user/group/value_stream_analytics/img/vsa_default_stage_v13_10.png
diff --git a/doc/user/group/value_stream_analytics/img/vsa_path_nav_v13_11.png b/doc/user/group/value_stream_analytics/img/vsa_path_nav_v13_11.png
new file mode 100644
index 00000000000..5dd79d06463
--- /dev/null
+++ b/doc/user/group/value_stream_analytics/img/vsa_path_nav_v13_11.png
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index 52cf51d85a4..6a512d78696 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -76,20 +76,15 @@ GitLab provides the ability to filter analytics based on a date range. To filter
 The "Time" metrics near the top of the page are measured as follows:
 
 - **Lead time**: median time from issue created to issue closed.
-- **Cycle time**: median time from first commit to issue closed.
-
-A commit is associated with an issue by [crosslinking](../../project/issues/crosslinking_issues.md) in the commit message or by manually linking the merge request containing the commit.
+- **Cycle time**: median time from first commit to issue closed. (You can associate a commit with an issue by [crosslinking in the commit message](../../project/issues/crosslinking_issues.md#from-commit-messages).)
 
 ![Value stream analytics time metrics](img/vsa_time_metrics_v13_0.png "Time metrics for value stream analytics")
 
 ## How the stages are measured
 
-Value Stream Analytics records stage time and data based on the project issues with the
-exception of the staging stage, where only data deployed to
-production are measured.
-
-Specifically, if your CI is not set up and you have not defined a [production environment](#how-the-production-environment-is-identified), then you will not have any
-data for this stage.
+Value Stream Analytics measures each stage from its start event to its stop event.
+For example, a stage might start when one label is added to an issue, and end when another label is added.
+Value Stream Analytics excludes work in progress, meaning it ignores any items that have not reached the stop event.
 
 Each stage of Value Stream Analytics is further described in the table below.
 
@@ -193,17 +188,37 @@ GitLab allows users to create multiple value streams, hide default stages and cr
 
 ### Stage path
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/210315) in GitLab 13.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/210315) in GitLab 13.0.
+> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
+> - It's enabled on GitLab.com.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](../../../administration/feature_flags.md). **(FREE SELF)**
+
+![Value stream path navigation](img/vsa_path_nav_v13_11.png "Value stream path navigation")
 
-Stages are visually depicted as a horizontal process flow. Selecting a stage will update the
-the content below the value stream.
+Stages are visually depicted as a horizontal process flow. Selecting a stage updates the content
+below the value stream.
 
-This is disabled by default. If you have a self-managed instance, an
+The stage time is displayed next to the name of each stage, in the following format:
+
+| Symbol | Description |
+|--------|-------------|
+| `m`    | Minutes     |
+| `h`    | Hours       |
+| `d`    | Days        |
+| `w`    | Weeks       |
+| `M`    | Months      |
+
+Hovering over a stage item displays a popover with the following information:
+
+- Start event description for the given stage
+- End event description
+
+Horizontal path navigation is enabled by default. If you have a self-managed instance, an
 administrator can [open a Rails console](../../../administration/troubleshooting/navigating_gitlab_via_rails_console.md)
-and enable it with the following command:
+and disable it with the following command:
 
 ```ruby
-Feature.enable(:value_stream_analytics_path_navigation)
+Feature.disable(:value_stream_analytics_path_navigation)
 ```
 
 ### Adding a stage
@@ -299,17 +314,16 @@ To create a value stream:
 1. Navigate to your group's **Analytics > Value Stream**.
 1. Click the Value stream dropdown and select **Create new Value Stream**
 1. Fill in a name for the new Value Stream
-   - You can [customize the stages](#creating-a-value-stream-with-stages) as the `value_stream_analytics_extended_form` feature flag is enabled.
+   - You can [customize the stages](#creating-a-value-stream-with-stages)
 1. Click the **Create Value Stream** button.
 
 ![New value stream](img/new_value_stream_v13_3.png "Creating a new value stream")
 
 #### Creating a value stream with stages
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55572) in GitLab 13.10.
-> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
-> - It's enabled on GitLab.com.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](../../../administration/feature_flags.md). **(FREE SELF)**
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50229) in GitLab 13.7.
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55572) in GitLab 13.10.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/294190) in GitLab 13.11.
 
 WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
@@ -331,27 +345,6 @@ To create a value stream with stages:
 
 ![Extended create value stream form](img/extended_value_stream_form_v13_10.png "Extended create value stream form")
 
-#### Enable or disable value stream with stages
-
-Value streams with stages is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-# For the instance
-Feature.enable(:value_stream_analytics_extended_form)
-```
-
-To disable it:
-
-```ruby
-# For the instance
-Feature.disable(:value_stream_analytics_extended_form)
-```
-
 ### Deleting a value stream
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221205) in GitLab 13.4.