> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Organisationen

> Ressourcenteilung auf Teamebene mit rollenbasiertem Zugriff, optionaler Überprüfung und Credential-Fallback.

## Übersicht

Organisationen sind FIM Ones Einheit für Teamzusammenarbeit. Sie ermöglichen es Benutzergruppen, Ressourcen — Agents, Connectors, MCP Servers, Workflows und Skills — innerhalb eines vertrauenswürdigen Bereichs zu teilen. Knowledge Bases sind die eine Ausnahme: Sie sind niemals teilbar und erreichen andere Mitglieder nur als interne Abhängigkeit eines freigegebenen Agents (siehe [Sharing and credentials](/architecture/sharing-and-credentials)).

Jede Ressource in FIM One beginnt als **persönlich** (nur für ihren Ersteller sichtbar). Wenn Sie eine Ressource in einer Organisation veröffentlichen, wird sie **auffindbar** für andere Organisationsmitglieder über den Marktplatz im Organisationsbereich. Mitglieder durchsuchen die freigegebenen Ressourcen der Organisation und abonnieren die, die sie benötigen.

```mermaid theme={null}
flowchart TD
    R["Personal Resource"]

    subgraph OrgPublish["Organization"]
        O["Org Scope in Market"]
        M1["Member A<br/>(subscribes)"]
        M2["Member B<br/>(subscribes)"]
        M3["Member C<br/>(browses only)"]
    end

    R -->|"publish to org"| O
    O -->|"subscribe"| M1
    O -->|"subscribe"| M2
    O -.->|"visible but not subscribed"| M3
```

Organisationen und der globale Marktplatz nutzen das gleiche abonnementbasierte Zugriffsmodell. Der Hauptunterschied ist Vertrauen: Organisationen stellen ein Team oder Unternehmen dar, in dem sich Mitglieder kennen und vertrauen, daher ist eine Überprüfung optional und die Anmeldedatenverwaltung ist unkompliziert.

## Erstellen und Verwalten von Organisationen

Jeder Benutzer kann **unbegrenzte** Organisationen erstellen und einer beliebigen Anzahl von ihnen beitreten. Eine Organisation hat drei Rollen:

| Rolle          | Berechtigungen                                                                                  |
| -------------- | ----------------------------------------------------------------------------------------------- |
| **Eigentümer** | Vollständige Kontrolle — Mitglieder verwalten, Einstellungen konfigurieren, Überprüfung umgehen |
| **Admin**      | Mitglieder verwalten und veröffentlichte Ressourcen überprüfen                                  |
| **Mitglied**   | Freigegebene Ressourcen durchsuchen und abonnieren                                              |

Der Eigentümer ist immer der Benutzer, der die Organisation erstellt hat. Die Eigentümerschaft kann übertragen, aber nicht geteilt werden.

## Ressourcen veröffentlichen

Wenn Sie eine Ressource in Ihrer Organisation veröffentlichen, wird sie **nicht** automatisch im Arbeitsbereich aller Mitglieder angezeigt. Stattdessen wird die Ressource im Organisationsbereich des Markts auffindbar, wo Mitglieder sie durchsuchen und abonnieren können.

Dieses abonnementbasierte Modell gibt jedem Mitglied Kontrolle über seinen Arbeitsbereich. Eine große Organisation könnte Dutzende von Konnektoren teilen, aber ein einzelnes Mitglied abonniert nur diejenigen, die für seine Arbeit relevant sind.

```mermaid theme={null}
sequenceDiagram
    participant U as Publisher
    participant P as Platform
    participant O as Org Settings
    participant M as Other Members

    U->>P: Publish Agent to Org
    P->>O: Check review_agents flag
    alt Review disabled
        P->>P: publish_status = NULL (auto-approved)
        P-->>U: Resource discoverable by org members
    else Review enabled
        P->>P: publish_status = "pending_review"
        P-->>U: Pending admin approval
        Note over P: Org admin approves or rejects
        P->>P: publish_status = "approved"
    end
    M->>P: Browse org resources in Market
    M->>P: Subscribe to Agent
    P-->>M: Agent appears in workspace
```

### Überprüfungssystem

Die Überprüfung ist **optional** und wird pro Ressourcentyp konfiguriert. Jede Organisation hat unabhängige Umschalter:

* `review_agents`
* `review_connectors`
* `review_kbs`
* `review_mcp_servers`
* `review_workflows`
* `review_skills`

Wenn die Überprüfung für einen Ressourcentyp deaktiviert ist, sind veröffentlichte Ressourcen sofort für Mitglieder auffindbar — keine Admin-Aktion erforderlich. Wenn die Überprüfung aktiviert ist, treten Ressourcen in einen `pending_review`-Status ein und erfordern eine Admin-Genehmigung, bevor sie sichtbar werden.

<Tip>
  Organisationseigentümer umgehen die Überprüfung automatisch. Ihre veröffentlichten Ressourcen sind immer sofort auffindbar.
</Tip>

Diese Flexibilität ermöglicht es Organisationen, ihre Governance-Anforderungen zu erfüllen. Ein kleines Startup könnte alle Überprüfungs-Umschalter deaktivieren, um reibungsloses Teilen zu ermöglichen, während ein compliance-fokussiertes Unternehmen die Überprüfung für Agenten und Konnektoren aktiviert, um die Kontrolle zu behalten.

## Credential Fallback

Konnektoren und MCP Server erfordern häufig Anmeldedaten (API-Schlüssel, Datenbankpasswörter, OAuth-Token). FIM One bietet einen **Fallback-Mechanismus**, damit Mitglieder nicht jede Anmeldedaten selbst konfigurieren müssen.

```mermaid theme={null}
flowchart TD
    E["Member uses a shared Connector"]
    C1{"Member has own credential?"}
    C2{"allow_fallback enabled?"}
    C3{"Owner set default credential?"}

    E --> C1
    C1 -->|Yes| U["Use member's credential"]
    C1 -->|No| C2
    C2 -->|Yes| C3
    C3 -->|Yes| F["Fallback to owner's default"]
    C3 -->|No| ERR["Error: credential required"]
    C2 -->|No| ERR2["Error: credential required"]
```

Es gibt zwei Modi:

* **Fallback aktiviert** (`allow_fallback=true`, Standard): Mitglieder, die ihre eigenen Anmeldedaten nicht bereitstellen, verwenden automatisch die Standard-Anmeldedaten des Eigentümers. Dies funktioniert gut für von Teams gemeinsam genutzte API-Schlüssel oder interne Services, bei denen ein einzelner Schlüssel das ganze Team abdeckt.
* **Fallback deaktiviert** (`allow_fallback=false`): Jedes Mitglied muss seine eigenen Anmeldedaten konfigurieren. Dies ist angemessen, wenn jeder Benutzer einen persönlichen API-Schlüssel benötigt (z. B. für benutzerbasierte SaaS-Lizenzen).

Ressourcen, die keine Anmeldedaten erfordern – wie ein schreibgeschützter öffentlicher API-Konnektor oder ein Agent ohne Authentifizierung – funktionieren sofort nach dem Abonnement. Keine Konfiguration erforderlich.

<Info>
  Der Credential Fallback gilt nur nach dem Abonnement einer Ressource durch ein Mitglied. Der Fallback-Mechanismus bestimmt, wie Anmeldedaten zur Laufzeit aufgelöst werden, nicht ob die Ressource zugänglich ist.
</Info>

## Ressourcensichtbarkeit

Jede Ressource in FIM One hat eine `visibility`, die ihren Zugriffsgeltungsbereich bestimmt:

| Sichtbarkeit | Geltungsbereich | Wer kann sie entdecken                                             |
| ------------ | --------------- | ------------------------------------------------------------------ |
| `personal`   | Nur Eigentümer  | Der Benutzer, der sie erstellt hat                                 |
| `org`        | Organisation    | Org-Mitglieder können durchsuchen und abonnieren (falls genehmigt) |

Der Sichtbarkeitsfilter folgt einem einheitlichen Abfragemuster:

```
A resource is available in your workspace if:
  1. You own it (any visibility), OR
  2. It's published to an org you belong to, approved, AND you've subscribed to it
```

<Warning>
  Das Veröffentlichen einer Ressource in einer Organisation gewährt keinen automatischen Zugriff. Mitglieder müssen sich über den Markt im Org-Geltungsbereich anmelden, um die Ressource zu ihrem Arbeitsbereich hinzuzufügen.
</Warning>

## Infrastructure-Ressourcen (organisationsweit, kein Abonnement)

Eine zweite Klasse von organisationsweit geltenden Ressourcen folgt **nicht** dem oben beschriebenen Lebenszyklus „persönlich → veröffentlichen → abonnieren". Diese werden **einmalig von einem Org-Eigentümer oder Admin konfiguriert** und sind dann transparent für jeden Agenten in der Organisation verfügbar:

| Ressource          | Zweck                                                                                       | Konfiguriert von                         | Verwendet von                                                                                   |
| ------------------ | ------------------------------------------------------------------------------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Channels**       | Ausgehende Verbindung zu einer IM-Plattform (derzeit Feishu; Slack / WeCom / Teams geplant) | Org-Eigentümer / Admin                   | [Hook-System](/architecture/hook-system) jedes Agenten und proaktive Benachrichtigungswerkzeuge |
| **OAuth-Anbieter** | Social-Login-Anmeldedaten (GitHub, Google, Feishu, Discord)                                 | Systemadministrator (Umgebungsvariablen) | Anmeldeseite                                                                                    |
| **API-Schlüssel**  | Programmatische Zugriffstokens für Headless-Clients                                         | Jeder Benutzer, organisationsweit        | Externe Integrationen                                                                           |

```mermaid theme={null}
flowchart LR
    Admin["Org Owner / Admin"]
    subgraph Org["Organization"]
        Ch["Channel<br/>(e.g. FIM One ↔ Feishu group)"]
        A1["Agent A"]
        A2["Agent B"]
        A3["Agent C"]
    end
    Admin -->|"configure once"| Ch
    A1 -. "uses via feishu_gate hook" .-> Ch
    A2 -. "uses for notifications" .-> Ch
    A3 -. "uses for approval cards" .-> Ch
```

Der Schlüsseunterschied: **veröffentlichbare Ressourcen** (Agenten, Connectoren, Skills, …) sind benutzerbasierte Artefakte, die ein explizites Mitgliederabonnement erfordern; **Infrastruktur-Ressourcen** (Channels, OAuth, API-Schlüssel) sind Plattform-Level-Verkabelung, die alle Agenten implizit gemeinsam nutzen. Channels sind speziell die IM-Hotline für die gesamte Organisation — ein gut gepflegter Feishu-Channel unterstützt jedes Approval Gate eines Agenten, jeden geplanten Bericht, jedes Eskalationsereignis.

Siehe [Channels-Übersicht](/configuration/channels/overview) für den Channel-Lebenszyklus und unterstützte Plattformen.

## Praktische Szenarien

### Team-Datenbankverbindung teilen

1. Alice erstellt einen Connector zur PostgreSQL-Datenbank des Teams
2. Alice veröffentlicht ihn im Org-Bereich ihres Teams (die Überprüfung ist für Connectors deaktiviert)
3. Der Connector wird im Org-Bereich des Marktes auffindbar
4. Bob durchsucht die gemeinsamen Ressourcen der Org, findet den Connector und abonniert ihn
5. Der Connector erscheint in Bobs Workspace und verwendet Alices Datenbankzugriffsdaten als Fallback
6. Carol abonniert ebenfalls. Dave (ein externer Auftragnehmer) abonniert und konfiguriert stattdessen seine eigenen Anmeldedaten mit Lesezugriff

### Organisation mit strenger Überprüfung

1. Ein compliance-fokussiertes Unternehmen aktiviert `review_agents=true` und `review_connectors=true` in ihrer Organisation
2. Wenn ein Mitarbeiter einen neuen Agenten veröffentlicht, wechselt dieser in den Zustand `pending_review`
3. Ein Organisations-Admin überprüft die Agenten-Konfiguration und genehmigt sie
4. Der Agent wird auffindbar — andere Mitglieder können ihn jetzt finden und abonnieren
5. Wenn der Herausgeber den genehmigten Agenten später bearbeitet, wird dieser automatisch zur erneuten Genehmigung in den Zustand `pending_review` zurückgesetzt

### Selektive Abonnements in einer großen Organisation

1. Eine Organisation veröffentlicht 50+ Konnektoren, die interne APIs, Datenbanken und Services von Drittanbietern abdecken
2. Das Datateam abonniert nur Datenbank-Konnektoren und Analytics-APIs
3. Das Marketing-Team abonniert nur die CRM- und E-Mail-Plattform-Konnektoren
4. Der Arbeitsbereich jedes Teammitglieds bleibt fokussiert und übersichtlich

## Siehe auch

* [Marktarchitektur](/concepts/market) — Für den globalen Markt und seine Beziehung zu Organisationen. Beide verwenden das gleiche Abonnementmodell, aber der Markt dient als organisationsübergreifender Erkennungskanal mit obligatorischer Überprüfung.
* [Agent- und Ressourcenerkennung](/architecture/agent-discovery) — Wie abonnierte Ressourcen während des Chats in Toolsets zusammengestellt werden.