Testen Sie LadVen OS mit unsDemo anfragen
Zum Hauptinhalt springen

Administrierung des Portals

Die Administrierung des Portals umfasst die Einstellungen, die festlegen, wie das gesamte Unternehmen in LadVen OS arbeitet: die Regeln der Module, der Zugriff, die Post und die Anmeldung. Geaendert werden sie vom Eigentuemer oder Administrator; dafuer sind administrative Rechte erforderlich.

Diese Seite ist ein Ueberblick dessen, was sich einrichten laesst. Das Zugriffsmodell ist ausfuehrlich im Abschnitt Zugriff und Rollen beschrieben, und der zweite Faktor bei der Anmeldung im Abschnitt Zwei-Faktor-Authentifizierung (2FA).

Arbeitsregeln der Module

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

Der Administrator legt Regeln je Modul fest — wie sich das Portal standardmaessig fuer alle verhaelt:

  • Aufgaben — Regeln fuer die Arbeitsverteilung (ob Aufgaben nach unten, nach oben oder zwischen Abteilungen gestellt werden duerfen), der Automatisierungsmodus fuer gewoehnliche Mitarbeitende, Standardanforderungen (Ergebnispruefung, vorherige Einschaetzung).
  • CRM — der Standard-Zugriffsmodus (streng oder offen) und die Rechte der Rollen an Kundendaten.
  • Chats — wem der persoenliche Schriftverkehr erlaubt ist: aktiven Mitarbeitenden, Kolleginnen und Kollegen aus der eigenen oder einer verbundenen Abteilung, nur im Rahmen eines Projekts oder niemandem (deny_by_default).
  • KI — ob das Modul aktiviert ist und wem die KI-Anbindungen zur Verfuegung stehen.
  • Dokumente und Dateien — Regeln fuer die Arbeit mit Dokumenten und Dateien des Unternehmens.

Aendern Sie die Regeln eines Moduls als Richtlinie fuer das gesamte Unternehmen und nicht fuer einen Einzelfall: Sie wirken sich auf alle Benutzer zugleich aus.

Arbeitsbereiche

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

Arbeitsbereiche grenzen groessere Rahmen innerhalb des Portals voneinander ab. Fuer jeden lassen sich Teilnehmende und ihre Rollen festlegen sowie ein Modus zur Einhaltung der Regeln: ausgeschaltet (off), stufenweise (staged) oder streng (strict). Im stufenweisen Modus bleibt Lesen offen, waehrend Schreiben und Verwalten an die Bereichsgrenzen gebunden sind; der strenge Modus blockiert Verstoesse. Beginnen Sie stufenweise, pruefen Sie die Auswirkungen und aktivieren Sie danach bei Bedarf den strengen Modus.

Sicherheit

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

Im Bereich Sicherheit legt der Administrator fest:

  • den Standard-Zugriffsmodus fuer Module (siehe Zugriff und Rollen);
  • die Sichtbarkeit der Abteilungenall (gesamte Struktur) oder self_chain (nur der eigene Zweig);
  • die Richtlinie der Zwei-Faktor-Authentifizierung getrennt fuer Mitarbeitende und externe Teilnehmende: off, optional, required_for_admins oder required_for_all (siehe Zwei-Faktor-Authentifizierung (2FA)).

Die Zugriffspolitiken oeffnen Sie in Portaleinstellungen (/portal-settings?tab=policies). Die alten Links /access-policies und /admin/access leiten dorthin weiter.

Der globale Modus dient als Fallback für Module. CRM, Aufgaben, Workflows, Chats und KI können ihn übernehmen oder einen eigenen Modus Streng/Offen erhalten; fehlt der Modulwert, gilt der globale Wert. Sobald ein Modus offen ist, zeigt das Portal vor dem Speichern eine Risikowarnung. Prüfen Sie danach den effektiven Modus und grenzen Sie ihn bei Bedarf mit einer ausdrücklichen Zugriffsregel ein.

Systempost

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

Die Systempost ist die Art, wie das Portal E-Mails versendet (Benachrichtigungen, Einladungen, Prozess-E-Mails). Der Administrator richtet Versandprofile, Vorlagen und Betreffzeilen ein und ueberwacht die Zustellung. Eine richtig eingerichtete Systempost ist noetig, damit Einladungen und Benachrichtigungen Mitarbeitende und Kunden erreichen.

Das allgemeine Zentrum ist /portal-settings; die eigene Versandseite liegt unter /portal-settings/system-email. Während die Berechtigungsdaten geladen werden, kann kurz „E-Mail-Kanal wird geprüft“ erscheinen; das ist kein Ausfall. Bewerten Sie „Aktiv“ oder „Nicht verfügbar“ und den Grund erst nach Abschluss der Prüfung.

Eine Test-E-Mail gilt nicht sofort nach dem Klick als versendet. Verwenden Sie eine synthetische Empfängeradresse und testen Sie nur in einer Testumgebung: „In Warteschlange“ und „Wartet auf Sender“ bedeuten, dass der Worker noch nicht verarbeitet hat, „Versendet“ ist ein bestätigtes Ergebnis und „Nicht versendet“ nennt den Ablehnungsgrund. Ist der Queue-Worker ausgeschaltet, verlässt die Nachricht die Warteschlange nicht; „Noch in Warteschlange“ ist kein Fehler — warten Sie auf einen Eintrag im Zustellprotokoll oder beenden Sie das Warten und prüfen Sie später erneut. Eine leere oder ungültige Empfängeradresse wird vor dem Einreihen abgelehnt.

Wenn mehrere Profile denselben Bereich-und-Zweck-Slot belegen, lehnt das Portal das Speichern ab: Der Administrator muss ein Profil behalten und Duplikate zusammenführen oder entfernen. Ein erneuter Versand ist nicht für jede Zustellung möglich: Bei einem aktiven Lease warten Sie das laufende Ergebnis ab, nach einem Konflikt laden Sie die Seite neu, und bei einem nicht wiederholbaren Datensatz prüfen Sie zuerst das Zustellprotokoll. Verwenden Sie nur synthetische Adressen und Inhalte; echte Empfänger oder Kundennachrichten gehören nicht in Tests, Screenshots oder Anleitungen.

Benutzerdefinierte Felder

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

Der Administrator kann den Profilen der Mitarbeitenden zusaetzliche Felder hinzufuegen — zum Beispiel eine Position in freier Form, eine interne Kennung oder das Eintrittsdatum. Unterstuetzt werden verschiedene Typen: Text, Zahl, Datum, Werteliste, Verweis auf einen Benutzer oder eine Abteilung; ein Feld laesst sich als pflichtig oder mehrfach kennzeichnen.

Bevor Sie massenhaft Felder anlegen, klaeren Sie, wozu jedes einzelne dient und wer es ausfuellt: Wo genau ein Feld den Mitarbeitenden angezeigt wird, haengt von der Konfiguration des Portals ab. Fuehren Sie Felder daher bewusst ein und nicht auf Vorrat.

Felder werden auf der Administrationsseite /custom-fields angelegt und sortiert; der Anzeigeort ausgefuellter Felder kann weiterhin von der Portalkonfiguration abhaengen.

Unternehmensanmeldung (SSO)

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

LadVen OS unterstuetzt die Anmeldung ueber einen externen Identitaetsanbieter (Unternehmens-SSO). Manche Installationen zeigen Einheitliche Anmeldung (OIDC) unter CRM → Integrationen, andere benoetigen weiterhin den Portal-Anbieter. Verfuegbarkeit und Felder haengen von der Installation ab; beachten Sie Einheitliche Anmeldung (OIDC) und klaeren Sie den Ablauf mit dem Portalbesitzer.

Gute Praktiken

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

  • Aendern Sie die Regeln der Module als Richtlinie fuer das gesamte Unternehmen und bedenken Sie vorab die Auswirkung auf alle.
  • Halten Sie fuer sensible Module standardmaessig den strengen Zugriffsmodus.
  • Richten Sie die Systempost ein und pruefen Sie sie, bevor Sie massenhaft einladen und Prozesse starten.
  • Fuehren Sie benutzerdefinierte Felder fuer eine konkrete Aufgabe ein und nicht auf Vorrat.
  • Begleiten Sie Aenderungen von Richtlinien und Regeln mit einer verstaendlichen Begruendung — sie bleibt in der Historie erhalten.

Haeufige Fehler

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.

  • Eine Modulregel wird fuer einen Einzelfall geaendert, wobei vergessen wird, dass sie fuer alle gilt.
  • Der offene Zugriffsmodus bleibt dort bestehen, wo es Kunden- oder Finanzdaten gibt.
  • Einladungen werden vor der Einrichtung der Systempost versendet — die E-Mails erreichen niemanden.
  • Benutzerdefinierte Felder werden ohne Zweck angelegt, und das Profil verkommt zum Sammelplatz.
  • Man nimmt an, dass jede Installation SSO gleich einrichtet — pruefen Sie zuerst, ob der OIDC-Connector vorhanden ist.

Verwandte Abschnitte

Konzeptionelle Prozesskarte; kein UI-Screenshot und kein Zustandsnachweis.