docs: proposal restructure (#5318)

* docs: docs structure

* docs: remove sdk from main nav

* docs: fix broken links

* docs: texts

* docs: texts

* docs: react example

* docs: proposal restructure

* remove manual, move troubleshooting

* revmove duplicate item

* identity providers

* broken links and rel paths

* examples wip

* examples

* navigation

* support

* solution scenarios

* concepts

* overview

* Actions caution to info

* suggestions from code review

* remove start command again

* proposed start command (with and without api)

* wip startpage

* startpage

* broken link integrate

* remove get started from nav

* Apply suggestions from code review

Co-authored-by: Elio Bischof <elio@zitadel.com>

---------

Co-authored-by: Fabienne <fabienne.gerschwiler@gmail.com>
Co-authored-by: Florian Forster <florian@zitadel.com>
Co-authored-by: Elio Bischof <elio@zitadel.com>

docs/docs/concepts/features/actions.md

@@ -5,10 +5,8 @@ title: Actions
 By using ZITADEL actions, you can manipulate ZITADELs behavior on specific Events.
 This is useful when you have special business requirements that ZITADEL doesn't support out-of-the-box.
 
-:::caution
-ZITADEL actions is in an early development stage.
-In the [roadmap](https://zitadel.com/roadmap), you see how we are planning to expand and improve it.
-Please tell us about your needs and help us prioritize further fixes and features.
+:::info
+We're working on Actions continuously. In the [roadmap](https://zitadel.com/roadmap), you see how we are planning to expand and improve it. Please tell us about your needs and help us prioritize further fixes and features.
 :::
 
 ## Why actions?
@@ -34,6 +32,6 @@ Within the JavaScript code, you can read and manipulate the state.
 
 ## Further reading
 
-- [Assign users a role after they register using an external identity provider](../../guides/manage/customize/behavior)
-- [Actions reference](../../apis/actions/introduction#action)
+- [Assign users a role after they register using an external identity provider](/guides/manage/customize/behavior)
+- [Actions reference](/apis/actions/introduction#action)
 - [Actions Marketplace: Find example actions to use in ZITADEL](https://github.com/zitadel/actions)

docs/docs/concepts/introduction.mdx

@@ -2,43 +2,9 @@
 title: Introduction
 ---
 
-import {ListElement, ListWrapper, ICONTYPE} from '../../src/components/list';
-import Column from '../../src/components/column';
-
 This part of the **ZITADEL** documentation contains ZITADEL specific or general concepts required to understand the system or our guides.
 
-Please be reminded that ZITADEL is open source — and so is the documentation. Should you happen to stumble over an incorrectness, a spelling mistake, a hard-to-understand text passage, please don’t hesitate to leave a comment or propose a corresponding change.
+![Overview](/img/concepts/objects/object_overview.png)
 
-
-<Column>
-  <ListWrapper title="General">
-    <ListElement link="./principles" type={ICONTYPE.TASKS} title="Principles" description="Design and engineering principles" />
-    <ListElement link="./architecture/software" type={ICONTYPE.ARCHITECTURE} title="Architecture" description="Sotware-, Cluster- and Multi Cluster Architecture" />
-  </ListWrapper>
-  <ListWrapper title="Structure">
-    <Column>
-      <div>
-      <ListElement link="./structure/overview" type={ICONTYPE.FOLDER} title="Overview" description="" />
-      <ListElement link="./structure/organizations" type={ICONTYPE.FILE} title="Organizations" description="" />
-      <ListElement link="./structure/policies" type={ICONTYPE.FILE} title="Policies" description="" />
-      <ListElement link="./structure/projects" type={ICONTYPE.FILE} title="Projects" description="" />
-    </div>
-    <div>
-      <ListElement link="./structure/applications" type={ICONTYPE.FILE} title="Applications" description="" />
-      <ListElement link="./structure/granted_projects" type={ICONTYPE.FILE} title="Granted Projects" description="" />
-      <ListElement link="./structure/users" type={ICONTYPE.FILE} title="Users" description="" />
-      <ListElement link="./structure/managers" type={ICONTYPE.FILE} title="Managers" description="" />
-    </div>
-    </Column>
-  </ListWrapper>
-
-  <ListWrapper title="Use Cases">
-    <ListElement link="./usecases/saas" type={ICONTYPE.START} title="SaaS" description="Product with Authentication and Authorization" />
-  </ListWrapper>
-  <ListWrapper title="Features">
-    <ListElement link="./features/actions" type={ICONTYPE.FILE} title="Actions" description="Customizing ZITADELs behavior using the actions feature" />
-  </ListWrapper>
-    <ListWrapper title="Customer Portal">
-      <ListElement link="../guides/manage/cloud/instances" type={ICONTYPE.INSTANCE} title="Instances" description="Manage all your ZITADEL instances" />
-    </ListWrapper>
-</Column>
+This overview shows the general structure of ZITADEL.
+You will find more detailed explanations around the different concepts in the following sections.

docs/docs/concepts/structure/policies.md

@@ -3,6 +3,6 @@ title: Settings/Policies
 ---
 
 Settings and policies are configurations of all the different parts of the Instance or an organization. For all parts we have a suitable default in the Instance.
-The default configuration can be overridden for each organization, some policies are currently only available on the instance level. Learn more about our different policies [here](../../guides/manage/console/instance-settings.mdx).
+The default configuration can be overridden for each organization, some policies are currently only available on the instance level. Learn more about our different policies [here](/guides/manage/console/instance-settings.mdx).
 
 API wise, settings are often called policies. You can read the proto and swagger definitions [here](../../apis/introduction.mdx).

docs/docs/concepts/usecases/saas.md

@@ -1,5 +1,6 @@
 ---
 title: SaaS Product with Authentication and Authorization
+sidebar_label: Software-as-a-Service
 ---
 
 This is an example architecture for a typical SaaS product. 
@@ -52,11 +53,11 @@ There are some different use cases how the login should behave and look like:
 
 1. Restrict Organization
 
-With the primary domain scope the organization will be restricted to the requested domain, this means only users of the requestd organization will be able to login.
+With the primary domain scope the organization will be restricted to the requested domain, this means only users of the requested organization will be able to login.
 The private labeling (branding) and the login policy of the requested organization will be set automatically.
 
 :::note
-More about the [Scopes](../../apis/openidoauth/scopes)
+More about the [Scopes](/apis/openidoauth/scopes)
 :::
 
 2. Show private labeling (branding) of the project organization
@@ -64,8 +65,8 @@ More about the [Scopes](../../apis/openidoauth/scopes)
 You can configure on project-level which branding should be shown to users.
 In the default the design of the instance will be shown, but as soon as the user is identified, the policy of the users organization (if specified) will be triggered.
 If the setting is set to `Ensure Project Resource Owner Setting`, the private labeling of the project organization will always be triggered.
-The last possibility is to show the private labeling of the project organization and as soon as the user is identitfied the user organization settings will be triggered.
+The last possibility is to show the private labeling of the project organization and as soon as the user is identified the user organization settings will be triggered.
 For this the Allow User Resource Owner Setting should be set.
 :::note
-More about [Private Labeling](../../guides/manage/customize/branding)
+More about [Private Labeling](/guides/manage/customize/branding)
 :::