Add latest changes from gitlab-org/gitlab@15-1-stable-eev15.1.0-rc42

15 files changed, 364 insertions, 393 deletions

diff --git a/doc/user/group/contribution_analytics/index.md b/doc/user/group/contribution_analytics/index.md
index cd2d5c190a1..ba805d6e1bb 100644
--- a/doc/user/group/contribution_analytics/index.md
+++ b/doc/user/group/contribution_analytics/index.md
@@ -49,7 +49,7 @@ Select the desired period from the calendar dropdown.
 
 ## Sorting by different factors
 
-Contributions per group member are also presented in tabular format. Click a column header to sort the table by that column:
+Contributions per group member are also presented in tabular format. Select a column header to sort the table by that column:
 
 - Member name
 - Number of pushed events
diff --git a/doc/user/group/custom_project_templates.md b/doc/user/group/custom_project_templates.md
index 00e6bc671c1..6755bf9ffb9 100644
--- a/doc/user/group/custom_project_templates.md
+++ b/doc/user/group/custom_project_templates.md
@@ -41,7 +41,7 @@ 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)
+  if all [project features](../project/settings/index.md#configure-project-visibility-features-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.
 
diff --git a/doc/user/group/epics/img/epics_search_v14_7.png b/doc/user/group/epics/img/epics_filter_v14_7.png
index baed532c736..baed532c736 100644
--- a/doc/user/group/epics/img/epics_search_v14_7.png
+++ b/doc/user/group/epics/img/epics_filter_v14_7.png
diff --git a/doc/user/group/epics/manage_epics.md b/doc/user/group/epics/manage_epics.md
index e8f720238ed..e0334eda875 100644
--- a/doc/user/group/epics/manage_epics.md
+++ b/doc/user/group/epics/manage_epics.md
@@ -87,6 +87,26 @@ To edit an epic's start date, due date, or labels:
 1. Next to each section in the right sidebar, select **Edit**.
 1. Select the dates or labels for your epic.
 
+### Reorder list items in the epic description
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15260) in GitLab 15.1.
+
+When you view an epic that has a list in the description, you can also reorder the list items.
+
+Prerequisites:
+
+- You must have at least the Reporter role for the project, be the author of the epic, or be
+  assigned to the epic.
+- The epic's description must have an [ordered, unordered](../../markdown.md#lists), or
+  [task](../../markdown.md#task-lists) list.
+
+To reorder list items, when viewing an epic:
+
+1. Hover over the list item row to make the drag icon (**{drag-vertical}**) visible.
+1. Select and hold the drag icon.
+1. Drag the row to the new position in the list.
+1. Release the drag icon.
+
 ## Bulk edit epics
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7250) in GitLab 12.2.
@@ -187,17 +207,17 @@ To view epics in a group:
 The total count of open epics displayed in the sidebar is cached if higher
 than 1000. The cached value is rounded to thousands or millions and updated every 24 hours.
 
-## Search for an epic from epics list page
+## Filter the list of epics
 
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/37081) from GitLab Ultimate to GitLab Premium in 12.8.
-> - Searching by the user's reaction emoji [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325630) in GitLab 13.11.
+> - Filtering by epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/195704) in GitLab 12.9.
+> - Filtering by child epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9029) in GitLab 13.0.
+> - Filtering by the user's reaction emoji [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325630) in GitLab 13.11.
 > - Sorting by epic titles [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/331625) in GitLab 14.1.
-> - Searching by milestone and confidentiality [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268372) in GitLab 14.2 [with a flag](../../../administration/feature_flags.md) named `vue_epics_list`. Disabled by default.
+> - Filtering by milestone and confidentiality [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268372) in GitLab 14.2 [with a flag](../../../administration/feature_flags.md) named `vue_epics_list`. Disabled by default.
 > - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/276189) in GitLab 14.7.
 > - [Feature flag `vue_epics_list`](https://gitlab.com/gitlab-org/gitlab/-/issues/327320) removed in GitLab 14.8.
 
-You can search for an epic from the list of epics using filtered search bar based on following
-parameters:
+You can filter the list of epics by:
 
 - Title or description
 - Author name / username
@@ -206,9 +226,9 @@ parameters:
 - Confidentiality
 - Reaction emoji
 
-![epics search](img/epics_search_v14_7.png)
+![epics filter](img/epics_filter_v14_7.png)
 
-To search:
+To filter:
 
 1. On the top bar, select **Menu > Groups** and find your group.
 1. On the left sidebar, select **Epics**.
@@ -216,7 +236,9 @@ To search:
 1. From the dropdown menu, select the scope or enter plain text to search by epic title or description.
 1. Press <kbd>Enter</kbd> on your keyboard. The list is filtered.
 
-You can also sort epics list by:
+## Sort the list of epics
+
+You can sort the epics list by:
 
 - Start date
 - Due date
diff --git a/doc/user/group/img/restrict-by-email.gif b/doc/user/group/img/restrict-by-email.gif
deleted file mode 100644
index d1ebeb07a0a..00000000000
--- a/doc/user/group/img/restrict-by-email.gif
+++ /dev/null
diff --git a/doc/user/group/img/restrict-by-ip.gif b/doc/user/group/img/restrict-by-ip.gif
deleted file mode 100644
index 6292a58e748..00000000000
--- a/doc/user/group/img/restrict-by-ip.gif
+++ /dev/null
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 6967815bf22..ae1465d0b1b 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -1,37 +1,42 @@
 ---
-type: reference, howto
 stage: Manage
 group: Import
 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
 ---
 
-# Migrate groups from another instance of GitLab **(FREE)**
+# Migrating groups **(FREE)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/249160) in GitLab 13.7 [with a flag](../../feature_flags.md) named `bulk_import`. Disabled by default.
-> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338985) in GitLab 14.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/249160) in GitLab 13.7 for group resources [with a flag](../../feature_flags.md) named `bulk_import`. Disabled by default.
+> - Group resources [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338985) in GitLab 14.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267945) in GitLab 14.4 for project resources [with a flag](../../feature_flags.md) named `bulk_import_projects`. Disabled by default.
 
 FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `bulk_import`. On GitLab.com, this feature is available.
+On self-managed GitLab, by default [migrating group resources](#migrated-group-resources) is available. To hide the
+feature, ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `bulk_import`.
+On self-managed GitLab, by default [migrating project resources](#migrated-project-resources) is not available. To show
+this feature, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named
+`bulk_import_projects`. On GitLab.com, migrating group resources is available but migrating project resources is not
+available.
 
-You can migrate your existing top-level groups to any of the following:
+Users with the Owner role on a top-level group can migrate it to:
 
-- Another GitLab instance, including GitLab.com.
 - Another top-level group.
 - The subgroup of any existing top-level group.
+- Another GitLab instance, including GitLab.com.
 
-Migrating groups is not the same as [group import/export](../settings/import_export.md).
-
-- Group import/export requires you to export a group to a file and then import that file in
-  another GitLab instance.
-- Group migration automates this process.
+Migrating groups using the method documented here is not the same as [migrating groups using file exports](../settings/import_export.md).
+Importing and exporting groups using file exports requires you to export a group to a file and then import that file in
+another GitLab instance. Migrating groups using the method documented here automates this step.
 
 ## Import your groups into GitLab
 
 When you migrate a group, you connect to your GitLab instance and then choose
-groups to import. Not all the data is migrated. View the
-[Migrated resources](#migrated-resources) list for details.
+groups to import. Not all the data is migrated. See:
+
+- [Migrated group resources](#migrated-group-resources).
+- [Migrated project resources](#migrated-project-resources).
 
-Leave feedback about group migration in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495).
+Leave feedback about group migration in [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495).
 
 NOTE:
 You might need to reconfigure your firewall to prevent blocking the connection on the self-managed
@@ -74,66 +79,57 @@ Migration importer page. The remote groups you have the Owner role for are liste
 For information on automating user, group, and project import API calls, see
 [Automate group and project import](../../project/import/index.md#automate-group-and-project-import).
 
-## Migrated resources
+## Migrated group resources
 
 Only the following resources are migrated to the target instance. Any other items are **not**
 migrated:
 
-- Groups ([Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4374) in 13.7)
-  - description
-  - attributes
-  - subgroups
-  - avatar ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322904) in 14.0)
-- Group labels ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292429) in 13.9)
-  - title
-  - description
-  - color
-  - created_at ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300007) in 13.10)
-  - updated_at ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300007) in 13.10)
+- Badges ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292431) in 13.11)
+- Board Lists
+- Boards 
+- Epics ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250281) in 13.7)
+- Finisher
+- Group Labels ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292429) in 13.9)
+- Iterations ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292428) in 13.10)
 - Members ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299415) in 13.9)
   Group members are associated with the imported group if:
   - The user already exists in the target GitLab instance and
   - The user has a public email in the source GitLab instance that matches a
     confirmed email in the target GitLab instance
-- Epics ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250281) in 13.7)
-  - title
-  - description
-  - state (open / closed)
-  - start date
-  - due date
-  - epic order on boards
-  - confidentiality
-  - labels ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/297460) in 13.9)
-  - author ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/298745) in 13.9)
-  - parent epic ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/297459) in 13.9)
-  - emoji award ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/297466) in 13.9)
-  - events ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/297465) in 13.10)
 - Milestones ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292427) in 13.10)
-  - title
-  - description
-  - state (active / closed)
-  - start date
-  - due date
-  - created at
-  - updated at
-  - iid ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326157) in 13.11)
-- Iterations ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292428) in 13.10)
-  - iid
-  - title
-  - description
-  - state (upcoming / started / closed)
-  - start date
-  - due date
-  - created at
-  - updated at
-- Badges ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292431) in 13.11)
-  - name
-  - link URL
-  - image URL
-- Boards
-- Board Lists
+- Namespace Settings
 - Releases
   - Milestones ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339422) in GitLab 15.0).
+- Sub-Groups
+- Uploads
+
+## Migrated project resources
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267945) in GitLab 14.4 [with a flag](../../feature_flags.md) named `bulk_import_projects`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, migrating project resources are not available by default. To make them available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `bulk_import_projects`. On GitLab.com, migrating project resources are not available.
+
+- Projects ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267945) in GitLab 14.4)
+  - Auto DevOps ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339410) in GitLab 14.6)
+  - Branches (including protected branches) ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339414) in GitLab 14.7)
+  - CI Pipelines ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339407) in GitLab 14.6)
+  - Designs ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339421) in GitLab 15.1)
+  - Issues ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267946) in GitLab 14.4)
+  - Labels ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339419) in GitLab 14.4)
+  - LFS Objects ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339405) in GitLab 14.8)
+  - Members ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/341886) in GitLab 14.8)
+  - Merge Requests ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339403) in GitLab 14.5)
+  - Migrate Push Rules ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339403) in GitLab 14.6)
+  - Pull Requests (including external pull requests) ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339409) in GitLab 14.5)
+  - Pipeline History ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339412) in GitLab 14.6)
+  - Pipeline Schedules ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339408) in GitLab 14.8)
+  - Releases ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339422) in GitLab 15.1)
+  - Release Evidences ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360567) in GitLab 15.1)
+  - Repositories ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267945) in GitLab 14.4)
+  - Snippets ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/343438) in GitLab 14.6)
+  - Uploads ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/339401) in GitLab 14.5)
+  - Wikis ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345923) in GitLab 14.6)
 
 ## Troubleshooting Group Migration
 
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 87146329031..c0ae721e3b4 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -418,7 +418,7 @@ This action removes the group. It also adds a background job to delete all proje
 
 Specifically:
 
-- In [GitLab 12.8 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [GitLab Premium](https://about.gitlab.com/pricing/premium/) or higher tiers, this action adds a background job to mark a group for deletion. By default, the job schedules the deletion 7 days in the future. You can modify this waiting period through the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
+- In [GitLab 12.8 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [GitLab Premium](https://about.gitlab.com/pricing/premium/) or higher tiers, this action adds a background job to mark a group for deletion. By default, the job schedules the deletion 7 days in the future. You can modify this waiting period through the [instance settings](../admin_area/settings/visibility_and_access_controls.md#deletion-protection).
 - In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/39504), if the user who sets up the deletion is removed from the group before the
 deletion happens, the job is cancelled, and the group is no longer scheduled for deletion.
 
@@ -599,7 +599,7 @@ You can export a list of members in a group or subgroup as a CSV.
 1. Select **Export as CSV**.
 1. After the CSV file has been generated, it is emailed as an attachment to the user that requested it.
 
-## Restrict group access by IP address **(PREMIUM)**
+## Group access restriction by IP address **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1985) in GitLab 12.0.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/215410) from GitLab Ultimate to GitLab Premium in 13.1.
@@ -611,24 +611,26 @@ applies to:
 - The GitLab UI, including subgroups, projects, and issues.
 - [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), the API.
 
-You should consider these security implications before configuring IP address restrictions:
-
-- **SSH requests, including `git` operations will fail from all IP addresses**: 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 can access group settings from any IP address**: 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.
-- **Some GitLab API endpoints will remain accessible from any IP**: 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.
-- **Activities performed by GitLab Runners are not bound by IP 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
+### Security implications
+
+You should consider some security implications before configuring IP address restrictions.
+
+- Restricting HTTP traffic on GitLab.com with IP address restrictions causes SSH requests (including Git operations over
+  SSH) to fail. For more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271673).
+- Administrators and group owners can access group settings from any IP address, regardless of IP restriction. However:
+  - Groups owners cannot access projects belonging to the group when accessing from a disallowed IP address.
+  - Administrators can access projects belonging to the group when accessing from a disallowed IP address.
+    Access to projects includes cloning code from them.
+  - Users can still see group and project names and hierarchies. Only the following are restricted:
+    - [Groups](../../api/groups.md), including all [group resources](../../api/api_resources.md#group-resources).
+    - [Project](../../api/projects.md), including all [project resources](../../api/api_resources.md#project-resources).
+- 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.
+- 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.
+
+### Restrict group access by IP address
 
 To restrict group access by IP address:
 
@@ -637,7 +639,9 @@ To restrict group access by IP address:
 1. In the **Allow access to the following IP addresses** field, enter IPv4 or IPv6 address ranges in CIDR notation.
 1. Select **Save changes**.
 
-   ![Domain restriction by IP address](img/restrict-by-ip.gif)
+In self-managed installations of GitLab 15.1 and later, you can also configure
+[globally-allowed IP address ranges](../admin_area/settings/visibility_and_access_controls.md#configure-globally-allowed-ip-address-ranges)
+at the group level.
 
 ## Restrict group access by domain **(PREMIUM)**
 
@@ -654,8 +658,6 @@ To restrict group access by domain:
 1. In the **Restrict membership by email** field, enter the domain names.
 1. Select **Save changes**.
 
-![Domain restriction by email](img/restrict-by-email.gif)
-
 Any time you attempt to add a new user, the user's [primary email](../profile/index.md#change-your-primary-email) is compared against this list.
 Only users with a [primary email](../profile/index.md#change-your-primary-email) that matches any of the configured email domain restrictions
 can be added to the group.
@@ -734,14 +736,17 @@ To disable group mentions:
 > - [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.
+> - [Instance setting is inherited and enforced when disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/352960) in GitLab 15.1.
+> - [User interface changed](https://gitlab.com/gitlab-org/gitlab/-/issues/352961) in GitLab 15.1.
 
-[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).
+[Delayed project deletion](../project/settings/index.md#delayed-project-deletion) is locked and disabled unless the instance-level settings for
+[deletion protection](../admin_area/settings/visibility_and_access_controls.md#deletion-protection) is enabled for either groups only or groups and projects.
+When enabled on groups, 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#retention-period).
 
 On self-managed GitLab, projects are deleted immediately by default.
 In GitLab 14.2 and later, an administrator can
-[change the default setting](../admin_area/settings/visibility_and_access_controls.md#default-delayed-project-deletion)
+[change the default setting](../admin_area/settings/visibility_and_access_controls.md#deletion-protection)
 for projects in newly-created groups.
 
 On GitLab.com, see the [GitLab.com settings page](../gitlab_com/index.md#delayed-project-deletion) for
@@ -751,8 +756,12 @@ To enable delayed deletion of projects in a group:
 
 1. Go to the group's **Settings > General** page.
 1. Expand the **Permissions and group features** section.
-1. Check **Enable delayed project deletion**.
-1. Optional. To prevent subgroups from changing this setting, select **Enforce for all subgroups**.
+1. Scroll to:
+   - (GitLab 15.1 and later) **Deletion protection** and select **Keep deleted projects**.
+   - (GitLab 15.0 and earlier) **Enable delayed project deletion** and tick the checkbox.
+1. Optional. To prevent subgroups from changing this setting, select:
+   - (GitLab 15.1 and later), **Enforce deletion protection for all subgroups**
+   - (GitLab 15.0 and earlier), **Enforce for all subgroups**.
 1. Select **Save changes**.
 
 NOTE:
@@ -766,8 +775,6 @@ By default, projects in a group can be forked.
 Optionally, on [GitLab Premium](https://about.gitlab.com/pricing/) or higher tiers,
 you can prevent the projects in a group from being forked outside of the current top-level group.
 
-Previously, this setting was available only for groups enforcing a
-[Group Managed Account](saml_sso/group_managed_accounts.md) in SAML.
 This setting will be removed from the SAML setting page, and migrated to the
 group settings page. In the interim period, both of these settings are taken into consideration.
 If even one is set to `true`, then the group does not allow outside forks.
@@ -800,7 +807,7 @@ The group's new subgroups have push rules set for them based on either:
 - The closest parent group with push rules defined.
 - Push rules set at the instance level, if no parent groups have push rules defined.
 
-## Group approval settings **(PREMIUM)**
+## Group merge request approval settings **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285458) in GitLab 13.9. [Deployed behind the `group_merge_request_approval_settings_feature_flag` flag](../../administration/feature_flags.md), disabled by default.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.5.
@@ -844,6 +851,7 @@ Support for group-level settings for merge request approval rules is tracked in
 - [Enforce two-factor authentication (2FA)](../../security/two_factor_authentication.md#enforce-2fa-for-all-users-in-a-group): Enforce 2FA
   for all group members.
 - Namespaces [API](../../api/namespaces.md) and [Rake tasks](../../raketasks/features.md).
+- [Control access and visibility](../admin_area/settings/visibility_and_access_controls.md).
 
 ## Troubleshooting
 
@@ -855,7 +863,7 @@ If a user sees a 404 when they would normally expect access, and the problem is
 - `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.
+[allowed IPs](#group-access-restriction-by-ip-address) for the group.
 
 ### Validation errors on namespaces and groups
 
diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index 6771ff8739a..0a00d0c1c1c 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -3,121 +3,12 @@ type: reference, howto
 stage: Manage
 group: Authentication and Authorization
 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
+remove_date: '2022-06-13'
+redirect_to: 'index.md'
 ---
 
 # Group Managed Accounts **(PREMIUM)**
 
-WARNING:
-This [Closed Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#sts=Closed%20Beta) feature is being re-evaluated in favor of a different
-[approach](https://gitlab.com/groups/gitlab-org/-/epics/4786) that aligns more closely with our [Subscription Agreement](https://about.gitlab.com/handbook/legal/subscription-agreement/).
-We recommend that group owners who haven't yet implemented this feature wait for the new solution.
-
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/709) in GitLab 12.1.
-> - It's deployed behind a feature flag, disabled by default.
-
-When [SSO for Groups](index.md) is enforced, groups can enable an additional level of protection by enforcing the creation of dedicated user accounts to access the group.
-
-With group-managed accounts enabled, users are required to create a new, dedicated user linked to the group.
-The notification email address associated with the user is locked to the email address received from the configured identity provider.
-Without group-managed accounts, users can link their SAML identity with any existing user on the instance.
-
-When this option is enabled:
-
-- All users in the group are required to log in via the SSO URL associated with the group.
-- After the group-managed account has been created, group activity requires the use of this user account.
-- Users can't share a project in the group outside the top-level group (also applies to forked projects).
-
-Upon successful authentication, GitLab prompts the user with options, based on the email address received from the configured identity provider:
-
-- To create a unique account with the newly received email address.
-- If the received email address matches one of the user's verified GitLab email addresses, the option to convert the existing account to a group-managed account. ([Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/13481).)
-
-Since use of the group-managed account requires the use of SSO, users of group-managed accounts lose access to these accounts when they are no longer able to authenticate with the connected identity provider. In the case of an offboarded employee who has been removed from your identity provider:
-
-- The user is unable to access the group (their credentials no longer work on the identity provider when prompted to use SSO).
-- Contributions in the group (for example, issues and merge requests) remains intact.
-
-Please refer to our [SAML SSO for Groups page](../index.md) for information on how to configure SAML.
-
-## Feature flag **(PREMIUM SELF)**
-
-The group-managed accounts feature is behind these feature flags: `group_managed_accounts`, `sign_up_on_sso` and `convert_user_to_group_managed_accounts`. The flags are disabled by default.
-To activate the feature, ask a GitLab administrator with Rails console access to run:
-
-```ruby
-Feature.enable(:group_managed_accounts)
-Feature.enable(:sign_up_on_sso)
-Feature.enable(:convert_user_to_group_managed_accounts)
-```
-
-## Project restrictions for Group-managed accounts
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12420) in GitLab 12.9.
-
-Projects within groups with enabled group-managed accounts are not to be shared with:
-
-- Groups outside of the parent group.
-- Members who are not users managed by this group.
-
-This restriction also applies to projects forked from or to those groups.
-
-## Outer forks restriction for Group-managed accounts
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34648) in GitLab 12.9.
-
-Groups with group-managed accounts can prevent forking of projects to destinations outside the group.
-To do so, enable the "Prohibit outer forks" option in **Settings > SAML SSO**.
-When enabled **at the parent group level**, projects within the group can be forked
-only to other destinations within the group (including its subgroups).
-
-## Credentials inventory for Group-managed accounts **(ULTIMATE)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/38133) in GitLab 12.8.
-
-Owners who manage user accounts in a group can view the following details of personal access tokens and SSH keys:
-
-- Owners
-- Scopes
-- Usage patterns
-
-To access the Credentials inventory of a group, navigate to **{shield}** **Security & Compliance > Credentials** in your group's sidebar.
-
-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.
-
-Users in a group managed account can optionally specify an expiration date for
-[personal access tokens](../../profile/personal_access_tokens.md).
-This expiration date is not a requirement, and can be set to any arbitrary date.
-
-Since personal access tokens are the only token needed for programmatic access to GitLab, organizations with security requirements may want to enforce more protection to require regular rotation of these tokens.
-
-### Set a limit
-
-Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field
-is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens)
-on the lifetime of personal access tokens apply.
-
-To set a limit on how long personal access tokens are valid for users in a group managed account:
-
-1. Navigate to the **Settings > General** page in your group's sidebar.
-1. Expand the **Permissions and group features** section.
-1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
-1. Click **Save changes**.
-
-Once a lifetime for personal access tokens is set:
-
-- GitLab applies the lifetime for new personal access tokens and requires users managed by the group to set an expiration date that's no later than the allowed lifetime.
-- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the allowed lifetime. Three hours is given to allow administrators/group owner to change the allowed lifetime, or remove it, before revocation takes place.
+This [closed beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#sts=Closed%20Beta) feature was never enabled globally. See
+[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/296544) for progress on removing the feature.
+Use [SAML SSO](index.md) instead.
diff --git a/doc/user/group/saml_sso/group_sync.md b/doc/user/group/saml_sso/group_sync.md
new file mode 100644
index 00000000000..2239562b831
--- /dev/null
+++ b/doc/user/group/saml_sso/group_sync.md
@@ -0,0 +1,161 @@
+---
+type: reference, howto
+stage: Manage
+group: Authentication and Authorization
+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
+---
+
+# SAML Group Sync **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363084) for self-managed instances in GitLab 15.1.
+
+WARNING:
+Changing Group Sync configuration can remove users from the mapped GitLab group.
+Removal happens if there is any mismatch between the group names and the list of `groups` in the SAML response.
+If changes must be made, ensure either the SAML response includes the `groups` attribute
+and the `AttributeValue` value matches the **SAML Group Name** in GitLab,
+or that all groups are removed from GitLab to disable Group Sync.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For a demo of Group Sync using Azure, see [Demo: SAML Group Sync](https://youtu.be/Iqvo2tJfXjg).
+
+## Configure SAML Group Sync
+
+To configure SAML Group Sync:
+
+1. Configure SAML authentication:
+   - For GitLab self-managed, see [SAML OmniAuth Provider](../../../integration/saml.md).
+   - For GitLab.com, see [SAML SSO for GitLab.com groups](index.md).
+1. Ensure your SAML identity provider sends an attribute statement named `Groups` or `groups`.
+
+NOTE:
+The value for `Groups` or `groups` in the SAML response can be either the group name or the group ID.
+
+```xml
+<saml:AttributeStatement>
+  <saml:Attribute Name="Groups">
+    <saml:AttributeValue xsi:type="xs:string">Developers</saml:AttributeValue>
+    <saml:AttributeValue xsi:type="xs:string">Product Managers</saml:AttributeValue>
+  </saml:Attribute>
+</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.
+
+## Configure SAML Group Links
+
+When SAML is enabled, users with the Maintainer or Owner role
+see a new menu item in group **Settings > SAML Group Links**. You can configure one or more **SAML Group Links** to map
+a SAML identity provider group name to a GitLab role. This can be done for a top-level group or any subgroup.
+
+To link the SAML groups:
+
+1. In **SAML Group Name**, enter the value of the relevant `saml:AttributeValue`.
+1. Choose the role in **Access Level**.
+1. Select **Save**.
+1. Repeat to add additional group links if required.
+
+![SAML Group Links](img/saml_group_links_v13_9.png)
+
+If a user is a member of multiple SAML groups mapped to the same GitLab group,
+the user gets the highest role from the groups. For example, if one group
+is linked as Guest and another Maintainer, a user in both groups gets the Maintainer
+role.
+
+Users granted:
+
+- A higher role with Group Sync are displayed as having
+  [direct membership](../../project/members/#display-direct-members) of the group.
+- A lower or the same role with Group Sync are displayed as having
+  [inherited membership](../../project/members/#display-inherited-members) of the group.
+
+### Automatic member removal
+
+After a group sync, for GitLab subgroups, users who are not members of a mapped SAML
+group are removed from the group.
+
+FLAG:
+In [GitLab 15.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/364144), on GitLab.com, users in the top-level
+group are assigned the [default membership role](index.md#role) rather than removed. This setting is enabled with the
+`saml_group_sync_retain_default_membership` feature flag and can be configured by GitLab.com administrators only.
+
+For example, in the following diagram:
+
+- Alex Garcia signs into GitLab and is removed from GitLab Group C because they don't belong
+  to SAML Group C.
+- Sidney Jones belongs to SAML Group C, but is not added to GitLab Group C because they have
+  not yet signed in.
+
+```mermaid
+graph TB
+   subgraph SAML users
+      SAMLUserA[Sidney Jones]
+      SAMLUserB[Zhang Wei]
+      SAMLUserC[Alex Garcia]
+      SAMLUserD[Charlie Smith]
+   end
+
+   subgraph SAML groups
+      SAMLGroupA["Group A"] --> SAMLGroupB["Group B"]
+      SAMLGroupA --> SAMLGroupC["Group C"]
+      SAMLGroupA --> SAMLGroupD["Group D"]
+   end
+
+   SAMLGroupB --> |Member|SAMLUserA
+   SAMLGroupB --> |Member|SAMLUserB
+
+   SAMLGroupC --> |Member|SAMLUserA
+   SAMLGroupC --> |Member|SAMLUserB
+
+   SAMLGroupD --> |Member|SAMLUserD
+   SAMLGroupD --> |Member|SAMLUserC
+```
+
+```mermaid
+graph TB
+    subgraph GitLab users
+      GitLabUserA[Sidney Jones]
+      GitLabUserB[Zhang Wei]
+      GitLabUserC[Alex Garcia]
+      GitLabUserD[Charlie Smith]
+    end
+
+   subgraph GitLab groups
+      GitLabGroupA["Group A (SAML configured)"] --> GitLabGroupB["Group B (SAML Group Link not configured)"]
+      GitLabGroupA --> GitLabGroupC["Group C (SAML Group Link configured)"]
+      GitLabGroupA --> GitLabGroupD["Group D (SAML Group Link configured)"]
+   end
+
+   GitLabGroupB --> |Member|GitLabUserA
+
+   GitLabGroupC --> |Member|GitLabUserB
+   GitLabGroupC --> |Member|GitLabUserC
+
+   GitLabGroupD --> |Member|GitLabUserC
+   GitLabGroupD --> |Member|GitLabUserD
+```
+
+```mermaid
+graph TB
+   subgraph GitLab users
+      GitLabUserA[Sidney Jones]
+      GitLabUserB[Zhang Wei]
+      GitLabUserC[Alex Garcia]
+      GitLabUserD[Charlie Smith]
+   end
+
+   subgraph GitLab groups after Alex Garcia signs in
+      GitLabGroupA[Group A]
+      GitLabGroupA["Group A (SAML configured)"] --> GitLabGroupB["Group B (SAML Group Link not configured)"]
+      GitLabGroupA --> GitLabGroupC["Group C (SAML Group Link configured)"]
+      GitLabGroupA --> GitLabGroupD["Group D (SAML Group Link configured)"]
+   end
+
+   GitLabGroupB --> |Member|GitLabUserA
+   GitLabGroupC --> |Member|GitLabUserB
+   GitLabGroupD --> |Member|GitLabUserC
+   GitLabGroupD --> |Member|GitLabUserD
+```
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 1b480a52920..c05e847e2c9 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -176,6 +176,36 @@ If using [Group Sync](#group-sync), customize the name of the group claim to mat
 
 See the [troubleshooting page](../../../administration/troubleshooting/group_saml_scim.md#azure-active-directory) for an example configuration.
 
+### Google Workspace setup notes
+
+Follow the Google Workspace documentation on
+[setting up SSO with Google as your identity provider](https://support.google.com/a/answer/6087519?hl=en)
+with the notes below for consideration.
+
+| GitLab setting                       | Google Workspace field |
+|:-------------------------------------|:-----------------------|
+| Identifier                           | Entity ID              |
+| Assertion consumer service URL       | ACS URL                |
+| GitLab single sign-on URL            | Start URL              |
+| Identity provider single sign-on URL | SSO URL                |
+
+You must download the certificate to get the SHA1 certificate fingerprint.
+
+The recommended attributes and claims settings are:
+
+- **Primary email** set to `email`.
+- **First name** set to `first_name`.
+- **Last name** set to `last_name`.
+
+For NameID, the following settings are recommended:
+
+- **Name ID format** is set to `EMAIL`.
+- **NameID** set to `Basic Information > Primary email`.
+
+When selecting **Verify SAML Configuration** on the GitLab SAML SSO page, disregard the warning recommending setting the NameID format to "persistent".
+
+See the [troubleshooting page](../../../administration/troubleshooting/group_saml_scim.md#google-workspace) for an example configuration.
+
 ### 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/main/) with the notes below for consideration.
@@ -342,7 +372,7 @@ To rescind a user's access to the group when only SAML SSO is configured, either
 - Remove (in order) the user from:
   1. The user data store on the identity provider or the list of users on the specific app.
   1. The GitLab.com group.
-- Use Group Sync at the top-level of your group to [automatically remove the user](#automatic-member-removal).
+- Use Group Sync at the top-level of your group to [automatically remove the user](group_sync.md#automatic-member-removal).
 
 To rescind a user's access to the group when also using SCIM, refer to [Blocking access](scim_setup.md#blocking-access).
 
@@ -372,149 +402,7 @@ For example, to unlink the `MyOrg` account:
 
 ## Group Sync
 
-WARNING:
-Changing Group Sync configuration can remove users from the relevant GitLab group.
-Removal happens if there is any mismatch between the group names and the list of `groups` in the SAML response.
-If changes must be made, ensure either the SAML response includes the `groups` attribute
-and the `AttributeValue` value matches the **SAML Group Name** in GitLab,
-or that all groups are removed from GitLab to disable Group Sync.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For a demo of Group Sync using Azure, see [Demo: SAML Group Sync](https://youtu.be/Iqvo2tJfXjg).
-
-When the SAML response includes a user and their group memberships from the SAML identity provider,
-GitLab uses that information to automatically manage that user's GitLab group memberships.
-
-Ensure your SAML identity provider sends an attribute statement named `Groups` or `groups` like the following:
-
-```xml
-<saml:AttributeStatement>
-  <saml:Attribute Name="Groups">
-    <saml:AttributeValue xsi:type="xs:string">Developers</saml:AttributeValue>
-    <saml:AttributeValue xsi:type="xs:string">Product Managers</saml:AttributeValue>
-  </saml:Attribute>
-</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).
-
-When SAML SSO is enabled for the top-level group, `Maintainer` and `Owner` level users
-see a new menu item in group **Settings > SAML Group Links**. You can configure one or more **SAML Group Links** to map
-a SAML identity provider group name to a GitLab Access Level. This can be done for the parent group or the subgroups.
-
-To link the SAML groups from the `saml:AttributeStatement` example above:
-
-1. In the **SAML Group Name** box, enter the value of `saml:AttributeValue`.
-1. Choose the desired **Access Level**.
-1. **Save** the group link.
-1. Repeat to add additional group links if desired.
-
-![SAML Group Links](img/saml_group_links_v13_9.png)
-
-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.
-
-Users granted:
-
-- A higher role with Group Sync are displayed as having
-  [direct membership](../../project/members/#display-direct-members) of the group.
-- A lower or the same role with Group Sync are displayed as having
-  [inherited membership](../../project/members/#display-inherited-members) of the group.
-
-### Automatic member removal
-
-After a group sync, users who are not members of a mapped SAML group are removed from
-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:
-
-- Alex Garcia signs into GitLab and is removed from GitLab Group C because they don't belong
-  to SAML Group C.
-- Sidney Jones belongs to SAML Group C, but is not added to GitLab Group C because they have
-  not yet signed in.
-
-```mermaid
-graph TB
-   subgraph SAML users
-      SAMLUserA[Sidney Jones]
-      SAMLUserB[Zhang Wei]
-      SAMLUserC[Alex Garcia]
-      SAMLUserD[Charlie Smith]
-   end
-
-   subgraph SAML groups
-      SAMLGroupA["Group A"] --> SAMLGroupB["Group B"]
-      SAMLGroupA --> SAMLGroupC["Group C"]
-      SAMLGroupA --> SAMLGroupD["Group D"]
-   end
-
-   SAMLGroupB --> |Member|SAMLUserA
-   SAMLGroupB --> |Member|SAMLUserB
-
-   SAMLGroupC --> |Member|SAMLUserA
-   SAMLGroupC --> |Member|SAMLUserB
-
-   SAMLGroupD --> |Member|SAMLUserD
-   SAMLGroupD --> |Member|SAMLUserC
-```
-
-```mermaid
-graph TB
-    subgraph GitLab users
-      GitLabUserA[Sidney Jones]
-      GitLabUserB[Zhang Wei]
-      GitLabUserC[Alex Garcia]
-      GitLabUserD[Charlie Smith]
-    end
-
-   subgraph GitLab groups
-      GitLabGroupA["Group A (SAML configured)"] --> GitLabGroupB["Group B (SAML Group Link not configured)"]
-      GitLabGroupA --> GitLabGroupC["Group C (SAML Group Link configured)"]
-      GitLabGroupA --> GitLabGroupD["Group D (SAML Group Link configured)"]
-   end
-
-   GitLabGroupB --> |Member|GitLabUserA
-
-   GitLabGroupC --> |Member|GitLabUserB
-   GitLabGroupC --> |Member|GitLabUserC
-
-   GitLabGroupD --> |Member|GitLabUserC
-   GitLabGroupD --> |Member|GitLabUserD
-```
-
-```mermaid
-graph TB
-   subgraph GitLab users
-      GitLabUserA[Sidney Jones]
-      GitLabUserB[Zhang Wei]
-      GitLabUserC[Alex Garcia]
-      GitLabUserD[Charlie Smith]
-   end
-
-   subgraph GitLab groups after Alex Garcia signs in
-      GitLabGroupA[Group A]
-      GitLabGroupA["Group A (SAML configured)"] --> GitLabGroupB["Group B (SAML Group Link not configured)"]
-      GitLabGroupA --> GitLabGroupC["Group C (SAML Group Link configured)"]
-      GitLabGroupA --> GitLabGroupD["Group D (SAML Group Link configured)"]
-   end
-
-   GitLabGroupB --> |Member|GitLabUserA
-   GitLabGroupC --> |Member|GitLabUserB
-   GitLabGroupD --> |Member|GitLabUserC
-   GitLabGroupD --> |Member|GitLabUserD
-```
+For information on automatically managing GitLab group membership, see [SAML Group Sync](group_sync.md).
 
 ## Passwords for users created via SAML SSO for Groups
 
@@ -528,8 +416,8 @@ This section contains possible solutions for problems you might encounter.
 
 SAML responses are base64 encoded, so we recommend the following browser plugins to decode them on the fly:
 
-- [SAML tracer for Firefox](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)
-- [Chrome SAML Panel](https://chrome.google.com/webstore/detail/saml-chrome-panel/paijfdbeoenhembfhkhllainmocckace?hl=en)
+- [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) for Firefox.
+- [SAML Message Decoder](https://chrome.google.com/webstore/detail/saml-message-decoder/mpabchoaimgbdbbjjieoaeiibojelbhm?hl=en) for Chrome.
 
 Specific attention should be paid to:
 
@@ -548,7 +436,7 @@ To generate a SAML Response:
    - [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.
+   - Chrome: Right-click on the page, select **Inspect**, then select 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
@@ -569,6 +457,10 @@ This can then be compared to the [NameID](#nameid) being sent by the identity pr
 
 ### Users receive a 404
 
+Because SAML SSO for groups is a paid feature, your subscription expiring can result in a `404` error when you're signing in using SAML SSO on GitLab.com.
+If all users are receiving a `404` when attempting to log in using SAML, confirm
+[there is an active subscription](../../../subscriptions/gitlab_com/index.md#view-your-gitlab-saas-subscription) being used in this SAML SSO namespace.
+
 If you receive a `404` during setup when using "verify configuration", make sure you have used the correct
 [SHA-1 generated fingerprint](../../../integration/saml.md#notes-on-configuring-your-identity-provider).
 
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index bc1799c2e54..cc154b96ed0 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -82,7 +82,7 @@ table, use the Azure defaults. For a list of required attributes, refer to the [
 
 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. Below the mapping list select **Show advanced options > Edit attribute list for AppName**.
 1. Ensure the `id` is the primary and required field, and `externalId` is also required.
 
    NOTE:
@@ -112,7 +112,7 @@ After the above steps are complete:
 1. Sign in to Okta.
 1. Ensure you are in the Admin Area by selecting the **Admin** button located in the top right. The button is not visible from the Admin Area.
 1. In the **Application** tab, select **Browse App Catalog**.
-1. Search for **GitLab**, find and select on the 'GitLab' application.
+1. Search for **GitLab**, find and select 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.
 1. Select **Done** to finish adding the application.
diff --git a/doc/user/group/settings/group_access_tokens.md b/doc/user/group/settings/group_access_tokens.md
index 4b791d5a221..649e7f2c264 100644
--- a/doc/user/group/settings/group_access_tokens.md
+++ b/doc/user/group/settings/group_access_tokens.md
@@ -36,7 +36,7 @@ You can use group access tokens:
   - Consider [disabling group access tokens](#enable-or-disable-group-access-token-creation) to
     lower potential abuse.
 
-You cannot use group access tokens to create other access tokens.
+You cannot use group access tokens to create other group, project, or personal access tokens.
 
 Group access tokens inherit the [default prefix setting](../../admin_area/settings/account_and_limit_settings.md#personal-access-token-prefix)
 configured for personal access tokens.
@@ -147,9 +147,12 @@ Even when creation is disabled, you can still use and revoke existing group acce
 
 ## Bot users for groups
 
-Each time you create a group access token, a bot user is created and added to the group.
-These bot users are similar to [bot users for projects](../../project/settings/project_access_tokens.md#bot-users-for-projects),
-except they are added to groups instead of projects.
-These bot users do not count as licensed seats.
+Each time you create a group access token, a bot user is created and added to the group. These bot users are similar to
+[bot users for projects](../../project/settings/project_access_tokens.md#bot-users-for-projects), except they are added
+to groups instead of projects. Bot users for groups:
+
+- Do not count as licensed seats.
+- Can have a maximum role of Owner for a group. For more information, see
+  [Create a group access token](../../../api/group_access_tokens.md#create-a-group-access-token).
 
 For more information, see [Bot users for projects](../../project/settings/project_access_tokens.md#bot-users-for-projects).
diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md
index 23a638fb98c..eb94a181647 100644
--- a/doc/user/group/settings/import_export.md
+++ b/doc/user/group/settings/import_export.md
@@ -1,16 +1,24 @@
 ---
-type: reference
 stage: Manage
 group: Import
 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 import/export **(FREE)**
+# Migrating groups using file exports (deprecated) **(FREE)**
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2888) in GitLab 13.0 as an experimental feature. May change in future releases.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2888) in GitLab 13.0 as an experimental feature. May change in future releases.
+> - [Deprecated](https://gitlab.com/groups/gitlab-org/-/epics/4619) in GitLab 14.6.
 
-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).
+WARNING:
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/4619) in GitLab 14.6 and replaced by
+[a different migration method](../import/index.md). To follow progress on a solution for
+[offline environments](../../application_security/offline_deployments/index.md), see
+[the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/363406).
+
+You can export groups, with all their related data, from one GitLab instance to another. You can also:
+
+- [Migrate groups](../import/index.md) using the preferred method.
+- [Migrate projects using file exports](../../project/settings/import_export.md).
 
 ## Enable export for a group
 
@@ -63,10 +71,6 @@ For more details on the specific data persisted in a group export, see the
 
 ## Export a group
 
-WARNING:
-This feature will be [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/4619)
-in GitLab 14.6 and replaced by [GitLab Migration](../import/).
-
 Prerequisites:
 
 - You must have the Owner role for the group.
@@ -96,16 +100,11 @@ You can export groups from the [Community Edition to the Enterprise Edition](htt
 
 The Enterprise Edition retains some group data that isn't part of the Community Edition. If you're exporting a group from the Enterprise Edition to the Community Edition, you may lose this data. For more information, see [downgrading from EE to CE](../../../index.md).
 
-## 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/).
+## Import the group
 
 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.
-
 1. Select **Import group**.
 1. Enter your group name.
 1. Accept or modify the associated group URL.
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index 4be97779603..72d42a8081f 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -50,9 +50,8 @@ To view value stream analytics for your group:
       - In the **To** field, select an end date. The charts and list show workflow items created
         during the date range.
 1. Optional. Sort results by ascending or descending:
-      - To sort by most recent or oldest workflow item, select the **Merge requests** or **Issues**
-        header. The header name differs based on the stage you select.
-      - To sort by most or least amount of time spent in each stage, select the **Time** header.
+      - To sort by most recent or oldest workflow item, select the **Last event** header.
+      - To sort by most or least amount of time spent in each stage, select the **Duration** header.
 
 A badge next to the workflow items table header shows the number of workflow items that
 completed during the selected stage.
@@ -366,7 +365,7 @@ The chart shows data for the last 500 workflow items.
       - In the **From** field, select a start date.
       - In the **To** field, select an end date.
 
-## Type of work - Tasks by type chart
+## Tasks by type chart
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32421) in GitLab 12.10.