Mention restricted users in the faq

Signed-off-by: Manush Dodunekov <manush@stendahls.se>

docs/content/doc/help/faq.en-us.md

@@ -31,6 +31,7 @@ Also see [Support Options]({{< relref "doc/help/seek-help.en-us.md" >}})
   * [Only allow certain email domains](#only-allow-certain-email-domains)
   * [Only allow/block certain OpenID providers](#only-allow-block-certain-openid-providers)
   * [Issue only users](#issue-only-users)
+  * [Restricted users](#restricted-users)
   * [Enable Fail2ban](#enable-fail2ban)
 * [Adding custom themes](#how-to-add-use-custom-themes)
 * [SSHD vs built-in SSH](#sshd-vs-built-in-ssh)
@@ -147,6 +148,14 @@ You can configure `WHITELISTED_URIS` or `BLACKLISTED_URIS` under `[openid]` in y
 ### Issue only users
 The current way to achieve this is to create/modify a user with a max repo creation limit of 0.
 
+### Restricted users
+Restricted users are limited to a subset of the content based on their organization/team memberships and collaborations, ignoring the public flag on organizations/repos etc.__
+
+Example use case: A company runs a Gitea instance that requires login. Most repos are public (accessible/browseable by all co-workers).
+
+At some point, a customer or third party needs access to a specific repo and only that repo. Making such a customer account restricted and granting any needed access using team membership(s) and/or collaboration(s) is a simple way to achieve that without the need to make everything private.
+
+
 ### Enable Fail2ban
 
 Use [Fail2Ban]({{ relref "doc/usage/fail2ban-setup.md" >}}) to monitor and stop automated login attempts or other malicious behavior based on log patterns