Add latest changes from gitlab-org/gitlab@13-4-stable-ee

14 files changed, 153 insertions, 63 deletions

diff --git a/doc/user/group/bulk_editing/index.md b/doc/user/group/bulk_editing/index.md
index 35bdc6696eb..ec1e81bac2d 100644
--- a/doc/user/group/bulk_editing/index.md
+++ b/doc/user/group/bulk_editing/index.md
@@ -13,6 +13,9 @@ For more details, see [Bulk editing issues and merge requests at the project lev
 If you want to update attributes across multiple issues, epics, or merge requests in a group, you
 can do it by bulk editing them, that is, editing them together.
 
+NOTE: **Note:**
+Only the items visible on the current page are selected for bulk editing (up to 20).
+
 ![Bulk editing](img/bulk-editing_v13_2.png)
 
 ## Bulk edit issues at the group level
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index e61b24f84f6..ebf38aef4a6 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -46,7 +46,7 @@ You can associate more than one Kubernetes cluster to your group, and maintain d
 for different environments, such as development, staging, and production.
 
 When adding another cluster,
-[set an environment scope](#environment-scopes-premium) to help
+[set an environment scope](#environment-scopes) to help
 differentiate the new cluster from your other clusters.
 
 ## GitLab-managed clusters
@@ -162,10 +162,10 @@ For a consolidated view of which CI [environments](../../../ci/environments/inde
 are deployed to the Kubernetes cluster, see the documentation for
 [cluster environments](../../clusters/environments.md).
 
-## Security of Runners
+## Security of runners
 
-For important information about securely configuring GitLab Runners, see
-[Security of Runners](../../project/clusters/add_remove_clusters.md#security-of-gitlab-runners)
+For important information about securely configuring runners, see
+[Security of runners](../../project/clusters/add_remove_clusters.md#security-of-runners)
 documentation for project-level clusters.
 
 ## More information
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index 04b57d13828..e8bcb7219fc 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -48,14 +48,14 @@ To learn what you can do with an epic, see [Manage epics](manage_epics.md). Poss
 - [Search for an epic from epics list page](manage_epics.md#search-for-an-epic-from-epics-list-page)
 - [Make an epic confidential](manage_epics.md#make-an-epic-confidential)
 - [Manage issues assigned to an epic](manage_epics.md#manage-issues-assigned-to-an-epic)
-- [Manage multi-level child epics **(ULTIMATE)**](manage_epics.md#manage-multi-level-child-epics-ultimate)
+- [Manage multi-level child epics **(ULTIMATE)**](manage_epics.md#manage-multi-level-child-epics)
 
 ## Relationships between epics and issues
 
 The possible relationships between epics and issues are:
 
 - An epic is the parent of one or more issues.
-- An epic is the parent of one or more child epics. For details see [Multi-level child epics](#multi-level-child-epics-ultimate). **(ULTIMATE)**
+- An epic is the parent of one or more child epics. For details see [Multi-level child epics](#multi-level-child-epics). **(ULTIMATE)**
 
 ```mermaid
 graph TD
@@ -73,7 +73,7 @@ to add an issue to an epic, reorder issues, move issues between epics, or promot
 > - The health status of a closed issue [will be hidden](https://gitlab.com/gitlab-org/gitlab/-/issues/220867) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.3 or later.
 
 You can report on and quickly respond to the health of individual issues and epics by setting a
-red, amber, or green [health status on an issue](../../project/issues/index.md#health-status-ultimate),
+red, amber, or green [health status on an issue](../../project/issues/index.md#health-status),
 which will appear on your Epic tree.
 
 ### Disable Issue health status in Epic tree
@@ -92,7 +92,7 @@ When you add an epic that's already linked to a parent epic, the link to its cur
 
 An epic can have multiple child epics up to the maximum depth of five.
 
-See [Manage multi-level child epics](manage_epics.md#manage-multi-level-child-epics-ultimate) for
+See [Manage multi-level child epics](manage_epics.md#manage-multi-level-child-epics) for
 steps to create, move, reorder, or delete child epics.
 
 ## Start date and due date
@@ -145,7 +145,7 @@ then the parent epic's start date will reflect the change and this will propagat
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7327) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.10.
 
-If your epic contains one or more [child epics](#multi-level-child-epics-ultimate) which
+If your epic contains one or more [child epics](#multi-level-child-epics) which
 have a [start or due date](#start-date-and-due-date), a
 [roadmap](../roadmap/index.md) view of the child epics is listed under the parent epic.
 
diff --git a/doc/user/group/epics/manage_epics.md b/doc/user/group/epics/manage_epics.md
index aaa5d3a3034..c09032bffb2 100644
--- a/doc/user/group/epics/manage_epics.md
+++ b/doc/user/group/epics/manage_epics.md
@@ -164,21 +164,9 @@ To make an epic confidential:
 - **In an existing epic:** in the epic's sidebar, select **Edit** next to **Confidentiality** then
   select **Turn on**.
 
-### Disable confidential epics **(PREMIUM ONLY)**
-
-The confidential epics feature is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can disable it for your self-managed instance.
-
-To disable it:
-
-```ruby
-Feature.disable(:confidential_epics)
-```
-
 ## Manage issues assigned to an epic
 
-### Add an issue to an epic
+### Add a new issue to an epic
 
 You can add an existing issue to an epic, or, create a new issue that's
 automatically added to the epic.
@@ -190,13 +178,13 @@ subgroups, are eligible to be added to the epic. Newly added issues appear at th
 issues in the **Epics and Issues** tab.
 
 An epic contains a list of issues and an issue can be associated with at most one epic.
-When you add an issue that's already linked to an epic, the issue is automatically unlinked from its
+When you add a new issue that's already linked to an epic, the issue is automatically unlinked from its
 current parent.
 
-To add an issue to an epic:
+To add a new issue to an epic:
 
 1. Click the **Add** dropdown button.
-1. Click **Add an issue**.
+1. Click **Add a new issue**.
 1. Identify the issue to be added, using either of the following methods:
    - Paste the link of the issue.
    - Search for the desired issue by entering part of the issue's title, then selecting the desired
@@ -298,7 +286,7 @@ For more on epic templates, see [Epic Templates - Repeatable sets of issues](htt
 To add a child epic to an epic:
 
 1. Click the **Add** dropdown button.
-1. Click **Add an epic**.
+1. Click **Add a new epic**.
 1. Identify the epic to be added, using either of the following methods:
    - Paste the link of the epic.
    - Search for the desired issue by entering part of the epic's title, then selecting the desired
@@ -313,7 +301,7 @@ To add a child epic to an epic:
 
 New child epics appear at the top of the list in the **Epics and Issues** tab.
 You can move child epics from one epic to another.
-When you add an epic that's already linked to a parent epic, the link to its current parent is removed.
+When you add a new epic that's already linked to a parent epic, the link to its current parent is removed.
 Issues and child epics cannot be intermingled.
 
 To move child epics to another epic:
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 22ad311ab4f..32b76cf9280 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -227,7 +227,7 @@ To change this setting for a specific group:
 To change this setting globally, see [Default branch protection](../admin_area/settings/visibility_and_access_controls.md#default-branch-protection).
 
 NOTE: **Note:**
-In [GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can choose to [disable group owners from updating the default branch protection](../admin_area/settings/visibility_and_access_controls.md#disable-group-owners-from-updating-default-branch-protection-premium-only).
+In [GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can choose to [disable group owners from updating the default branch protection](../admin_area/settings/visibility_and_access_controls.md#disable-group-owners-from-updating-default-branch-protection).
 
 ## Add projects to a group
 
@@ -340,7 +340,7 @@ Group syncing allows LDAP groups to be mapped to GitLab groups. This provides mo
 
 Group links can be created using either a CN or a filter. These group links are created on the **Group Settings -> LDAP Synchronization** page. After configuring the link, it may take over an hour for the users to sync with the GitLab group.
 
-For more information on the administration of LDAP and group sync, refer to the [main LDAP documentation](../../administration/auth/ldap/index.md#group-sync-starter-only).
+For more information on the administration of LDAP and group sync, refer to the [main LDAP documentation](../../administration/auth/ldap/index.md#group-sync).
 
 NOTE: **Note:**
 If an LDAP user is a group member when LDAP Synchronization is added, and they are not part of the LDAP group, they will be removed from the group.
@@ -363,7 +363,7 @@ To create group links via filter:
 
 1. Select the **LDAP Server** for the link.
 1. Select `LDAP user filter` as the **Sync method**.
-1. Input your filter in the **LDAP User filter** box. Follow the [documentation on user filters](../../administration/auth/ldap/index.md#set-up-ldap-user-filter-core-only).
+1. Input your filter in the **LDAP User filter** box. Follow the [documentation on user filters](../../administration/auth/ldap/index.md#set-up-ldap-user-filter).
 1. In the **LDAP Access** section, select the [permission level](../permissions.md) for users synced in this group.
 1. Click the `Add Synchronization` button to save this group link.
 
@@ -480,7 +480,7 @@ To remove a group and its contents:
 This action either:
 
 - Removes the group, and also queues a background job to delete all projects in that group.
-- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/premium/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only).
+- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/premium/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
 
 ### Restore a group **(PREMIUM)**
 
@@ -660,7 +660,7 @@ Optionally, on [Premium or Silver](https://about.gitlab.com/pricing/) or higher
 you can configure the projects within a group to be deleted after a delayed interval.
 
 During this interval period, the projects will be in a read-only state and can be restored, if required.
-The interval period defaults to 7 days, and can be modified by an admin in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only).
+The interval period defaults to 7 days, and can be modified by an admin in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
 
 To enable delayed deletion of projects:
 
@@ -668,6 +668,9 @@ To enable delayed deletion of projects:
 1. Expand the **Permissions, LFS, 2FA** section, and check **Enable delayed project removal**.
 1. Click **Save changes**.
 
+NOTE: **Note:**
+The group setting for delayed deletion is not inherited by sub-groups and has to be individually defined for each group.
+
 #### Prevent project forking outside group **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216987) in GitLab 13.3.
@@ -711,7 +714,8 @@ If your namespace shows `N/A` as the total storage usage, you can trigger a reca
 
 #### Group push rules **(STARTER)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34370) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.8.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34370) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.8.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/224129) in GitLab 13.4.
 
 Group push rules allow group maintainers to set
 [push rules](../../push_rules/push_rules.md) for newly created projects within the specific group.
@@ -724,18 +728,10 @@ When set, 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.
 
-##### Enabling the feature
-
-This feature comes with the `:group_push_rules` feature flag disabled by default. It can be enabled for specific group using feature flag [API endpoint](../../api/features.md#set-or-create-a-feature) or by GitLab administrator with Rails console access by running:
-
-```ruby
-Feature.enable(:group_push_rules)
-```
-
 ### Maximum artifacts size **(CORE ONLY)**
 
 For information about setting a maximum artifact size for a group, see
-[Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+[Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size).
 
 ## User contribution analysis **(STARTER)**
 
@@ -747,6 +743,12 @@ and issues) performed by your group members.
 
 With [GitLab Issue Analytics](issues_analytics/index.md), you can see a bar chart of the number of issues created each month in your groups.
 
+## Repositories analytics **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215104) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
+
+With [GitLab Repositories Analytics](repositories_analytics/index.md), you can download a CSV of the latest coverage data for all the projects in your group.
+
 ## Dependency Proxy **(PREMIUM)**
 
 Use GitLab as a [dependency proxy](../packages/dependency_proxy/index.md) for upstream Docker images.
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index f04472a29bb..20cbc043d83 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - It's enabled on GitLab.com.
 > - It's able to be enabled or disabled per-group.
 > - It's recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-iterations-core-only). **(CORE ONLY)**
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-iterations). **(CORE ONLY)**
 
 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)
@@ -62,7 +62,7 @@ To edit an iteration, click the three-dot menu (**{ellipsis_v}**) > **Edit itera
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216158) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.2.
 
 To learn how to add an issue to an iteration, see the steps in
-[Managing issues](../../project/issues/managing_issues.md#add-an-issue-to-an-iteration-starter).
+[Managing issues](../../project/issues/managing_issues.md#add-an-issue-to-an-iteration).
 
 ## Disable Iterations **(CORE ONLY)**
 
@@ -76,7 +76,7 @@ To enable it:
 # Instance-wide
 Feature.enable(:group_iterations)
 # or by group
-Feature.enable(:group_iterations, Group.find(<group id>))
+Feature.enable(:group_iterations, Group.find(<group ID>))
 ```
 
 To disable it:
@@ -85,7 +85,7 @@ To disable it:
 # Instance-wide
 Feature.disable(:group_iterations)
 # or by group
-Feature.disable(:group_iterations, Group.find(<group id>))
+Feature.disable(:group_iterations, Group.find(<group ID>))
 ```
 
 <!-- ## Troubleshooting
diff --git a/doc/user/group/repositories_analytics/index.md b/doc/user/group/repositories_analytics/index.md
new file mode 100644
index 00000000000..b013e371ed2
--- /dev/null
+++ b/doc/user/group/repositories_analytics/index.md
@@ -0,0 +1,67 @@
+---
+type: reference
+stage: Verify
+group: Analytics
+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/#designated-technical-writers
+---
+
+# Repositories Analytics **(PREMIUM)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215104) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
+> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
+> - It's enabled on GitLab.com.
+> - It's recommended for production use.
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-repositories-analytics). **(CORE ONLY)**
+
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+You can get a CSV of the code coverage data for all of the projects in your group. This report has a maximum of 1000 records. To get the report:
+
+1. Go to your group's **Analytics > Repositories** page
+1. Click **Download historic test coverage data (.csv)**,
+1. In the popup, select the projects you want to include in the report.
+1. Select the date range for the report from the preset options.
+1. Click **Download test coverage data (.csv)**.
+
+The projects dropdown shows up to 100 projects from your group. If the project you want to check is not in the dropdown list, you can select **All projects** to download the report for all projects in your group, including any projects that are not listed. There is a plan to improve this behavior in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/250684).
+
+For each day that a coverage report was generated by a job in a project's pipeline, there will be a row in the CSV which includes:
+
+- The date when the coverage job ran
+- The name of the job that generated the coverage report
+- The name of the project
+- The coverage value
+
+If the project's code coverage was calculated more than once in a day, we will take the last value from that day.
+
+## Enable or disable Repositories Analytics **(CORE ONLY)**
+
+Repositories Analytics is under development but ready for production use.
+It is deployed behind a feature flag that is **enabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can opt to disable it.
+
+To enable it:
+
+```ruby
+Feature.enable(:group_coverage_reports)
+```
+
+To disable it:
+
+```ruby
+Feature.disable(:group_coverage_reports)
+```
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index 126970ebbb6..7497d036d31 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Group Managed Accounts **(PREMIUM)**
 
 CAUTION: **Caution:**
-This [Closed Beta](https://about.gitlab.com/handbook/product/#closed-beta) feature is being re-evaluated in favor of a different
+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
 [identity model](https://gitlab.com/gitlab-org/gitlab/-/issues/218631) that does not require separate accounts.
 We recommend that group administrators who haven't yet implemented this feature wait for
 the new solution.
@@ -76,7 +76,8 @@ This restriction also applies to projects forked from or to those groups.
 
 Groups with group-managed accounts can disallow forking of projects to destinations outside the group.
 To do so, enable the "Prohibit outer forks" option in **Settings > SAML SSO**.
-When enabled, projects within the group can only be forked to other destinations within the group (including its subgroups).
+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)**
 
@@ -104,7 +105,7 @@ Since personal access tokens are the only token needed for programmatic access t
 
 ### Setting 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#limiting-lifetime-of-personal-access-tokens-ultimate-only) on the lifetime of personal access tokens apply.
+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#limiting-lifetime-of-personal-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:
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index f516f4080fa..57b9cc92c51 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -274,10 +274,10 @@ Group SAML on a self-managed instance is limited when compared to the recommende
 [instance-wide SAML](../../../integration/saml.md). The recommended solution allows you to take advantage of:
 
 - [LDAP compatibility](../../../administration/auth/ldap/index.md).
-- [LDAP Group Sync](../index.md#manage-group-memberships-via-ldap-starter-only).
-- [Required groups](../../../integration/saml.md#required-groups-starter-only).
-- [Admin groups](../../../integration/saml.md#admin-groups-starter-only).
-- [Auditor groups](../../../integration/saml.md#auditor-groups-starter-only).
+- [LDAP Group Sync](../index.md#manage-group-memberships-via-ldap).
+- [Required groups](../../../integration/saml.md#required-groups).
+- [Admin groups](../../../integration/saml.md#admin-groups).
+- [Auditor groups](../../../integration/saml.md#auditor-groups).
 
 ### Omnibus installations
 
@@ -361,7 +361,7 @@ Here are possible causes and solutions:
 
 Getting both of these errors at the same time suggests the NameID capitalization provided by the Identity Provider didn't exactly match the previous value for that user.
 
-This can be prevented by configuring the [NameID](#nameid) to return a consistent value. Fixing this for an individual user involves [unlinking SAML in the GitLab account](#unlinking-accounts), although this will cause group membership and Todos to be lost.
+This can be prevented by configuring the [NameID](#nameid) to return a consistent value. Fixing this for an individual user involves [unlinking SAML in the GitLab account](#unlinking-accounts), although this will cause group membership and to-dos to be lost.
 
 ### Message: "Request to link SAML account must be authorized"
 
@@ -377,7 +377,7 @@ Alternatively, when users need to [link SAML to their existing GitLab.com accoun
 
 | Cause                                                                                                                                                                                     | Solution                                                                                                                                                                                                                                           |
 |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| As mentioned in the [NameID](#nameid) section, if the NameID changes for any user, the user can be locked out. This is a common problem when an email address is used as the identifier. | Follow the steps outlined in the ["SAML authentication failed: User has already been taken"](#message-saml-authentication-failed-user-has-already-been-taken) section. If many users are affected, we recommend that you use the appropriate API. |
+| As mentioned in the [NameID](#nameid) section, if the NameID changes for any user, the user can be locked out. This is a common problem when an email address is used as the identifier. | Follow the steps outlined in the ["SAML authentication failed: User has already been taken"](#message-saml-authentication-failed-user-has-already-been-taken) section. |
 
 ### I need to change my SAML app
 
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 9a2bd2e8806..4f74e672392 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -159,7 +159,16 @@ application described above.
 
 ## User access and linking setup
 
-As long as [Group SAML](index.md) has been configured, prior to turning on sync, existing GitLab.com users can link to their accounts in one of the following ways, before synchronization is active:
+The following diagram is a general outline on what happens when you add users to your SCIM app:
+
+```mermaid
+graph TD
+  A[Add User to SCIM app] -->|IdP sends user info to GitLab| B(GitLab: Does the email exists?)
+  B -->|No| C[GitLab creates user with SCIM identity]
+  B -->|Yes| D[GitLab sends message back 'Email exists']
+```
+
+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:
@@ -168,21 +177,41 @@ As long as [Group SAML](index.md) has been configured, prior to turning on sync,
   1. Click on the GitLab app in the identity provider's dashboard or visit the **GitLab single sign-on URL**.
   1. Click on the **Authorize** button.
 
+We recommend users do this prior to turning on sync, because while synchronization is active, there may be provisioning errors for existing users.
+
 New users and existing users on subsequent visits can access the group through the identify provider's dashboard or by visiting links directly.
 
 For role information, please see the [Group SAML page](index.md#user-access-and-management)
 
 ### Blocking access
 
-To rescind access to the group, we recommend removing the user from the identity
+To rescind access to the group, remove the user from the identity
 provider or users list for the specific app.
 
-Upon the next sync, the user will be deprovisioned, which means that the user will be removed from the group. The user account will not be deleted unless using [group managed accounts](group_managed_accounts.md).
+Upon the next sync, the user is deprovisioned, which means that the user is removed from the group.
+
+NOTE: **Note:**
+Deprovisioning does not delete the user account.
+
+```mermaid
+graph TD
+  A[Remove User from SCIM app] -->|IdP sends request to GitLab| B(GitLab: Is the user part of the group?)
+  B -->|No| C[Nothing to do]
+  B -->|Yes| D[GitLab removes user from GitLab group]
+```
 
 ## Troubleshooting
 
 This section contains possible solutions for problems you might encounter.
 
+### How come I can't add a user after I removed them?
+
+As outlined in the [Blocking access section](#blocking-access), when you remove a user, they are removed from the group. However, their account is not deleted.
+
+When the user is added back to the SCIM app, GitLab cannot create a new user because the user already exists.
+
+Solution: Have a user sign in directly to GitLab, then [manually link](#user-access-and-linking-setup) their account.
+
 ### Azure
 
 #### How do I verify my SCIM configuration is correct?
@@ -236,7 +265,7 @@ Alternatively, the [SCIM API](../../../api/scim.md#get-a-list-of-saml-users) can
 For example:
 
 ```shell
-curl 'https://example.gitlab.com/api/scim/v2/groups/GROUP_NAME/Users?startIndex=1"' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
+curl 'https://gitlab.example.com/api/scim/v2/groups/GROUP_NAME/Users?startIndex=1"' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
 To see how this compares to the value returned as the SAML NameId, you can have the user use a [SAML Tracer](index.md#saml-debugging-tools).
diff --git a/doc/user/group/settings/img/import_panel_v13_1.png b/doc/user/group/settings/img/import_panel_v13_1.png
deleted file mode 100644
index ce2eb579446..00000000000
--- a/doc/user/group/settings/img/import_panel_v13_1.png
+++ /dev/null
diff --git a/doc/user/group/settings/img/import_panel_v13_4.png b/doc/user/group/settings/img/import_panel_v13_4.png
new file mode 100644
index 00000000000..e4e5b0e91a1
--- /dev/null
+++ b/doc/user/group/settings/img/import_panel_v13_4.png
diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md
index ae83c8da462..77cb862a49d 100644
--- a/doc/user/group/settings/import_export.md
+++ b/doc/user/group/settings/import_export.md
@@ -52,7 +52,7 @@ The following items are exported:
 The following items are **not** exported:
 
 - Projects
-- Runners token
+- Runner tokens
 - SAML discovery tokens
 
 NOTE: **Note:**
@@ -94,7 +94,7 @@ on an existing group's page.
 
 1. On the New Group page, select the **Import group** tab.
 
-   ![Fill in group details](img/import_panel_v13_1.png)
+   ![Fill in group details](img/import_panel_v13_4.png)
 
 1. Enter your group name.
 
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 235855b6e3a..6de38354c5e 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -115,10 +115,10 @@ When you add a member to a subgroup, they inherit the membership and permission
 level from the parent group(s). This model allows access to nested groups if you
 have membership in one of its parents.
 
-Jobs for pipelines in subgroups can use [Runners](../../../ci/runners/README.md) registered to the parent group(s).
+Jobs for pipelines in subgroups can use [runners](../../../ci/runners/README.md) registered to the parent group(s).
 This means secrets configured for the parent group are available to subgroup jobs.
 
-In addition, maintainers of projects that belong to subgroups can see the details of Runners registered to parent group(s).
+In addition, maintainers of projects that belong to subgroups can see the details of runners registered to parent group(s).
 
 The group permissions for a member can be changed only by Owners, and only on
 the **Members** page of the group the member was added.