Fleet Management Roles and Permissions: Responsibilities for Your Electric Fleet

A roles and permissions framework defines who may see which information and make which changes in fleet software. For electric fleets, this includes vehicle master data, charging assignments, billing overviews and exports. Effective permissions follow specific tasks and are adjusted for temporary cover, role changes and departures.

Start with the workflow. A site manager may need to resolve open charging sessions for their branch. Central billing, meanwhile, needs amounts across sites. These tasks may require different data views and editing permissions.

Describe activities before naming roles

Labels such as “administrator”, “manager” or “user” say little about which actions are allowed. First create a list of actual activities. These might include creating a vehicle, changing a cost centre, confirming a charging assignment, reading a report or creating an export.

Separate four questions: Which information may the person see? Which records may they edit? Which decisions may they approve? Which additional accounts may they administer? Read access should not silently include a complete data export.

Then group activities that regularly belong together. This creates roles that can be assigned transparently to new employees. A role should not keep accumulating permissions simply because individual exceptions have previously been easier to handle that way.

Create a simple permissions matrix

The matrix connects role, action and scope. Alongside the permission itself, it matters which vehicles, sites or legal entities it applies to.

This matrix is a planning example. Whether your software supports these distinctions needs to be checked. If a smaller team needs several roles per person, the individual permissions should still remain traceable.

The article on vehicle master data in fleet software provides the business foundations for master-data maintenance. The fleet portal change history article covers which changes particularly need to be traceable.

Practical example: Arranging holiday cover

Illustrative organisational example: The person who normally handles unresolved charging assignments at a site is away for two weeks. Their replacement needs access to the relevant vehicles and sessions.

Before the absence, the task, scope and period are documented. The replacement receives their own account with the agreed permissions. After the colleague returns, a check confirms that the additional permissions have been removed. Open cases are handed over with their processing status.

This preserves visibility of who made an assignment. A shared account would make this harder to trace. If the software does not support time-limited permissions automatically, a binding task is needed to adjust them later.

Plan joining, changes and leaving together

When someone joins, their role, data scope and responsible approver must be defined. Check with the new person that they can complete their tasks and know which issues to report when permission is missing. Resolve a missing permission specifically rather than granting broadly expanded access.

An internal role change also requires a review of previous access. New tasks are often added while old permissions are accidentally retained. Use a role change as a reason to review the person's entire assignment.

When someone leaves, consider open tasks, technical accounts and any temporary cover arrangements that remain valid. Record who closes the account and who takes over the business tasks. Technical accounts for integrations need their own owner; they should not silently depend on a personal account.

Checklist for a permissions test

Test the framework with representative user accounts before extending it to the whole team. Check both required actions and actions explicitly outside the role's needs.

1. Can each role complete all of its everyday tasks?

2. Does data outside its scope remain inaccessible?

3. Are reading, editing, approving and exporting separated appropriately?

4. Can temporary cover be arranged without shared credentials?

5. Are role changes and the relevant approvals recorded?

6. Do access removal and account suspension work as intended?

7. Is it clear who reviews permissions regularly?

Agree a review schedule suited to your organisation, with additional checks when sites or tasks change. Document the result briefly but clearly. The test should show whether the actual configuration matches the agreed framework.

Connect permissions to clear work instructions

Even suitable permissions do not explain when an action is correct in business terms. Add short work instructions to each role: required inputs, decision-making scope, evidence to document and a contact for unresolved questions.

For personal data, the purpose and lawfulness of processing also need to be clarified. The article on data privacy in fleet software helps structure these questions separately. A software permission does not replace this assessment.

Discuss with StromNow for fleets which people are involved in your charging organisation and billing. A prepared role matrix makes the access you need visible and helps establish which permissions can be implemented technically.