Rechte statt Rollenschubladen
Berechtigungen wie „fahrzeuge:verwalten“ oder „belege:als-bezahlt-markieren“ sind einzeln vergebbar. Module bringen jeweils eigene Rechte mit.
Berechtigungen sind einzelne Rechte, keine Schubladen: Fahrzeuge verwalten, Buchungen genehmigen, Belege korrigieren, Geräte ausgeben. Rollen bündeln diese Rechte — mitgeliefert oder komplett selbst definiert.
MobilityManager ist von Grund auf mehrmandantenfähig: Jeder Mandant hat eine eigene Datenbank, und derselbe Benutzer kann in verschiedenen Mandanten verschiedene Rollen haben. Alle datenverändernden Vorgänge landen in einem Audit-Log, das sich nicht nachträglich verändern lässt — Änderungsversuche werden abgewiesen statt still ausgeführt.
Berechtigungen wie „fahrzeuge:verwalten“ oder „belege:als-bezahlt-markieren“ sind einzeln vergebbar. Module bringen jeweils eigene Rechte mit.
Mitgelieferte Rollen (u. a. Systemadministrator, Mandantenadministrator, Fuhrparkleitung, Genehmigende, Fahrer) sind sofort nutzbar; eigene Rollen lassen sich frei zusammenstellen.
Tochtergesellschaften, Ämter oder Standorte laufen in getrennten Datenbanken aus einer Installation. Ein Mandantenwechsler im Kopfbereich blendet zwischen Berechtigungen um.
Innerhalb eines Mandanten lässt sich zusätzlich zeilengenau begrenzen, wer welche Daten sieht: Benutzer bekommen Standorte zugewiesen, Fahrzeuge und Fahrerakten tragen einen Standort, und die Grenze läuft in der Datenbankabfrage — nicht als Filter in der Oberfläche.
Es gibt keine stille Ausnahme für Systemadministratoren: ohne Standortzuweisung keine Daten. Die Verwaltungsoberflächen — Standorte-Katalog, Benutzer-Editor, Mandanteneinstellungen — bleiben ungefiltert, damit sich niemand aussperren kann.
Jede Datenänderung erzeugt einen Eintrag mit Benutzer, Zeitpunkt und Objekt — durchsuchbar und schreibgeschützt.
Auskunft und Löschung nach Art. 15 und 17 sind als Vorgänge abgebildet; Löschung erfolgt als Pseudonymisierung, damit betriebliche Historie und Aufbewahrungspflichten bestehen bleiben.
OIDC-Anbindung an Azure AD / Entra ID, Keycloak oder ADFS, damit Konten dort verwaltet werden, wo sie ohnehin gepflegt werden.
Ja. Neben den mitgelieferten Systemrollen lassen sich beliebige eigene Rollen anlegen und mit genau den Rechten bestücken, die eine Position braucht — etwa eine Rolle, die Belege prüfen, aber keine Fahrzeuge ändern darf.
Nein. Die Trennung erfolgt auf Datenbankebene, nicht nur über einen Filter in der Abfrage. Ein Benutzer mit Zugang zu mehreren Mandanten wechselt bewusst und arbeitet dann ausschließlich im Kontext des gewählten Mandanten.
Ja, über die standortbezogene Datensicht. Sie wird pro Mandant eingeschaltet, Benutzer bekommen im Benutzer-Editor ihre Standorte zugewiesen, und ab dann sind Listen, Detailaufrufe, Dashboards, Auswertungen und Exporte auf diese Standorte begrenzt. Ein zweiter Schalter entscheidet, ob Datensätze ohne Standortzuordnung sichtbar bleiben. Wir haben die Grenze in vier unabhängigen, gegnerisch angelegten Prüfungen durchgehen lassen, weil eine Sichtbarkeitsgrenze nur so gut ist wie ihre schwächste Tür — was ein Wächter nicht abdeckt, steht ausdrücklich in unserer Dokumentation.
Über Pseudonymisierung: Personenbezug wird entfernt, betriebliche Datensätze wie Buchungen oder Kosten bleiben als anonymisierte Vorgänge erhalten. Aufbewahrungsfristen sind konfigurierbar, ein Hintergrunddienst räumt abgelaufene Daten automatisch auf.
Fahrer als Stammsatz statt als Schatten eines Benutzerkontos — mit Nachweisen, Sperre und 360-Grad-Sicht.
Dokumente an Fahrzeuge, Fahrer, Belege, Schäden und Mandate anhängen, mandantenweit durchsuchen — auf Ihrem eigenen Speicher.
Ein Auswertungs-Hub mit 34 Berichten, einer gemeinsamen Exportschicht und Kennzahlen je Fahrzeug.
Self-Service-Buchung aus zugewiesenen Pools, Genehmigungsworkflow und eine Plantafel für die tägliche Disposition.
30 Minuten, ohne Verkaufsdruck: Wir zeigen das Modul im Zusammenspiel mit Ihrem Fuhrpark — On-Premise in Ihrem Rechenzentrum, DSGVO-konform, Made in Germany.