Add latest changes from gitlab-org/gitlab@14-6-stable-eev14.6.0-rc42

17 files changed, 260 insertions, 192 deletions

diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index 9c95b2b21a4..b2b16321488 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 WARNING:
 This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. To connect clusters to GitLab,
-use the [GitLab Kubernetes Agent](../../clusters/agent/index.md).
+use the [GitLab Agent](../../clusters/agent/index.md).
 
 Similar to [project-level](../../project/clusters/index.md) and
 [instance-level](../../instance/clusters/index.md) Kubernetes clusters,
diff --git a/doc/user/group/custom_project_templates.md b/doc/user/group/custom_project_templates.md
index 9378b3922b5..2214a18475a 100644
--- a/doc/user/group/custom_project_templates.md
+++ b/doc/user/group/custom_project_templates.md
@@ -9,49 +9,49 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6861) in GitLab 11.6.
 
-[Group owners](../permissions.md#group-members-permissions) can set a subgroup to
-be the source of project templates that are selectable when a new project is created
-in the group. These templates can be selected when you go to **New project > Create from template**
-in the group and select the **Group** tab.
+When you create a project, you can [choose from a list of templates](../project/working_with_projects.md#create-a-project).
+These templates, for things like GitLab Pages or Ruby, populate the new project with a copy of the files contained in the
+template. This information is identical to the information used by [GitLab project import/export](../project/settings/import_export.md)
+and can help you start a new project more quickly.
 
-Every project in the subgroup, but not nested subgroups, can be selected by members
-of the group when a new project is created.
+You can [customize the list](../project/working_with_projects.md#create-a-project) of available templates, so
+that all projects in your group have the same list. To do this, you populate a subgroup with the projects you want to
+use as templates.
 
-- Public projects can be selected by any signed-in user as a template for a new project,
-  if all enabled [project features](../project/settings/index.md#sharing-and-permissions)
-  except for **GitLab Pages** and **Security & Compliance** are set to **Everyone With Access**.
-  The same applies to internal projects.
-- Private projects can be selected only by users who are members of the projects.
+You can also configure [custom templates for the instance](../admin_area/custom_project_templates.md).
 
-Repository and database information that is copied over to each new project is identical to the
-data exported with the [GitLab Project Import/Export](../project/settings/import_export.md).
+## Set up group-level project templates
 
-To set custom project templates at the instance level, see [Custom instance-level project templates](../admin_area/custom_project_templates.md).
+Prerequisite:
 
-## Set up group-level project templates
+- You must have the [Owner role for the group](../permissions.md#group-members-permissions).
 
 To set up custom project templates in a group, add the subgroup that contains the
 project templates to the group settings:
 
 1. In the group, create a [subgroup](subgroups/index.md).
 1. [Add projects to the new subgroup](index.md#add-projects-to-a-group) as your templates.
-1. In the left menu for the group, go to **Settings > General**.
+1. In the left menu for the group, select **Settings > General**.
 1. Expand **Custom project templates** and select the subgroup.
 
-If all enabled [project features](../project/settings/index.md#sharing-and-permissions)
-(except for GitLab Pages) are set to **Everyone With Access**, then every project
-template in the subgroup is available to every member of the group.
+The next time a group member creates a project, they can select any of the projects in the subgroup.
 
-Any projects added to the subgroup later can be selected the next time a group member
-creates a new project.
+Projects in nested subgroups are not included in the template list.
+
+## Which projects are available as templates
+
+- Public and internal projects can be selected by any signed-in user as a template for a new project,
+  if all [project features](../project/settings/index.md#sharing-and-permissions)
+  except for **GitLab Pages** and **Security & Compliance** are set to **Everyone With Access**.
+- Private projects can be selected only by users who are members of the projects.
 
-### Example structure
+## Example structure
 
-Here's a sample group/project structure for project templates, for a hypothetical _Acme Co_:
+Here's a sample group and project structure for project templates, for `myorganization`:
 
 ```plaintext
 # GitLab instance and group
-gitlab.com/acmeco/
+gitlab.com/myorganization/
     # Subgroups
     internal
     tools
@@ -61,7 +61,7 @@ gitlab.com/acmeco/
             # Project templates
             client-site-django
             client-site-gatsby
-            client-site-hTML
+            client-site-html
 
         # Other projects
         client-site-a
diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md
index 36ccfc1031f..4151745189d 100644
--- a/doc/user/group/devops_adoption/index.md
+++ b/doc/user/group/devops_adoption/index.md
@@ -16,94 +16,81 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - Overview table [added](https://gitlab.com/gitlab-org/gitlab/-/issues/335638) in GitLab 14.3.
 > - Adoption over time chart [added](https://gitlab.com/gitlab-org/gitlab/-/issues/337561) in GitLab 14.4.
 
-Prerequisites:
+DevOps Adoption shows you how groups in your organization adopt and use the most essential features of GitLab.
 
-- You must have at least the [Reporter role](../../permissions.md) for the group.
+You can use Group DevOps Adoption to:
 
-To access Group DevOps Adoption, go to your group and select **Analytics > DevOps Adoption**.
+- Identify specific subgroups that are lagging in their adoption of GitLab features, so you can guide them on
+their DevOps journey.
+- Find subgroups that have adopted certain features, and provide guidance to other subgroups on
+how to use those features.
+- Verify if you are getting the return on investment that you expected from GitLab.
 
-Group DevOps Adoption shows you how individual groups and subgroups within your organization use the following features:
+![DevOps Adoption](img/group_devops_adoption_v14_2.png)
 
-- Dev
-  - Approvals
-  - Code owners
-  - Issues
-  - Merge requests
-- Sec
-  - DAST
-  - Dependency Scanning
-  - Fuzz Testing
-  - SAST
-- Ops
-  - Deployments
-  - Pipelines
-  - Runners
+## View DevOps Adoption
 
-When managing groups in the UI, you can add or remove your subgroups with the **Add or remove subgroups**
-button, in the top right hand section of your Groups pages.
+Prerequisite:
 
-With DevOps Adoption you can:
+- You must have at least the [Reporter role](../../permissions.md) for the group.
 
-- Verify whether you are getting the return on investment that you expected from GitLab.
-- Identify specific subgroups that are lagging in their adoption of GitLab, so you can help them along in their DevOps journey.
-- Find the subgroups that have adopted certain features, and can provide guidance to other subgroups on how to use those features.
+To view DevOps Adoption:
 
-![DevOps Adoption](img/group_devops_adoption_v14_2.png)
+1. On the top bar, select **Menu > Groups** and find your group.
+1. On the left sidebar, select **Analytics > DevOps adoption**
+
+## DevOps Adoption categories
+
+DevOps Adoption shows feature adoption for development, security, and operations.
+
+| Category | Feature |
+| ---      | ---      |
+| Development   | Approvals<br>Code owners<br>Issues<br>Merge requests   |
+| Security   | DAST<br>Dependency Scanning<br>Fuzz Testing<br>SAST  |
+| Operations   | Deployments<br>Pipelines<br>Runners   |
+
+## Feature adoption
 
-Feature adoption is based on usage in the previous calendar month. Data is updated on the first day
-of each month. If the monthly update fails, it tries again daily until successful.
+DevOps Adoption shows feature adoption data for groups and subgroups for the previous calendar month.
 
-## Enable data processing
+A feature shows as **adopted** when a group has used the feature in a project during the time period.
+This includes projects in any subgroups of the group. For example, if an issue was created in a project in a group, the group has adopted issues in that time.
 
-Group DevOps Adoption relies on data that has been gathered by a weekly data processing task.
-This task is disabled by default.
+### Exceptions to feature adoption data
 
-To begin using Group DevOps Adoption, access the feature for the first time. GitLab automatically
-enables the data processing for that group. The group data doesn't appear immediately, because
-GitLab requires around a minute to process it.
+When GitLab measures DevOps Adoption, some common DevOps information is not included:
 
-## What is displayed
+- Dormant projects. It doesn't matter how many projects in the group use a feature. Even if you have many dormant projects, it doesn't lower the adoption.
+- New GitLab features. Adoption is the total number of features adopted, not the percent of features.
 
-DevOps Adoption displays feature adoption data for the given group
-and any added subgroups for the current calendar month.
-Each group appears as a separate row in the table.
-For each row, a feature is considered "adopted" if it has been used in a project in the given group
-during the time period (including projects in any subgroups of the given group).
+## When DevOps Adoption data is gathered
 
-## Adoption over time
+A weekly task processes data for DevOps Adoption. This task is disabled until you access
+DevOps Adoption for a group for the first time.
 
-The **Adoption over time** chart in the **Overview** tab displays DevOps Adoption over time. The chart displays the total number of adopted features from the previous twelve months,
-from when you enabled DevOps Adoption for the group.
+The data processing task updates the data on the first day of each month. If the monthly update
+fails, the task tries daily until it succeeds.
 
-The tooltip displays information about the features tracked for individual months.
+DevOps Adoption data may take up to a minute to appear while GitLab processes the group's data.
 
-## When is a feature considered adopted
+## View feature adoption over time
 
-A feature is considered "adopted" if it has been used anywhere in the group in the specified time.
-For example, if an issue was created in one project in a group, the group is considered to have
-"adopted" issues in that time.
+The **Adoption over time** chart shows the total number of adopted features from the previous
+twelve months. The chart only shows data from when you enabled DevOps Adoption for the group.
 
-## No penalties for common adoption patterns
+To view feature adoption over time:
 
-DevOps Adoption is designed not to penalize for any circumstances or practices that are common in DevOps.
-Following this guideline, GitLab doesn't penalize for:
+1. On the top bar, select **Menu > Groups** and find your group.
+1. On the left sidebar, select **Analytics > DevOps adoption**.
+1. Select the **Overview** tab.
 
-1. Having dormant projects. It's common for groups to have a mix of active and dormant projects,
-   so we should not consider adoption to be low if there are relatively many dormant projects.
-   This means we should not measure adoption by how many projects in the group have used a feature,
-   only by whether a feature was used anywhere in the group.
-1. GitLab adding new features over time. It's common for group feature usage to be consistent
-   over time, so we should not consider adoption to have decreased if GitLab adds features.
-   This means we should not measure adoption by percentages, only total counts.
+Tooltips display information about the features tracked for individual months.
 
-## Add a subgroup
+## Add or remove a subgroup
 
-DevOps Adoption can also display data for subgroups within the given group,
-to show you differences in adoption across the group.
-To add subgroups to your Group DevOps Adoption report:
+To add or remove a subgroup from the DevOps Adoption report:
 
 1. Select **Add or remove subgroups**.
-1. Select the subgroups you want to add and select **Save changes**.
+1. Select the subgroup you want to add or remove and select **Save changes**.
 
-The subgroup data might not appear immediately, because GitLab requires around a minute to collect
-the data.
+It may take up to a minute for subgroup data to appear while GitLab collects the data.
diff --git a/doc/user/group/epics/epic_boards.md b/doc/user/group/epics/epic_boards.md
index d184030718a..1bc1e4d703b 100644
--- a/doc/user/group/epics/epic_boards.md
+++ b/doc/user/group/epics/epic_boards.md
@@ -9,6 +9,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5067) in GitLab 13.10.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/290039) in GitLab 14.1.
 
+INFO:
+Try epic boards and more with a
+[free 30-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/index.html?glm_source=docs.gitlab.com&glm_content=p-epics-boards-docs).
+
 Epic boards build on the existing [epic tracking functionality](index.md) and
 [labels](../../project/labels.md). Your epics appear as cards in vertical lists, organized by their assigned
 labels.
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index 65e0f31324b..3889398e2f8 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -1,5 +1,4 @@
 ---
-type: reference, howto
 stage: Plan
 group: Product Planning
 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
@@ -7,8 +6,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Epics **(PREMIUM)**
 
-> - Introduced in GitLab 10.2.
-> - Single-level epics were [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/37081) from GitLab Ultimate to GitLab Premium in 12.8.
+> Single-level epics were [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/37081) from GitLab Ultimate to GitLab Premium in 12.8.
+
+INFO:
+Check out [multi-level child epics](manage_epics.md#multi-level-child-epics) with a
+[free 30-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/index.html?glm_source=docs.gitlab.com&glm_content=p-epics-docs).
 
 When [issues](../../project/issues/index.md) share a theme across projects and milestones,
 you can manage them by using epics.
@@ -37,9 +39,9 @@ graph TD
     Child_epic --> Issue2
 ```
 
-## Roadmap in epics **(ULTIMATE)**
+Also, read more about possible [planning hierarchies](../planning_hierarchy/index.md).
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7327) in GitLab 11.10.
+## Roadmap in epics **(ULTIMATE)**
 
 If your epic contains one or more [child epics](manage_epics.md#multi-level-child-epics) that
 have a start or due date, a visual
diff --git a/doc/user/group/epics/manage_epics.md b/doc/user/group/epics/manage_epics.md
index 72fa9e1e310..f5b1a2a6ee6 100644
--- a/doc/user/group/epics/manage_epics.md
+++ b/doc/user/group/epics/manage_epics.md
@@ -332,7 +332,7 @@ Only issues from projects that are in groups can be promoted. When you attempt t
 issue, a warning is displayed. Promoting a confidential issue to an epic makes all information
 related to the issue public as epics are public to group members.
 
-When the quick action is executed:
+When an issue is promoted to an epic:
 
 - An epic is created in the same group as the project of the issue.
 - Subscribers of the issue are notified that the epic was created.
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index f0e08301a1b..db6ed02f405 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -321,7 +321,7 @@ To share a group after enabling this feature:
 1. Go to your group's page.
 1. On the left sidebar, go to **Group information > Members**, and then select **Invite a group**.
 1. Select a group, and select a **Max role**.
-1. (Optional) Select an **Access expiration date**.
+1. Optional. Select an **Access expiration date**.
 1. Select **Invite**.
 
 ## Manage group memberships via LDAP **(PREMIUM SELF)**
@@ -508,7 +508,7 @@ To prevent a project from being shared with other groups:
 This setting applies to all subgroups unless overridden by a group owner. Groups already
 added to a project lose access when the setting is enabled.
 
-## Prevent members from being added to a group **(PREMIUM)**
+## Prevent members from being added to projects in a group **(PREMIUM)**
 
 As a group owner, you can prevent any new project membership for all
 projects in a group, allowing tighter control over project membership.
@@ -516,7 +516,11 @@ projects in a group, allowing tighter control over project membership.
 For example, if you want to lock the group for an [Audit Event](../../administration/audit_events.md),
 you can guarantee that project membership cannot be modified during the audit.
 
-To prevent members from being added to a group:
+You can still invite groups or to add members to groups, implicitly giving members access to projects in the **locked** group.
+
+The setting does not cascade. Projects in subgroups observe the subgroup configuration, ignoring the parent group.
+
+To prevent members from being added to projects in a group:
 
 1. Go to the group's **Settings > General** page.
 1. Expand the **Permissions, LFS, 2FA** section.
@@ -557,12 +561,15 @@ You should consider these security implications before configuring IP address re
 - **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.
+- **GitLab API and runner activities**: Only the [group](../../api/groups.md) (including all
+  [group resources](../../api/api_resources.md#group-resources)) APIs and [project](../../api/api_resources.md#project-resources)
+  (including all [project resources](../../api/api_resources.md#project-resources)) 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.
+- **User dashboard activity**: Users may still see some events from the IP restricted groups and projects
+  on their dashboard. Activity may include push, merge, issue, or comment events.
 
 To restrict group access by IP address:
 
@@ -660,18 +667,15 @@ To disable group mentions:
 1. Select **Disable group mentions**.
 1. Select **Save changes**.
 
-## Enable delayed project removal **(PREMIUM)**
+## Enable delayed project deletion **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
 > - [Inheritance and enforcement added](https://gitlab.com/gitlab-org/gitlab/-/issues/321724) in GitLab 13.11.
 > - [Instance setting to enable by default added](https://gitlab.com/gitlab-org/gitlab/-/issues/255449) in GitLab 14.2.
 
-Projects can be configured to be deleted either:
-
-- Immediately.
-- After a delayed interval. During this interval period, the projects are in a read-only state
-  and can be restored. The default interval period is seven days but
-  [is configurable](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
+[Delayed project deletion](../project/settings/index.md#delayed-project-deletion) can be enabled for groups. When enabled, projects in
+the group are deleted after a period of delay. During this period, projects are in a read-only state and can be restored. The default
+period is seven days but [is configurable at the instance level](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
 
 On self-managed GitLab, projects are deleted immediately by default.
 In GitLab 14.2 and later, an administrator can
@@ -685,12 +689,12 @@ To enable delayed deletion of projects in a group:
 
 1. Go to the group's **Settings > General** page.
 1. Expand the **Permissions, LFS, 2FA** section.
-1. Check **Enable delayed project removal**.
+1. Check **Enable delayed project deletion**.
 1. Optional. To prevent subgroups from changing this setting, select **Enforce for all subgroups**.
 1. Select **Save changes**.
 
 NOTE:
-In GitLab 13.11 and above the group setting for delayed project removal is inherited by subgroups. As discussed in [Cascading settings](../../development/cascading_settings.md) inheritance can be overridden, unless enforced by an ancestor.
+In GitLab 13.11 and above the group setting for delayed project deletion is inherited by subgroups. As discussed in [Cascading settings](../../development/cascading_settings.md) inheritance can be overridden, unless enforced by an ancestor.
 
 ## Prevent project forking outside group **(PREMIUM)**
 
@@ -799,13 +803,5 @@ the following checks when creating or updating namespaces or groups:
 - Namespaces must not have parents.
 - Group parents must be groups and not namespaces.
 
-You can disable the validation if GitLab shows the following errors:
-
-- `A user namespace cannot have a parent`.
-- `A group cannot have a user namespace as its parent`.
-
-To disable the validation,
-[disable the `validate_namespace_parent_type` flag](../../administration/feature_flags.md).
-
-In the unlikely event that you had to disable this feature flag to prevent errors,
+In the unlikely event that you see these errors in your GitLab installation,
 [contact Support](https://about.gitlab.com/support/) so that we can improve this validation.
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index 7a1cbe86d58..8a79effba15 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -7,14 +7,10 @@ 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.
-> - 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.
-> - Can be enabled or disabled per-group.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-iterations).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214713) in GitLab 13.1 [with a flag](../../../administration/feature_flags.md) named `group_iterations`. Disabled by default.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) in GitLab 13.2.
 > - Moved to GitLab Premium in 13.9.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) in GitLab 14.6. [Feature flag `group_iterations`](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) removed.
 
 Iterations are a way to track issues over a period of time. This allows teams
 to track velocity and volatility metrics. Iterations can be used with [milestones](../../project/milestones/index.md)
@@ -169,31 +165,7 @@ To group issues by label:
 1. Select the **Filter by label** dropdown.
 1. Select the labels you want to group by in the labels dropdown.
    You can also search for labels by typing in the search input.
-1. Select or tap outside of the label dropdown. The page is now grouped by the selected labels.
-
-## Enable or disable iterations **(PREMIUM SELF)**
-
-GitLab Iterations feature is deployed with a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can disable it for your instance. `:group_iterations` can be enabled or disabled per-group.
-
-To enable it:
-
-```ruby
-# Instance-wide
-Feature.enable(:group_iterations)
-# or by group
-Feature.enable(:group_iterations, Group.find(<group ID>))
-```
-
-To disable it:
-
-```ruby
-# Instance-wide
-Feature.disable(:group_iterations)
-# or by group
-Feature.disable(:group_iterations, Group.find(<group ID>))
-```
+1. Select any area outside the label dropdown list. The page is now grouped by the selected labels.
 
 ### Enable or disable iteration cadences **(PREMIUM SELF)**
 
diff --git a/doc/user/group/planning_hierarchy/img/epic-view-ancestors-in-sidebar_v14_6.png b/doc/user/group/planning_hierarchy/img/epic-view-ancestors-in-sidebar_v14_6.png
new file mode 100644
index 00000000000..373b861239b
--- /dev/null
+++ b/doc/user/group/planning_hierarchy/img/epic-view-ancestors-in-sidebar_v14_6.png
diff --git a/doc/user/group/planning_hierarchy/img/hierarchy_with_multi_level_epics.png b/doc/user/group/planning_hierarchy/img/hierarchy_with_multi_level_epics.png
new file mode 100644
index 00000000000..d264ebf10d7
--- /dev/null
+++ b/doc/user/group/planning_hierarchy/img/hierarchy_with_multi_level_epics.png
diff --git a/doc/user/group/planning_hierarchy/img/issue-view-parent-epic-in-sidebar_v14_6.png b/doc/user/group/planning_hierarchy/img/issue-view-parent-epic-in-sidebar_v14_6.png
new file mode 100644
index 00000000000..95a5777674a
--- /dev/null
+++ b/doc/user/group/planning_hierarchy/img/issue-view-parent-epic-in-sidebar_v14_6.png
diff --git a/doc/user/group/planning_hierarchy/index.md b/doc/user/group/planning_hierarchy/index.md
new file mode 100644
index 00000000000..5887328abe4
--- /dev/null
+++ b/doc/user/group/planning_hierarchy/index.md
@@ -0,0 +1,67 @@
+---
+type: reference
+stage: Plan
+group: Product Planning
+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
+---
+
+# Planning hierarchies **(PREMIUM)**
+
+Planning hierarchies are an integral part of breaking down your work in GitLab.
+To understand how you can use epics and issues together in hierarchies, remember the following:
+
+- [Epics](../epics/index.md) exist in groups.
+- [Issues](../../project/issues/index.md) exist in projects.
+
+GitLab is not opinionated on how you structure your work and the hierarchy you can build with multi-level
+epics. For example, you can use the hierarchy as a folder of issues for bigger initiatives.
+
+To learn about hierarchies in general, common frameworks, and using GitLab for
+portfolio management, see
+[How to use GitLab for Agile portfolio planning and project management](https://about.gitlab.com/blog/2020/11/11/gitlab-for-agile-portfolio-planning-project-management/).
+
+## Hierarchies with epics
+
+With epics, you can achieve the following hierarchy:
+
+```mermaid
+graph TD
+    Group_epic --> Project1_Issue1
+    Group_epic --> Project1_Issue2
+    Group_epic --> Project2_Issue1
+```
+
+### Hierarchies with multi-level epics **(ULTIMATE)**
+
+With the addition of [multi-level epics](../epics/manage_epics.md#multi-level-child-epics) and up to
+seven levels of nested epics, you can achieve the following hierarchy:
+
+<!--
+Image below was generated with the following Mermaid code.
+Attached as an image because a rendered diagram doesn't look clear on the docs page.
+
+```mermaid
+classDiagram
+  direction TD
+  class Epic
+  class Issue
+
+  Epic *-- "0..7" Epic
+Epic "1"*-- "0..*" Issue
+```
+
+ -->
+
+![Diagram showing possible relationships of multi-level epics](img/hierarchy_with_multi_level_epics.png)
+
+## View ancestry of an epic
+
+In an epic, you can view the ancestors as parents in the right sidebar under **Ancestors**.
+
+![epics state dropdown](img/epic-view-ancestors-in-sidebar_v14_6.png)
+
+## View ancestry of an issue
+
+In an issue, you can view the parented epic above the issue in the right sidebar under **Epic**.
+
+![epics state dropdown](img/issue-view-parent-epic-in-sidebar_v14_6.png)
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index 206f3172170..7d489bc5b2d 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -19,7 +19,7 @@ Epics and milestones in a group containing a start date or due date can be visua
 of a timeline (that is, a Gantt chart). The Roadmap page shows the epics and milestones in a
 group, one of its subgroups, or a project in one of the groups.
 
-On the epic bars, you can see the each epic's title, progress, and completed weight percentage.
+On the epic bars, you can see each epic's title, progress, and completed weight percentage.
 When you hover over an epic bar, a popover appears with the epic's title, start date, due date, and
 weight completed.
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 402007b85b2..7443be250bb 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -14,6 +14,10 @@ This page describes SAML for groups. For instance-wide SAML on self-managed GitL
 
 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.
 
+INFO:
+Use your own SAML authentication to log in to [GitLab.com](http://gitlab.com/).
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial/index.html?glm_source=docs.gitlab.com&glm_content=p-saml-sso-docs).
+
 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.
 
@@ -29,14 +33,16 @@ If required, you can find [a glossary of common terms](../../../integration/saml
    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. Configure the required [user attributes](#user-attributes), ensuring you include 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
    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)
 
+If your account is the only owner in the group after SAML is set up, you can't unlink the account. To [unlink the account](#unlinking-accounts),
+set up another user as a group owner.
+
 ### NameID
 
 GitLab.com uses the SAML NameID to identify users. The NameID element:
@@ -60,15 +66,16 @@ Once users have signed into GitLab using the SSO SAML setup, changing the `NameI
 We recommend setting the NameID format to `Persistent` unless using a field (such as email) that requires a different format.
 Most NameID formats can be used, except `Transient` due to the temporary nature of this format.
 
-### Assertions
+### User attributes
+
+To create users with the correct information for improved [user access and management](#user-access-and-management),
+the user's details must be passed to GitLab as attributes in the SAML assertion. At a minimum, the user's email address
+must be specified as an attribute named `email` or `mail`.
 
-For users to be created with the right information with the improved [user access and management](#user-access-and-management),
-the user details need to be passed to GitLab as SAML assertions.
+GitLab.com supports the following attributes:
 
-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.
-In addition to the attributes in the linked assertions list, GitLab.com supports `username`
-and `nickname` attributes.
+- `username` or `nickname`. We recommend you configure only one of these.
+- The [attributes also available](../../../integration/saml.md#assertions) to self-managed GitLab instances.
 
 ### Metadata configuration
 
@@ -104,7 +111,7 @@ The certificate [fingerprint algorithm](../../../integration/saml.md#notes-on-co
 > - [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 (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.
+With this option enabled, users (except users with the Owner role) must access GitLab using your group GitLab single sign-on URL to access group resources. Users added manually as members can't access group resources.
 
 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.
 
@@ -119,7 +126,7 @@ SSO has the following effects when enabled:
 - For groups, users can't share a project in the group outside the top-level group,
   even if the project is forked.
 - For Git activity over SSH and HTTPS, users must have at least one active session signed-in through SSO before they can push to or
-  pull from a GitLab repository. 
+  pull from a GitLab repository.
 - Credentials that are not tied to regular users (for example, access tokens and deploy keys) do not have the SSO check enforced.
 - Users must be signed-in through SSO before they can pull images using the [Dependency Proxy](../../packages/dependency_proxy/index.md).
 <!-- Add bullet for API activity when https://gitlab.com/gitlab-org/gitlab/-/issues/9152 is complete -->
@@ -342,6 +349,11 @@ Ensure your SAML identity provider sends an attribute statement named `Groups` o
 </saml:AttributeStatement>
 ```
 
+Other attribute names such as `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups`
+are not accepted as a source of groups.
+See the [SAML troubleshooting page](../../../administration/troubleshooting/group_saml_scim.md)
+for examples on configuring the required attribute name in the SAML identity provider's settings.
+
 NOTE:
 The value for `Groups` or `groups` in the SAML response can be either the group name or the group ID.
 To inspect the SAML response, you can use one of these [SAML debugging tools](#saml-debugging-tools).
@@ -362,7 +374,7 @@ To link the SAML groups from the `saml:AttributeStatement` example above:
 If a user is a member of multiple SAML groups mapped to the same GitLab group,
 the user gets the highest access level from the groups. For example, if one group
 is linked as `Guest` and another `Maintainer`, a user in both groups gets `Maintainer`
-access. 
+access.
 
 Users granted:
 
@@ -374,7 +386,10 @@ Users granted:
 ### Automatic member removal
 
 After a group sync, users who are not members of a mapped SAML group are removed from
-the GitLab group.
+the GitLab group. Even if SSO authentication is successful, if an existing user is not a member of any of the configured groups:
+
+- They get an "unauthorized" message if they try to view the group.
+- All of their permissions to subgroups and projects are also removed.
 
 For example, in the following diagram:
 
@@ -475,6 +490,24 @@ Specific attention should be paid to:
 - The presence of a `X509Certificate`, which we require to verify the response signature.
 - The `SubjectConfirmation` and `Conditions`, which can cause errors if misconfigured.
 
+#### Generate a SAML Response
+
+SAML Responses can be used to preview the attribute names and values sent in the assertions list while attempting to sign in using an IdP.
+
+To generate a SAML Response:
+
+1. Install either:
+   - [SAML Chrome Panel](https://chrome.google.com/webstore/detail/saml-chrome-panel/paijfdbeoenhembfhkhllainmocckace) for Chrome.
+   - [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) for Firefox.
+1. Open a new browser tab.
+1. Open the SAML tracer console:
+   - Chrome: Right click on the page, select **Inspect**, then click on the SAML tab in the opened developer console.
+   - Firefox: Select the SAML-tracer icon located on the browser toolbar.
+1. Go to the GitLab single sign-on URL for the group in the same browser tab with the SAML tracer open.
+1. Select **Authorize** or attempt to log in. A SAML response is displayed in the tracer console that resembles this
+   [example SAML response](#example-saml-response).
+1. Within the SAML tracer, select the **Export** icon to save the response in JSON format.
+
 ### Verifying configuration
 
 For convenience, we've included some [example resources](../../../administration/troubleshooting/group_saml_scim.md) used by our Support Team. While they may help you verify the SAML app configuration, they are not guaranteed to reflect the current state of third-party products.
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index dd4558b4a3e..2651bcb9e12 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -115,12 +115,7 @@ configuration. Otherwise, the Okta SCIM app may not work properly.
 
 1. Sign in to Okta.
 1. Ensure you are in the Admin section by selecting the **Admin** button located in the top right. The admin button is not visible from the admin page.
-
-   NOTE:
-   If you're using the Developer Console, select **Developer Console** in the top
-   bar and then select **Classic UI**. Otherwise, you may not see the buttons described in the following steps:
-
-1. In the **Application** tab, select **Add Application**.
+1. In the **Application** tab, select **Browse App Catalog**.
 1. Search for **GitLab**, find and select on the 'GitLab' application.
 1. On the GitLab application overview page, select **Add**.
 1. Under **Application Visibility** select both checkboxes. Currently the GitLab application does not support SAML authentication so the icon should not be shown to users.
@@ -170,14 +165,11 @@ During provisioning:
 - Duplicate usernames are also handled, by adding suffix `1` upon user creation. For example,
   due to already existing `test_user` username, `test_user1` is used.
 
-As long as [Group SAML](index.md) has been configured, existing GitLab.com users can link to their accounts in one of the following ways:
-
-- By updating their *primary* email address in their GitLab.com user account to match their identity provider's user profile email address.
-- By following these steps:
+If [Group SAML](index.md) has been configured and you have an existing GitLab.com account, you can link your SCIM and SAML identities:
 
-  1. Sign in to GitLab.com if needed.
-  1. In the identity provider's dashboard select the GitLab app or visit the **GitLab single sign-on URL**.
-  1. Select the **Authorize**.
+1. Update the [primary email](../../profile/index.md#change-your-primary-email) address in your GitLab.com user account to match the
+   user profile email address in your identity provider.
+1. [Link your SAML identity](index.md#linking-saml-to-your-existing-gitlabcom-account).
 
 We recommend users do this prior to turning on sync, because while synchronization is active, there may be provisioning errors for existing users.
 
@@ -303,3 +295,12 @@ As a workaround, try an alternate mapping:
 1. Follow the Azure mapping instructions from above.
 1. Delete the `name.formatted` target attribute entry.
 1. Change the `displayName` source attribute to have `name.formatted` target attribute.
+
+#### Failed to match an entry in the source and target systems Group 'Group-Name'
+
+Group provisioning in Azure can fail with the `Failed to match an entry in the source and target systems Group 'Group-Name'` error message,
+and the error response can include a HTML result of the GitLab URL `https://gitlab.com/users/sign_in`.
+
+This error is harmless and occurs because Group provisioning was turned on but GitLab SCIM integration does not support it nor require it. To
+remove the error, follow the instructions in the Azure configuration guide to disable the option
+[`Synchronize Azure Active Directory Groups to AppName`](#azure-configuration-steps).
diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md
index 3692a2636ab..5745c499c5c 100644
--- a/doc/user/group/settings/import_export.md
+++ b/doc/user/group/settings/import_export.md
@@ -9,19 +9,16 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2888) in GitLab 13.0 as an experimental feature. May change in future releases.
 
-Existing groups running on any GitLab instance or GitLab.com can be exported with all their related data and moved to a
-new GitLab instance.
+You can export groups, with all their related data, from one GitLab instance to another.
+You can also [export projects](../../project/settings/import_export.md).
 
-The **GitLab import/export** button is displayed if the group import option in enabled.
+## Enable export for a group
 
-See also:
+Prerequisite:
 
-- [Group Import/Export API](../../../api/group_import_export.md)
-- [Project Import/Export](../../project/settings/import_export.md)
-- [Project Import/Export API](../../../api/project_import_export.md)
+- You must have the [Owner role](../../permissions.md) for the group.
 
-Users with the [Owner role](../../permissions.md) for a group can enable
-import and export for that group:
+To enable import and export for a group:
 
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
@@ -70,8 +67,11 @@ WARNING:
 This feature will be [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/4619)
 in GitLab 14.6 and replaced by [GitLab Migration](../import/).
 
-Users with the [Owner role](../../permissions.md) for a group can export the
-contents of that group:
+Prerequisites:
+
+- You must have the [Owner role](../../permissions.md) for the group.
+
+To export the contents of a group:
 
 1. On the top bar, select **Menu > Groups** and find your group.
 1. On the left sidebar, select **Settings > General**.
@@ -88,6 +88,8 @@ NOTE:
 The maximum import file size can be set by the Administrator, default is `0` (unlimited).
 As an administrator, you can modify the maximum import file size. To do so, use the `max_import_size` option in the [Application settings API](../../../api/settings.md#change-application-settings) or the [Admin UI](../../admin_area/settings/account_and_limit_settings.md). Default [modified](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50MB to 0 in GitLab 13.8.
 
+You can also use the [group import/export API](../../../api/group_import_export.md).
+
 ### Between CE and EE
 
 You can export groups from the [Community Edition to the Enterprise Edition](https://about.gitlab.com/install/ce-or-ee/) and vice versa.
@@ -96,6 +98,10 @@ The Enterprise Edition retains some group data that isn't part of the Community
 
 ## Importing the group
 
+WARNING:
+This feature will be [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/4619)
+in GitLab 14.8 and replaced by [GitLab Migration](../import/).
+
 1. Create a new group:
    - On the top bar, select **New** (**{plus}**) and then **New group**.
    - On an existing group's page, select the **New subgroup** button.
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index a0a13c71d95..b91e258b04a 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -86,8 +86,8 @@ the date filter behavior to filter the end event time of the currently selected
 The change makes it possible to get a much better picture about the completed items within the
 stage and helps uncover long-running items.
 
-For example, an issue was created a year ago and the current stage was finished in the current month. 
-If you were to look at the metrics for the last three months, this issue would not be included in the calculation of 
+For example, an issue was created a year ago and the current stage was finished in the current month.
+If you were to look at the metrics for the last three months, this issue would not be included in the calculation of
 the stage metrics. With the new date filter, this item would be included.
 
 DISCLAIMER:
@@ -100,7 +100,7 @@ sole discretion of GitLab Inc.
 
 ## How metrics are measured
 
-> DORA API-based deployment metrics for group-level Value Stream Analytics were 
+> DORA API-based deployment metrics for group-level Value Stream Analytics were
 > [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/337256) from GitLab Ultimate to GitLab Premium in 14.3.
 
 The "Time" metrics near the top of the page are measured as follows: