Rights, not role buckets
Permissions such as 'vehicles:manage' or 'belege:mark-paid' are granted individually. Each module brings its own rights.
Core platform
Roles, tenants & audit
Permissions are individual rights, not buckets: manage vehicles, approve bookings, correct receipts, issue devices. Roles bundle those rights — shipped or entirely your own.
Permissions110+ individual rights
TenantsOne database per tenant
Data visibilityRow-level, by site
Sign-inLocal or OIDC/SSO
Who may do what — and who changed what, when?
MobilityManager is multi-tenant from the ground up: each tenant has its own database, and the same user can hold different roles in different tenants. Every data-changing operation lands in an audit log that cannot be altered afterwards — modification attempts are rejected rather than silently applied.
What it does
What the module actually does
System roles and custom roles
Shipped roles (system admin, tenant admin, fleet manager, approver, driver) work out of the box; custom roles can be composed freely.
Isolated tenants
Subsidiaries, agencies or sites run in separate databases from one installation. A tenant switcher in the header moves between permission sets.
Site-based data visibility
Inside a tenant, visibility can additionally be limited row by row: users are assigned sites, vehicles and driver files carry a site, and the boundary runs inside the database query — not as a filter in the interface.
The boundary applies to administrators too
There is no silent exemption for system administrators: no site assignment, no data. Administrative surfaces — the site catalogue, the user editor, tenant settings — stay unfiltered so nobody can lock themselves out.
Immutable audit log
Every data change produces an entry with user, timestamp and object — searchable and write-protected.
GDPR tooling
Access and erasure under Art. 15 and 17 are modelled as workflows; erasure is pseudonymization so operational history and retention duties survive.
Sign-in through your directory
OIDC against Azure AD / Entra ID, Keycloak or ADFS, so accounts are managed where they are managed anyway.
Frequently asked questions
Yes. Alongside the shipped system roles you can create any number of custom roles with exactly the rights a position needs — for example a role that reviews receipts but cannot change vehicles.
No. Separation happens at the database level, not just as a filter in a query. A user with access to several tenants switches deliberately and then works exclusively in that tenant's context.
Yes, through site-based data visibility. It is switched on per tenant, users get their sites assigned in the user editor, and from then on lists, deep links, dashboards, reports and exports are limited to those sites. A second switch decides whether records without a site assignment stay visible. We ran the boundary through four independent adversarial reviews, because a visibility boundary is only as good as its weakest door — and where a guard cannot cover a class of error, our documentation says so.
Through pseudonymization: personal references are removed while operational records such as bookings or costs survive as anonymized entries. Retention periods are configurable and a background service cleans up expired data automatically.
Works together with
Driver file
Drivers as master records rather than shadows of a user account — with credentials, blocking and a 360-degree view.
Document management
Attach documents to vehicles, drivers, receipts, damages and fines, search them tenant-wide — on your own storage.
Reports & analytics
A report hub with 34 reports, one shared export layer and per-vehicle KPIs.
Bookings & dispatch board
Self-service booking from assigned pools, approval workflow and a dispatch board for day-to-day planning.
See this module with your own data
30 minutes, no sales pressure: we show the module in the context of your fleet — self-hosted in your data centre, GDPR-compliant, made in Germany.