# Administration (/docs/de/administration) Die Administration ist der Ort, an dem Sie Ihren **Workspace** verwalten: wer darin ist, eine Aufzeichnung dessen, was passiert ist, und wie viel Ihres Tarifs Sie nutzen. Das meiste davon ist Aufgabe eines **Admins**; jeder im Workspace kann an den Apps arbeiten. ## Ihr Workspace [#ihr-workspace] Ein **Workspace** ist das gemeinsame Zuhause für alles, was Ihr Team in Ovidens tut: seine Apps, Daten und Mitglieder. Jeder, den Sie einladen, kann dieselben Apps sehen und daran arbeiten, sodass ein Workspace in der Regel einem Team oder einem Unternehmen entspricht. Bei der ersten Anmeldung richten Sie Ihren Workspace ein: Ovidens begrüßt Sie mit "Benennen Sie Ihren Workspace, um die Einrichtung abzuschließen und ihn zu öffnen.", fragt nach einem **Organisationsnamen** (dem Namen, den alle in Ihrer Organisation sehen) und lässt Sie optional **Rechnungsdetails hinzufügen** - eine Postanschrift für Ihre Rechnungen, die Sie überspringen und später ergänzen können. **Workspace erstellen** schließt die Einrichtung ab und bringt Sie direkt hinein. Wenn Sie mehreren Workspaces angehören, wechseln Sie zwischen ihnen über den Workspace-Umschalter oben in der linken Navigation; jeder hält seine Apps, Daten und Mitglieder vollständig getrennt. Wenn Sie angemeldet zu [app.ovidens.com](https://app.ovidens.com) zurückkehren, öffnet Ovidens Ihre Apps automatisch. Bei mehreren Workspaces öffnet es den zuletzt ausgewählten Workspace, sofern Sie ihm weiterhin angehören; andernfalls wählen Sie einen aus. Ist Ihre Sitzung beendet, melden Sie sich erneut an, um fortzufahren. Eine noch offene Einrichtung des Workspace schließen Sie zuerst ab. Der Workspace-Name ist nicht endgültig. Ein Admin kann ihn ändern und auch Symbol und Farbe wählen, die in der Seitenleiste daneben erscheinen: auf dem Tab **Allgemein** der Seite **System** unter **Identität**. ## Mitglieder und Rollen [#mitglieder-und-rollen] Die Seite **Zugriff** listet auf ihrem Tab **Mitglieder** alle im Workspace auf. Jedes Mitglied hat eine **Rolle**: * Ein **Mitglied** kann mit den Apps arbeiten, die seine Rollen öffnen (siehe **Zugriff** und **Standardzugriff für neue Mitglieder** unten). * Ein **Admin** kann alles, was ein Mitglied kann, und verwaltet zusätzlich, wer im Workspace ist. Die Mitgliederliste sehen alle. **Benutzer einladen**, die Liste **Ausstehende Einladungen** und **Entfernen** sind für alle, die Mitglieder verwalten dürfen: einen Admin oder ein Mitglied, dem die **Mitgliederverwaltung** übertragen wurde. Zu entscheiden, was jemand tun darf - die Spalte **Workspace-Rolle**, **Zugriff verwalten** und jemanden als Admin einladen -, bleibt Admins vorbehalten. Ein Mitglied ohne beides sieht die Liste und sonst nichts. Die Liste ist eine Tabelle, die Sie nach Name oder E-Mail durchsuchen und nach Workspace-Rolle filtern können. Neben jeder Person stehen ihre **Workspace-Rolle** und, für Admins, die Rollen, die sie **In Bereichen** hat. Für einen Admin öffnen der Name und das Zahnrad in der Zeile (**Zugriff verwalten**) einen Dialog mit dem **Zugriff** der Person und **Was die Person darf**. Das Menü der Zeile bietet **KI-Berechtigungen**, **Aktivitätsprotokoll** und **Aus dem Workspace entfernen**, jeweils nur denen, die es nutzen dürfen; dürfen Sie nur eines davon nutzen, ist es stattdessen eine Schaltfläche in der Zeile. Eine E-Mail kopieren Sie mit der Schaltfläche daneben. Um jemanden einzuladen, öffnen Sie **Zugriff**, wählen **Benutzer einladen**, geben die E-Mail-Adresse ein, wählen die Rolle und senden die Einladung. Wenn Sie Mitglieder verwalten, ohne Admin zu sein, bietet der Dialog keine Rollenauswahl: Alle, die Sie einladen, treten als Mitglied bei. Die Person erscheint unter **Ausstehende Einladungen**, bis sie annimmt, und wandert dann zu **Mitglieder**. Aus dieser Liste können Sie mit **Einladungslink kopieren** die Einladung selbst verschicken oder eine noch nicht angenommene mit **Einladung zurückziehen** zurücknehmen. Ein neues Mitglied beginnt ohne Zugriff: Es hat seinen eigenen persönlichen Bereich und sonst nichts, bis ihm jemand eine Rolle gibt - es sei denn, Ihr Workspace legt einen **Standardzugriff für neue Mitglieder** fest (unten). Das Einladungsformular sagt das ebenfalls. Wer als Admin eingeladen wurde, ist von Anfang an Admin. Ein Admin ändert die **Workspace-Rolle** einer Person in ihrer Zeile: Die Änderung wird sofort gespeichert, mit **Rückgängig** in der Meldung, die sie bestätigt. Jemanden zum Admin zu machen oder einem Admin die Rechte zu entziehen, fragt vorher nach. Wem die Admin-Rechte entzogen werden, bleibt als Mitglied im Workspace und behält seine eigene Arbeit. Noch nicht angenommene Einladungen als Admin, die die Person verschickt hat, werden dabei storniert, und eine Einladung als Admin lässt sich nur annehmen, solange die einladende Person noch Admin ist. Ein Admin kann erst aus dem Workspace entfernt werden, wenn ihm die Admin-Rechte entzogen wurden. **Aus dem Workspace entfernen** fragt immer nach. ### Ein Mitglied mit eigenen Apps entfernen [#ein-mitglied-mit-eigenen-apps-entfernen] Jedes Mitglied hat einen persönlichen Bereich, den nur es selbst sieht. Darin erstellt, veröffentlicht, führt und archiviert es seine eigenen Apps, schreibt eigene SQL-Abfragen darauf und führt sie aus und kann seine Ausführungen schützen und löschen und Seiten der Wissensdatenbank aus dem Papierkorb endgültig löschen. Eine Abfrage dort liest nur die App, in der sie läuft, nie eine andere App. Niemand sonst kann einen persönlichen Bereich öffnen, auch kein Admin. Wenn Sie jemanden entfernen, in dessen persönlichem Bereich Apps liegen, nennt Ihnen die Bestätigung **wie viele** es sind - nie welche, denn außer der Person selbst sieht sie niemand - und fragt, was mit ihnen geschehen soll, bevor **Entfernen** möglich ist: * **In ... verschieben** verschiebt alle Apps der Person in einen Team-Bereich, wo alle mit Zugriff auf diesen Bereich damit arbeiten können. Angeboten werden nur die Team-Bereiche, in denen Sie Apps erstellen dürfen. * **Archivieren** archiviert alle Apps an Ort und Stelle. Niemand sieht sie, sie zählen nicht mehr gegen Ihr App-Limit, und sie werden endgültig gelöscht, sobald die Aufbewahrungsfrist für archivierte Apps abgelaufen ist. Kommt die Person vorher zurück, findet sie die Apps in ihrem eigenen Archiv und kann sie wiederherstellen. Ist der persönliche Bereich leer, fragt die Bestätigung nichts weiter. Beim Entfernen eines Mitglieds werden außerdem alle KI-Tools getrennt, die die Person mit diesem Workspace verbunden hatte; kommt sie zurück, verbindet sie sie neu. ### Zugriff: eine Rolle für den gesamten Workspace, einen Bereich oder eine App [#zugriff-eine-rolle-für-den-gesamten-workspace-einen-bereich-oder-eine-app] **Zugriff verwalten** in der Zeile eines Mitglieds (nur für Admins) öffnet dessen **Zugriff**: jede Rolle, die diese Person hat, und wo sie gilt - im gesamten Workspace, in einem Bereich oder in einer einzelnen App -, je eine Zeile, in der sich die Rolle direkt ändern lässt. Hier geben Sie jemandem eine engere Rolle als Admin oder eine Rolle für weniger als den gesamten Workspace: zum Beispiel **App-Ersteller** für den Bereich eines Teams, damit die Person dessen Apps konfigurieren und veröffentlichen kann und keine anderen, oder **App-Ersteller** für eine einzelne App, damit sie genau diese App ändern kann. Um eine Rolle zu vergeben, wählen Sie unter **Zugriff hinzufügen** den Bereich oder die App (oder den Workspace) und dann die Rolle. Angeboten wird nur, was Sie dort vergeben dürfen: Persönliche Bereiche und die App Audit Analytics werden nie angeboten, archivierte Apps ebenso wenig. Eine Rolle, die nichts hinzufügen würde - weil die Person dort über eine andere Rolle schon so viel hat -, wird nicht angeboten, und eine Zeile, die eine andere Rolle bereits abdeckt, ist abgeblendet und nennt diese Rolle. Die Rollen sind: * **Admin** - alles, auch die Entscheidung, was alle anderen tun dürfen. * **App-Ersteller** - Apps anlegen, konfigurieren, veröffentlichen und archivieren (auch mit Vera) und mit ihren Daten arbeiten. * **Analyst** - die Konfiguration und die Daten einer App lesen, sie ausführen und ihre Daten herunterladen. * **Mitwirkender** - die Konfiguration und die Daten einer App lesen, Daten erfassen (von Hand oder durch den Import einer Datei) und herunterladen. Was ein neues Mitglied beim Beitritt erhält, ist der Standardzugriff des Workspace für neue Mitglieder (unten). * **Betrachter** - das veröffentlichte Dashboard einer Analyse-App, ihre Wissensbasis und ihre Daten lesen, ohne ihre Konfiguration, Entwürfe oder ihren Verlauf, und ohne die Daten herunterzuladen oder KI darauf auszuführen. * **Mitgliederverwaltung** - Mitglieder einladen und entfernen (nur für den gesamten Workspace). * **Berichtsverantwortlicher** - die Erhebung einer Indikator-App durchführen: ihren Berichtszeitplan, Erhebungsrunden und die gefragten Personen, die Beurteilung der Antworten sowie das Einreichen, Freigeben und erneute Öffnen von Berichtszeiträumen (auch mit Vera). Die Rolle liest die Apps, die sie abdeckt, samt Konfiguration und Daten, und ändert beides nicht. Vergeben Sie sie für einen Bereich oder eine App, etwa an eine Nachhaltigkeitsverantwortliche, die dort das Berichtswesen führt und sonst nichts administriert. Zahlen erfasst sie allein nicht: Wer auch Zahlen erfasst, erhält daneben **Mitwirkender**. Ein **App-Ersteller** führt keine Erhebung durch, sodass die Person, die eine App gestaltet, nicht diejenige ist, die das darin Erhobene freigibt - es sei denn, sie erhält auch diese Rolle. Um eine Rolle zu entziehen, wählen Sie **Entfernen** daneben. Jede Änderung wird sofort gespeichert, mit **Rückgängig** in der Meldung, die sie bestätigt. Wird eine Änderung abgelehnt - etwa weil sie den letzten Admin entfernen würde -, nennt die Meldung den Grund, und nichts ändert sich. Ihren eigenen Zugriff sehen Sie hier, können ihn aber nicht ändern. **Was die Person darf**, die zweite Ansicht des Dialogs, zeigt, was die Person tatsächlich tun darf und warum: für den gesamten Workspace, für jeden Bereich und jede App, für die sie eine Rolle hat, und für ihren eigenen persönlichen Bereich jede Berechtigung, die sie dort hat, jeweils mit der Rolle, die sie gibt („App-Ersteller für Finance“). Ein Bereich oder eine App führt auch auf, was ihre Rollen für den gesamten Workspace erlauben, sodass jeder Ort für sich vollständig ist. Ihr persönlicher Bereich zeigt nur, dass sie dort immer arbeiten kann - nie, was darin liegt. ### Mein Zugriff [#my-access] Jedes Mitglied sieht auf dem Tab **Mein Zugriff** der Seite **Zugriff**, was es selbst tun darf. Es ist dieselbe Ansicht wie **Was die Person darf** im Dialog eines Admins, nur über Sie: für den gesamten Workspace, für jeden Bereich und jede App, für die Sie eine Rolle haben, und für Ihren eigenen persönlichen Bereich jede Berechtigung, die Sie dort haben, und die Rolle, die sie gibt. Ihr persönlicher Bereich wird als Ihrer aufgeführt. Brauchen Sie mehr, bitten Sie einen Admin darum: Admins vergeben Rollen über **Zugriff verwalten** in Ihrer Zeile. Eine Rolle für einen Bereich oder eine App entscheidet, was die Person dort TUN darf: Konfigurieren, Veröffentlichen, Daten erfassen, Herunterladen und was Vera und verbundene KI in ihrem Namen tun dürfen, werden App für App entschieden. Sie entscheidet auch, welche Apps die Person überhaupt sieht. In jeder App-Liste und in der Suche findet jede Person nur die Apps, die eine ihrer Rollen abdeckt - eine Rolle für den ganzen Workspace deckt jede App ab, eine Rolle für einen Bereich die Apps darin -, und eine App, die keine ihrer Rollen abdeckt, verhält sich für sie, als gäbe es sie nicht, auch für Vera und verbundene KI, die in ihrem Namen handeln. Die Rolle **Mitgliederverwaltung** allein öffnet keine App. Was eine Person von einer Analyse-App lesen darf, die sie öffnen kann, hängt von ihrer Rolle ab. Eine Rolle, die die Konfiguration der App liest - **Mitwirkender**, **Analyst**, **App-Ersteller** und **Admin** -, öffnet den Editor (schreibgeschützt, wo sie nicht konfigurieren darf) und liest den Entwurf, die Konfiguration und das SQL jedes Knotens, den Versionsverlauf und die Skills. Ein **Betrachter** liest die App so, wie sie zuletzt **veröffentlicht** wurde: ihre Dashboard-Seiten, wobei jedes SQL-Widget seine Zeilen zeigt, aber nie die Abfrage dahinter, ihre Wissensbasis und die Daten dahinter. Ein Betrachter sieht nicht, dass an einem Entwurf gearbeitet wird, bekommt kein **Editor öffnen** angeboten, und der Link in den Editor führt ihn stattdessen zum Dashboard. Eine App, die nie veröffentlicht wurde, zeigt einem Betrachter ihren leeren Zustand. Eine **Indikator-App** wird genauso gelesen. Ein Betrachter liest ihre Indikatoren, Gruppen, Dimensionen und Prüfungen so, wie sie zuletzt **veröffentlicht** wurden - jeden Indikator vollständig, mit seiner Anleitung, seiner Einheit, seiner Rahmenwerk-Zuordnung und seinen Regeln, und einen berechneten Indikator mit seiner Berechnung - und ihre erfassten Werte genau so wie alle anderen, zusammen mit ihren Berichtszeiträumen und den Erhebungsrunden, in denen er selbst angefragt ist. Die Berichtseinheiten in diesen Runden, in seinen eigenen Aufgaben und in der Tabelle **Erhebungsfortschritt** der App samt ihren Begleittabellen tragen die zuletzt veröffentlichten Namen, und eine Einheit, die nur im Entwurf hinzugefügt wurde, erscheint für ihn gar nicht. Ein Betrachter sieht nicht den Entwurf, an dem gearbeitet wird, den Versionsverlauf, Veras Arbeit oder die Prüfwerkzeuge des Editors, bekommt kein **Editor öffnen** angeboten, und der Link in den Editor führt ihn stattdessen zur App. Eine Indikator-App, die nie veröffentlicht wurde, zeigt einem Betrachter, dass sie noch nicht veröffentlicht wurde. Eine **Erhebung-App** wird genauso gelesen. Ein Betrachter liest das Formular so, wie es zuletzt **veröffentlicht** wurde - jede Frage genau so, wie sie den Befragten gestellt wurde - und jede eingegangene Antwort, zusammen mit den Dateien, die angehängt wurden. Die Seite **Informationen** der Erhebung, ihre Zahlen und ihre Erfassungsregeln liest jeder gleich. Ein Betrachter sieht keine Fragen, die für die nächste Runde entworfen werden, keinen Versionsverlauf, keinen Freigabelink und keine Prüfwerkzeuge des Formular-Editors, bekommt kein **Editor öffnen** angeboten, und der Link in den Editor führt ihn stattdessen zur Erhebung. Die Antworten als CSV herunterzuladen gehört nicht zur Rolle Betrachter. Eine Erhebung, die nie veröffentlicht wurde, zeigt einem Betrachter, dass ihre Antworten erscheinen, sobald jemand, der die Erhebung verwaltet, sie veröffentlicht. Folgt jemand einem Link zu einer App, die er nicht öffnen kann, sieht er **App nicht gefunden** mit der Zeile „Diese App existiert nicht, oder Sie haben keinen Zugriff darauf.“ und den Namen der Admins, die ihm Zugriff geben können - bis zu drei, dann „und N weitere“, oder die Person, die den Link geteilt hat, wenn es keinen anderen Admin gibt. Die Seite sagt nie, welcher der beiden Fälle vorliegt, und verrät so nicht, ob die App existiert. Um die Person hineinzulassen, geben Sie ihr eine Rolle für die App, ihren Bereich oder den ganzen Workspace. Der Workspace behält immer mindestens einen Admin. Dem letzten Admin die Rechte zu entziehen, wird deshalb abgelehnt, bevor sich etwas ändert: Machen Sie zuerst jemand anderen zum Admin. Ihre eigene Workspace-Rolle und **Aus dem Workspace entfernen** sind in Ihrer eigenen Zeile nicht verfügbar - Ihre Rolle ändert ein anderer Admin. Im Menü eines Mitglieds legt **KI-Berechtigungen** fest, was die KI dieser Person in diesem Workspace höchstens tun darf (siehe [MCP](../integrations/mcp.mdx)), und **Aktivitätsprotokoll** öffnet die Historie dieses Mitglieds in der App Audit Analytics. ### Rollen und Bereiche [#roles-and-spaces] **Rollen** auf der Seite **Zugriff** ist für alle: Der Tab listet jede Berechtigung, nach Gebiet gruppiert, mit einer Spalte je Rolle, die zeigt, ob sie sie erlaubt, und nennt unter einer Berechtigung, wenn sie nur für den gesamten Workspace oder einen Bereich vergeben werden kann. Klicken Sie auf Rollennamen in der Kopfzeile, um diese Rollen zu vergleichen (**Rolle hinzufügen** holt eine zurück, die Sie nicht mehr sehen), und **Nur Unterschiede**, um zu sehen, worin sie sich unterscheiden. Rollen lassen sich nicht ändern. Eine Rolle für einen Bereich oder eine App erlaubt nur, was dort gelten kann - **Admin** für einen Bereich lässt zum Beispiel niemanden Mitglieder verwalten. **Bereiche** ist eine Tabelle mit dem **Workspace** und jedem Teambereich, der Standardbereich zuerst: wer dort eine Rolle hat, wie viele Apps darin liegen und was sie belegen. Eine Rolle für den gesamten Workspace gilt auch in jedem Teambereich und steht deshalb einmal oben statt unter jedem Bereich. Persönliche Bereiche werden nie aufgelistet, weil nur ihre Eigentümer sie öffnen können: Der Tab nennt nur, wie viele Mitglieder einen haben und wie viele Apps darin liegen. Der Tab zeigt außerdem, wie viel Speicher der Workspace im Verhältnis zu seiner Grenze belegt und was die Apps jedes gemeinsamen Bereichs belegen. Persönliche Bereiche zählen gegen dieselbe Grenze, deshalb nennt der Tab, was die persönlichen Bereiche der Mitglieder zusammen belegen - nie, was der Bereich einer einzelnen Person belegt, und erst, wenn mindestens drei persönliche Bereiche von Kolleginnen und Kollegen Daten enthalten; bis dahin zählt diese Zahl zu den Dateien, die zu keiner App gehören. Was zu keiner App gehört (Originaldateien des Prüfprotokolls, Anhänge und andere Dateien des Workspace), steht als eigene Zahl da. Die Zahlen je Bereich werden einmal täglich gemessen, und der Tab nennt den Tag. Er zeigt außerdem, wie viele gemeinsame Bereiche der Workspace im Verhältnis zu seiner Höchstzahl hat, zum Beispiel "3 von 10 Teambereichen belegt". Admins verwalten die gemeinsamen Bereiche hier. Ein Klick auf einen Teambereich öffnet **Bereichseinstellungen** - dieselben Bereichseinstellungen wie auf der Seite **Apps** - mit seinem **Zugriff** und unter **Details** seinem Namen, seinem Symbol und **Löschen**: * **Neuer Bereich** legt einen an. Geben Sie ihm einen Namen mit höchstens 80 Zeichen, den kein anderer gemeinsamer Bereich schon trägt (Groß- und Kleinschreibung zählt nicht als Unterschied). Hat der Workspace seine Höchstzahl erreicht, ist die Schaltfläche nicht verfügbar und sagt warum; das Ovidens-Team kann die Grenze anheben. Der Standardbereich zählt mit; persönliche Bereiche zählen nie. * Den **Namen** unter **Details** zu ändern, benennt einen Bereich um, auch den des Standardbereichs. Die für den Bereich vergebenen Rollen und die Apps darin bleiben unberührt. * **Löschen** unter **Details** entfernt nach Ihrer Bestätigung einen gemeinsamen Bereich, aber nur einen leeren: Liegen darin noch Apps (auch archivierte), für ihn vergebene Rollen oder Vorgaben für neue Mitglieder, wird das Löschen abgelehnt und nennt, wie viele davon jeweils übrig sind. Verschieben Sie zuerst seine Apps mit **In einen anderen Bereich verschieben** auf der Seite **Apps** in einen anderen Bereich - dort sehen Sie, wer Zugriff gewinnt und verliert, bevor etwas verschoben wird - und entfernen Sie seine Rollen und Vorgaben hier auf der Seite **Zugriff**. Der Standardbereich kann nicht gelöscht werden. Jede dieser Änderungen wird im Aktivitätsprotokoll festgehalten. Ein Mitglied, das Mitglieder verwaltet, ohne Admin zu sein, sieht auch den Tab **Bereiche**: Er listet die gemeinsamen Bereiche, die es öffnen kann - aber nicht, wer darin welche Rolle hat; das bleibt bei den Admins. Alle anderen sehen **Mitglieder**, **Mein Zugriff** und **Rollen**, und ein Link zu **Bereiche** sagt ihnen, dass ihn nur sehen kann, wer Mitglieder verwaltet oder festlegt, was sie dürfen. ### API-Zugangsdaten [#api-credentials] Ein verbundenes System - ein nächtlicher Import, ein Skript, ein Planer - meldet sich mit **API-Zugangsdaten** an statt mit dem Konto einer Person. Zugangsdaten liegen auf der Seite **Zugriff** neben den Mitgliedern, auf dem Tab **API-Zugangsdaten**, den nur Admins sehen. Alles rund um Zugangsdaten geschieht dort: sie anlegen und ihr Secret kopieren (es wird einmal angezeigt), sehen, was sie dürfen, ihr Secret erneuern, ihren Zugriff ändern und sie widerrufen. Der Tab ist eine Tabelle - Name, Schlüssel und Zugriffsoptionen jeder Zugangsdaten, wann sie zuletzt genutzt wurden und wann sie ablaufen oder als Nächstes bestätigt werden müssen -, und das Zahnrad einer Zeile öffnet die Details. Ihr Tab **Zugriff** listet jede Berechtigung, die ihre Zugriffsoptionen geben, und welche Option sie jeweils gibt, genauso wie bei einem Mitglied. Zugangsdaten haben keine Rolle; sie wirken deshalb in jedem gemeinsamen Bereich und jeder App darin, auch in später angelegten Apps, und nie im persönlichen Bereich einer Person. Die Anleitung steht unter [Verbundene Systeme](./connected-systems.mdx). ### Standardzugriff für neue Mitglieder [#standardzugriff-für-neue-mitglieder] Alle, die dem Workspace ab jetzt beitreten - indem sie eine Einladung mit einem bereits vorhandenen Konto annehmen, sich über eine Einladung registrieren oder vom Ovidens-Team hinzugefügt werden -, erhalten die Rollen, die unten auf dem Tab **Mitglieder** der Seite **Zugriff** unter **Standardzugriff für neue Mitglieder** aufgeführt sind, dazu ihren eigenen persönlichen Bereich. Wer als Admin eingeladen wurde, ist zusätzlich Admin; jede andere Einladung gibt nichts über die Vorgaben hinaus. Admins sehen diesen Abschnitt und ändern ihn dort; alle anderen sehen ihn nicht. Jeder Workspace beginnt ohne Standardzugriff: Ein neues Mitglied hat keine Rolle, bis ihm jemand eine gibt, und arbeitet bis dahin nur in seinem eigenen persönlichen Bereich. Wer bereits Mitglied war, behält jede Rolle, die er hat. Ein Satz über der Liste sagt, was neue Mitglieder erhalten. Um eine Vorgabe hinzuzufügen, wählen Sie rechts in der Überschrift **Vorgabe hinzufügen**, im Dialog den Workspace, einen Bereich oder eine App (sie lassen sich durchsuchen) und dann die Rolle, und wählen **Vorgabe hinzufügen**: Sie wird hinzugefügt, mit **Rückgängig** in der Meldung, die das bestätigt. So lässt zum Beispiel **Betrachter** für den Bereich eines Teams jede neue Person die Dashboards dieses Teams lesen und sonst nichts. Angeboten werden nur Rollen, die Sie vergeben dürfen, eine dort bereits gesetzte Rolle wird nicht erneut angeboten, und **Admin** und **Mitgliederverwaltung** für den gesamten Workspace werden nie angeboten: Eine Vorgabe kann niemanden zum Admin machen oder ihm die Verwaltung von Mitgliedern übertragen. Ein Workspace kann bis zu 20 Vorgaben haben. Um eine nicht mehr zu vergeben, wählen Sie **Entfernen** daneben; auch das bietet **Rückgängig** an. Wird eine Änderung abgelehnt, nennt die Meldung den Grund, und nichts ändert sich. Eine Änderung der Vorgaben ändert nie die Rollen von jemandem, der bereits beigetreten ist - dafür nutzen Sie **Zugriff verwalten** in seiner Zeile. Die Vorgaben werden gelesen, wenn eine Person beitritt, nicht wenn sie eingeladen wurde; eine noch offene Einladung gibt also die Vorgaben, wie sie beim Annehmen gelten. Ein Mitglied, dessen Rollen noch keine App öffnen - zum Beispiel in einem Workspace ohne Standardzugriff -, sieht auf der App-Seite „Noch keine Apps mit Ihnen geteilt“ mit den Namen der Admins, die es um Zugriff bitten kann, statt eines leeren Workspace. Konnte seine Liste der Apps nicht geladen werden, sagt die Seite das und bietet **Erneut versuchen** an. Wenn Sie es lieber gezeigt als erklärt bekommen, führt Sie die Seite **Zugriff** selbst durch ihren Tab Mitglieder: [Tour der Seite Zugriff starten](https://app.ovidens.com/access?tour=users). Eine Tour zeigt nur; sie ändert nie etwas. ## Aktivitätsprotokoll [#aktivitätsprotokoll] Ihr Workspace zeichnet bei jeder Änderung automatisch auf, wer was wann geändert hat: Apps erstellt, Daten bearbeitet, Pipelines ausgeführt, Teammitglieder eingeladen. Admins lesen diese Aufzeichnung in der App **Audit Analytics** und erreichen sie überall im Produkt über die Schaltfläche **Prüfprotokolle anzeigen**. Die Seite [Audits](../administration/audit-trail.mdx) ist die vollständige Anleitung. Welches KI-Modell Vera antreibt, ist eine Entscheidung pro Workspace, die ein Workspace-Admin auf dem Tab **Allgemein** der Seite **System** trifft - siehe [Das KI-Modell des Workspace auswählen](../infrastructure/ai-transparency.mdx#das-ki-modell-des-workspace-auswählen). ## Die Seite System [#usage] Die Seite **System** hat diese Tabs. API-Zugangsdaten gehören nicht dazu: Sie liegen auf dem Tab **API-Zugangsdaten** der Seite **Zugriff** (siehe [API-Zugangsdaten](#api-credentials)). * **Nutzung** nennt die **Compute-Stufe** und die **Instanz** Ihres Workspace, die die Werte darunter maßgeblich bestimmen, und zeigt die Obergrenzen mit einem live aktuellen Wert daneben: Apps, Benutzer, Audit-Log-Einträge, gespeicherte Daten, monatliche Compute-Credits, monatliche KI-Credits und Teambereiche. Darunter ein Diagramm der Nutzung über die Zeit, umschaltbar zwischen **KI-Credits**, **Compute-Credits** und **Speicher**, nach Stunde, Tag, Woche oder Monat. Admins - wer die Aktivitätsaufzeichnungen des Workspace lesen darf - sehen am Fuß des Tabs außerdem **Daten-Downloads**: was Mitglieder dieses Workspace heruntergeladen haben - wer, aus welcher App und welchem Knoten, ob es die aktuellen Daten, eine Version oder ein Lauf waren, wie viele Zeilen und wie viel - mit den Summen der letzten 30 Tage darüber. Ein Download, der schmaler war als sein Knoten, ist als **gefiltert** oder mit der Anzahl der genommenen Spalten markiert, damit eine kleine Datei nie mit dem gesamten Datensatz verwechselt wird. Ein Download aus einer App, die Sie nicht öffnen können - einer im persönlichen Bereich einer Kollegin oder eines Kollegen -, wird weder aufgeführt noch in den Summen gezählt. Nachweise werden 90 Tage aufbewahrt, die Dateien selbst deutlich kürzer. Es ist dieselbe Frage, die die Seite [Zugangsdaten](../integrations/api/credentials.mdx) für ein automatisiertes System beantwortet, hier über Personen gestellt. * **Limits** zeigt die festen Obergrenzen pro App, pro Version und pro Visualisierung - wie viele Knoten, Wissensdatenbank-Elemente, Widgets, Kennzahlen, Dimensionen oder Skills jeweils erlaubt sind - sowie wie viele Durchlaufdaten pro App aufbewahrt werden und wie lange eine archivierte App erhalten bleibt, bevor sie endgültig gelöscht wird. * **Allgemein** enthält die **Identität** Ihres Workspace (Name, Symbol und Farbe) und seine **KI-Konfiguration** (das Modell, das Vera antreibt). Ein Admin bearbeitet beides und speichert es gemeinsam mit einem **Speichern**; alle anderen, auch ein Mitglied mit Mitgliederverwaltung, sehen es schreibgeschützt. [Tour der Seite System starten](https://app.ovidens.com/system?tour=system), um sich jeden Tab auf der Seite selbst zeigen zu lassen. ### Wenn Sie ein Limit erreichen [#wenn-sie-ein-limit-erreichen] Zwei der Zähler können die Arbeit stoppen, und beide sagen das deutlich, statt stillschweigend zu versagen: * **KI-Credits** setzen sich monatlich zurück. Am monatlichen Limit stoppen die KI-Funktionen mit einer Meldung, die das Limit des Workspace nennt und auf den Support verweist; der Rest des Workspace arbeitet normal weiter. * **Compute-Credits** setzen sich ebenfalls monatlich zurück und bezahlen das Ausführen von Pipelines und das Lesen von Daten. Am Limit erscheint "Das monatliche Compute-Credit-Limit für diesen Workspace wurde erreicht.", bis der nächste Monat beginnt oder ein Admin ein höheres Budget vereinbart. Andere Limits, etwa die Anzahl der Apps, Mitglieder oder gemeinsamen Bereiche, verweigern schlicht die Aktion, die sie überschreiten würde, und nennen das erreichte Limit.